Here’s the way I usually approach a problem or an ambiguous project:
I start by talking to the people affected by the problem: product owners, content producers, technologists – and, most importantly, the people who will likely use the new product or process.
People ask for what they know, which usually doesn’t cover the range of possibilities.
My approach is to gather as much implicit feedback as possible: web analytics, observations of behavior, history of incident reports or trouble tickets, conversations on social media.
Then it’s time to have more conversations with real humans who experience the problem at hand, in order to learn more about their daily context and what they’re trying to achieve.
I really like to follow Peer Insight‘s framework for problem-solving, which is to follow the steps of what is, what if, what wows, and what works. The brainstorming happens during the “what if” stage. It’s the time for divergence of ideas, without the limitations of resource or risk. The trick is to keep the product team from converging too quickly.
This is my absolute favorite part of the process, because it’s where we begin to see what wows people and whether our hypotheses were right. It’s also the point at which teams seem to solidify.
Most of my prototypes begin as sketches, then become of increasingly higher fidelity with each iteration (after feedback). Once we can generally agree on an approach, I look for ways to cheaply and easily test our assumptions: is this version easier to read? can people figure it out without training? does the system work as expected when we use real content?
If we’re talking a technology project, I often work closely with development teams as either a product owner or UI/UX designer. If we show end users a finished product, we did it wrong. I bring users in early and often and have them help us design something that will work for them. That means they see the messiness and the mistakes. But they’re cool about it. And their early input saves considerable development time.
This usually entails a communications plan, change management plan, governance, and a feedback mechanism. I still treat this as a test, albeit with a large group of real people really using it. So I develop a set of questions to ask after a certain amount of time, and ensure that we have the tools to gather the metrics necessary to answer our questions.
I like to give early users an easy way to share their ideas and ask questions.
Iterative design! I gather all the feedback and usage data I can and look for trends and themes. What are the answers to the questions we had? This may begin another round of conversations, brainstorming, and prototyping. Time to try something different and put it in front of real people. In my ideal world, we would continue to do this throughout the life of the product, although the cycles will slow as the product becomes more stable.
One good way to learn from a project is to develop a common narrative for the team. Writing or telling the stories of what we did helps us come to a common understanding of what we learned.