Originally published: Jul 10, 2012
For today's designer, much of the work we do focuses on improving designs that already exist. Whether what we're working on is something we've built or we're improving on a competitor's idea, we can look to what users do today to figure out where we can make the design better. We understand how to identify the improvements by using time-proven methods and processes.
However, with greater frequency than ever before, we now get opportunities to work on design solutions that don't have existing models to work from. We're working in the world of the "never been done before."
Maybe we're integrating a new technology into a workflow that's never had something like that before, much like what's been happening with handheld devices in medicine? Maybe we're providing new data and insights to people because we can now combine data in a way we never could before, like what's happening in the world of big data? Or maybe we have a way for users to take advantage of each other's experience and knowledge, like some of the emerging crowd-sourcing applications?
Working in the never-been-done-before world can be stressful for design teams. Because there's no existing designs to copy and enhance, it can feel like more pressure to get the right solution.
One piece of solace is that new solutions usually occur to solve an old problem. While your new idea may be solving the problem in a completely novel way, the problem itself probably existed long before you came up with your idea.
Let's say we're working on a new application for a hospital Critical Care Unit. Our application will let doctors, nurses, and family members track the status of a patient in the CCU. It'll use a variety of platforms - desktop and mobile - so folks can track what's going on both in the hospital and when they are away from the patient.
Now, our application is brand new. Nobody has built one of these before. (Ok, it's very possible this application does already exist, but let's pretend we're the first ones to think of it.)
Because it's brand new, we can't just see what others have done and build something incrementally better. This will be a revolutionary new design - something the world has never seen before.
However, the problems of keeping up on a patient's status do exist in the world right now. Doctors, nurses, and family members all want up-to-the-minute status. They want to find out the moment an important event occurs.
This means we can study these interactions today. Even though there isn't a product yet, we can see where people are losing critical information or time because they don't have the most up-to-date information. We can see how they compensate for these problems, using hacks or workarounds they've created.
Most importantly, we can see what information they value and what they consider secondary. We can see when they need certain information, and how that information landscape changes as the care of the patient moves forward.
The key to building great designs that have never been done before is to truly understand the problem space. We do this by studiously investigating the contexts that our design will live in.
Getting out of our offices and visiting where people will use our designs is important for any type of design, and super critical when it's something nobody has ever built before. We want to look anywhere these problems surface and witness what made that happen.
As we explore the problem space, we want to take the entire team with us into the field. Of course, it may be impractical for 5 or 10 people to show up in a critical care unit, so we'd have to break the group up into manageable teams. This means that different team members will observe different aspects of the problem, so we need a good synthesis process to layout the entire problem.
Where teams get themselves into trouble, is by adopting the first design solution that pops into their head. Instead, the most successful teams hold back on solutions and work hard to wrap their brains around the problem. A solid synthesis process keeps us focused on the problem without jumping to design solutions too quickly.
Once we've collected as many observations as we can, we need to synthesize those findings into something we can start to build from. A great way to dive into the problems is to catalogue the research's working scenarios: a collection of small stories describing what we saw during our research. Each scenario describes a time when our future design could've improved the lives of the people we observed.
In our CCU patient tracking application, we observed a parent that wanted to know how their recovering child was eating foods. Their child had recently returned to eating solid foods. The mom wanted to know when her son started to eat again, as this indicates a major step in recovery.
Thinking about this made us think about how the system would learn that the child started eating food again. If we had observed a nurse putting this information into the chart, we could create a scenario around that too.
However, the creation of the parent notification scenario might point out that we don't know where that data is coming from. We hadn't actually seen a nurse make a note of it and didn't know how the CCU staff handled that today. This would give us an opportunity to explore that particular part of the problem in more depth with additional research.
Scenarios are a great tool for this kind of synthesis, since they help us fill in the gaps in our understanding. It's important that the entire team be part of the scenario creation and documentation. This forms the basis of a shared understanding, which will help reduce opinion wars later on in the process.
A studio workshop is another great tool for exploring the problem space, ironically by creating a variety of design solutions to test against it. The workshop activity is fairly simple. The entire team gathers in a room with lots of sketching materials and starts by creating some quick design variations.
In a typical workshop, the team might break into groups of 3 or 4 individuals. Each group focuses on one of the scenarios. Then each group member spends 5 minutes drawing as many different low-resolution design solutions as they can think of. Ideally, each person would come up with 5 to 8 ideas in that 5-minute sprint.
Next, they share their drawings with the others in their small group to hear inspirational ideas before a second round of quick sketches. This process is repeated two or three times, to generate as many ideas as they can, all without judgement.
In the next phase, each group member identifies one or two of their own sketches they particularly liked. They refine their ideas for another 8 minutes, taking the details to the next level. Like the first phase of sketches, they share their thinking with the other group members, then work on a different refinement, again repeating this a couple of times.
By the end of the first hour, everyone in the workshop should have sketched dozens of design ideas and started working through the most interesting ones. In a show-and-tell session with everyone, they can now start to share their thinking, talking about the good ideas and places where they need to think some more.
The beauty of a studio workshop is that it quickly generates a working design vocabulary, both through the sketches and the language that people use when talking about their ideas. That vocabulary becomes the foundation for talking about the problem the design is trying to solve and the ways it can solve it.
By laying down this foundational understanding of the problem, the team will be in a better place to come up with innovative solutions. They'll have a rich catalogue of how people deal with the problem today and they'll create a design vocabulary that describes workable and delightful solutions.
How have you ensured your team explored the problems behind your never-before-done designs? Leave us your thoughts at our UIE Brain Sparks blog.
Read related articles: