Jonathan Walter has written a great article, Navigating Ambiguity, at UX Matters. It’s part of a series of columns that focuses on enterprise UX, or as he puts it ‘designing experiences for people at work’ – That’s what drew me in, initially because there’s much written about new development and design from a UX perspective, but enterprise work is often the overlooked and neglected ‘other’ that’s not considered very glamorous and doesn’t get the attention it deserves where UX is concerned.
As I began reading the article, thought, I realized that he was a kindred spirit of sorts, because I use the phrases: “Navigating ambiguity” or in jest, “parsing the nebula” just about every day when solving problems with digital experience and software functionality development, roadmapping, etc. We, individually, and as a team, have to understand what we’re trying to do before we can map it, plan it, work on it, but particularly, deliver it. Jonathan provides some great insights on that.
Get comfortable with not knowing everything
Jonathan writes:
“Even in situations in which you feel alone in your lack of knowledge, you must become comfortable with saying, “I don’t know.” In his Forbes article, “The Power of Saying ‘I Don’t Know’,” Gaurav Gupta states: “We are conditioned to having and providing quick, confident answers as a sign of competence and leadership. We behave as though any gaps in knowledge should be hidden at all cost. But is this desire to have an answer—and have it quickly—actually helping you? How often do we trade factual accuracy and thoughtfulness for immediacy? Why do people find it so hard to say, ‘I don’t know’?”
Ask (the right) questions
I would say, just ask question, as you don’t know what you don’t know. It’s a journey of a thousand miles, start with one step. Additionally, Jonathan adds:
“…ask the following W questions to reduce ambiguity and approach a problem from a higher-level perspective:“…Once you understand this high-level information, you can ask progressively more specific questions.”
- What problems does this product or capability solve?
- Who will use it?
- Why will they use it?
- When or in which context will they use it?
Provide a vision
This has been hugely important for me. I never had any idea how often I’d have to repeat, dramatize, articulate and visually represent my vision for product or experience. Jonathan puts a finer point on this that I really appreciate:
“…your vision—even if it is overly aspirational or flawed—provides a North Star that product-team members can keep in sight as they develop a product. It can also serve as a useful artifact for identifying which features are in scope for early releases and which you should defer to later releases. “Just take care to avoid leading stakeholders to believe that the vision is final.”
I’ve only scratched the surface on Jonathan’s great article, but I highly recommend you give it a read; if you’re interested in UX and process, you won’t be disappointed and the information is as practical and steeped in experience as it is easy to understand and put into practice. Again, you can find that article here.