Design with trust, ask questions
The most important lesson I learned this past year is that when I don’t understand something, I need to ask questions. I’ve found that overcoming any embarrassment, shame, pride, or ego, and pushing myself to ask seemingly ignorant or naive questions is actually my responsibility as a professional. Having the courage to acknowledge my own lack of understanding and relying on my teammates and other involved subject matter experts has created trust between us and lead to more successful outcomes in my work. I wish I’d learned this lesson early on in high school—I might have done better in algebra.
Learning the importance of asking clarifying questions has helped me develop a general framework for my design process:
- Determine the design problem
- Ask clarifying questions of subject matter experts
- Restate and confirm the design problem
- Draft and critique a design solution
- Iterate on the design solution
- Present the solution to users
- Iterate
- Launch
- Support and iterate
My framework assumes that I’m working in a product environment in which I have design ownership, rather than a consulting environment in which project delivery is the goal.
Day to day, I work with product managers, engineers, marketing and analytics specialists, and regulatory and policy strategists, which all have their own vocabulary and assumptions about our products and services. I often find that our vocabularies and assumptions don’t overlap, so I ask a lot of questions. Doing so has helped me broaden my vocabulary and tease out my co-workers’ and clients’ assumptions.
I’ve also found that when I don’t fully grasp a problem, neither do the people I’m working with; they have their own knowledge gaps, and questioning helps expose what is not fully understood, allowing us to acknowledge and resolve those gaps. Going through this process together often makes design solutions clear to everybody involved, allowing me to document a solution for a design problem that already has the support of major stakeholders.
As a user experience designer, my job is to provide people with a coherent dialogical framework. Because products are relationships, and my top priority with every project is to provide the easiest way possible for clear back-and-forth communication. To do that, I need to fully comprehend the problem, which means synthesizing the knowledge of all the business and technical contributors to the project, and determining the form and content that I think will best resonate with our users. Which is with whom the line of questioning continues, because my design work is always a best guess, and presenting that work to users will further expose assumptions my team could not have known about. It is only by embracing this approach that we can design for those short falls and continue doing our best possible work.
(Source: stewartmccoy.com)
