Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Designing What’s Never Been Done Before

by Jared M. Spool
on July 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.

New Solutions Are Often for Old Problems

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.

Exploring the Problem Space

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.

Building Out the Working Scenarios

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.

Generating Design Ideas to Fill out the Problem Space

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.

Tackling What’s Never Been Done Before

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.

Share your thoughts with us

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.

About the Author

Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter at @jmspool.