Practical Design Discovery

One of the hardest design problems I ever worked on was for a company that helps IT groups manage risk. Their product focused on open-source components—inexpensive and widely supported by an enormous community, but often vulnerable to security flaws.

What made this design problem hard was the complexity of the product’s underlying structure, a triangle of interrelated abstract concepts. To work through the problem, we created a series of sketches that helped us understand it.

The outcome ended up being a relatively simple prototype, a model of the overall structure of the application. Though we were chartered to create a detailed design, our client later admitted that they knew we wouldn’t get there, but that they highly valued our efforts to solve the underlying structure. Those efforts set the direction for everything else on the product.

Direction-setting assertions#section2

Much like when we frame problems, we can make assertions that set direction and describe decisions about the design. These decisions will be pretty high-level, meaning they’ll deal with a holistic view of the site or product. Decisions about details come later, though you’ll see that some assertions get pretty specific as a way of clarifying and testing the direction.

There are three kinds of assertions you can make about design direction:

• Principles define what the design should or shouldn’t do. These statements are grounded in research, and may be referred to as implications when you can tie them to research.
• Concepts establish an overall approach for the product, expressed as a central theme or idea.
• Models describe the product in an abstract way, showing the underlying architecture, structure, flow, or approach. They offer a sense of how the product will work (without actual functionality).

If you try to make tactical decisions too early, you may set a precedent without understanding how it influences what comes next—it’s difficult to trace low-level decisions back to a specific objective or problem statement. Why is the button blue? There’s no project objective in the world that can justify such a decision.

Instead, you’ll make a few low-level decisions alongside your assertions, using samples to illustrate, clarify, and demonstrate the application of the high-level decisions. For example, you might arrive at the design principle that the site’s tone should be friendly without being too casual or informal. You would demonstrate that through sample screen designs and content, showing messaging that says “Thanks!” instead of the too-formal “Thank you very much” or too-casual “You rock!”

Exploring the big decisions through examples might encourage you to reconsider them, or to find places in the product experience that need variation. Perhaps the color palette is insufficient for everything you need, or the authoritative voice isn’t appropriate for certain pages.

By venturing a solution, you’re not just asking, “Will this work?” You’re also asking, “Do I have enough knowledge to know whether this will work?” That is, steps toward solving the problem may trigger additional insights, or questions, about the problem. Great discovery entails providing just enough shape and definition so the team can get aligned behind them as direction for the product.

Principles and implications#section3

Principles are rules that help designers evaluate their decisions about the design. They provide guidance in the form of absolute statements about what the design should or should not do. That said, no set of principles can be exhaustive. They read, sometimes, as commandments: rules that may be applicable to many different kinds of design decisions, and therefore open to interpretation.

There’s no industry standard on how to write design principles, so you won’t be violating some ordinance if you use pictograms or write a dialogue. But principles are usually just one sentence, often written in the imperative:

I like these, but they don’t feel specific to the product or company. Principles are most powerful when they’re directly relevant. These use more elaborate phrases that closely relate to the product:

Sometimes, you’ll find principles rendered as one- or two-word noun phrases, as if to complete the expression, “The Principle of ______.”:

Principles are sometimes followed by deeper descriptions and examples. My favorite variation of this comes from the Windows User Experience Design Principles. These principles include questions for designers to ask themselves about design decisions:

Regardless of the approach you take in framing the principles, use consistent language and structures, if only to make them easier to remember and use. If you lead with a verb, always lead with a verb. If you write a pithy phrase or a complete sentence to express the principle, always do that. If you write single-word principles, well, there’s a special place in purgatory for you.

In my practice, I phrase principles as direct consequences of what we learned in research. I call them implications, and I prefer them because they fit into the narrative: “We learned that users often lose their place in the system. The implication is that the UI should prioritize clarifying context.”

Implications answer the question, “So what?” You’ve generated a lot of data, and now need to explain why it all matters. I typically document this in a spreadsheet that identifies project questions, answers I’ve uncovered, and the resulting implications (Fig. 1).

Ultimately, principles and implications do the same thing, so I won’t belabor the distinction between them. In both cases, they make an assertion that, yes, guides the designer, but also provides a test: designers can compare an idea to the principle and determine how closely it adheres to the guide.

There’s no standard for design principles, though there are lots of suggestions out there (the Resources section includes a few of the best). Here are my suggestions for crafting design principles.

Be specific#section4

Principles should be as specific to the product as possible. “Easy to use” isn’t a meaningful principle, because it could apply to anything.

For the project with the risk-management company I described at the beginning of this chapter, we used a number of principles. In early versions of their product, users complained that it was easy to lose their place, so they couldn’t keep track of what they were working on. This led us to the principle:

Context became something we talked about a lot. It forced us to think carefully before moving information to a different screen, or triggering a dialog box for taking action. Because of this principle, we often asked ourselves, “Can the user tell where they are? Is loss of context here okay?”

Question your choices#section5

Good principles go beyond specificity: they issue a direct challenge to designers. They force you to take a second look at your work: does the principle invalidate any of your decisions? Done right, principles should make you squirm a little.

In the risk-management product, the complexity of its requirements inevitably produced dense, esoteric designs. Elaborate displays attempted to capture every nuance, pack in every detail. At the same time, our client had heard their users didn’t like the dense displays. We had to walk a fine line, and so we relied on this principle:

The principle’s borderline self-contradiction provoked us to reconsider what stayed on each screen as users worked through the process. Did we take out too much? Is everything on this screen absolutely necessary? On one hand, we wanted users to feel confident about where they were, but on the other, we didn’t want the page overwhelmed by navigation devices irrelevant to the current task.

We also constantly asked ourselves, “What is ‘just enough information?’” and “What are the ‘essential decisions?’” Every iteration of the design tested the meaning of these key phrases.

Inspire your team#section6

Specific and provocative principles may seem like whip-cracking: Do this, and do it this way. But a good principle also inspires you, pointing you to even loftier goals. It opens up possibilities by encouraging you to explore—and providing rationale for where you end up.

In Luke Wroblewski’s summary of a 2009 talk by Stephan Hoefnagels of Microsoft, he writes, “Goals are the mountain peaks you are trying to get to. [Design] principles are the path we use to get to the top of the mountain.”

One of the driving principles for my client’s product rested on the insight that the product was focused on bad news: every display was about what was going wrong in the IT department that day, how bad it was, and what wasn’t getting done. Like most interactive products, though, this one was meant to be a pleasure to use. In short, we needed to balance the gloom and doom with the satisfaction that comes from understanding the nature and extent of the bad news. We relied on this principle:

We knew the goal was to help customers manage risk. This principle acted as the path to the top of the mountain by inspiring us to focus not just on reporting the bad news, but also on ensuring customers could do something about it.

Link principles to research#section7

Principles grounded in research make for stronger statements. The death knell of any principle is arbitrariness: if a principle comes from the subjective preference of the Chief Something Officer or because it reflects the (dysfunctional) way the organization has always worked, designers will ignore it. Your principle can be otherwise perfect, but if its source is suspect, the team won’t take it seriously.

The team’s participation in all discovery activities is crucial here, too. Since they helped with the research, they can also help with writing the principles. By participating in crafting principles, your team will internalize them. Seeing the principles later will trigger memories of user observations, which they can integrate into their work more readily.

The Windows User Experience Design Principles came directly from research. In reading some of these principles, you can almost hear supporting quotes from users:

• Reduce concepts to increase confidence
• Small things matter, good and bad
• Be great at “look” and “do”
• Solve distractions, not discoverability
• UX before knobs and questions
• Personalization, not customization
• Value the lifecycle of the experience
• Time matters, so build for people on the go

You might argue that these lack specificity. When you take into account the scope of the project, however—an entire operating system—they’re sufficiently provocative and inspirational. “Solve distractions, not discoverability” is a bold statement, offering clear opportunities to refine the design without dictating a particular solution. It opens up conversations, and steers them, too.

Concepts and big ideas#section8

One of my favorite scenes in Mad Men, the television show about advertising agencies in the 1960s, is the pitch to Kodak at the end of the first season. Kodak is introducing a new product, a circular tray that makes it easy to store and show photographic slides. They call it “The Wheel,” admitting, “We know wheels aren’t seen as exciting technology.”

Creative director Don Draper, the show’s main character, explains that this product isn’t about the technology: it’s about tapping into our memories and emotions. The agency then pulls the veil off their concept for the campaign: the carousel.

By establishing a central concept, a team (whether in advertising or web design) has a singular source of inspiration, a template for considering ideas. And while principles can serve as guideposts, only a concept can establish a vision. With both of them in your toolkit, your team has a potentially interesting tension to draw from.

Using a carousel to describe a slide projector creates a metaphor brimming with meaning and possibility. It shows two ways we can express a big idea:

• How the product makes you feel: carousels evoke the joy of reliving happy memories.
• How the product works: the spinning carousel mimics storing and displaying photographic slides from a wheel.

Either approach can help us express the big idea behind our digital products and websites. (Though I’ve never worked on a project that gave us a central concept as elegant as the carousel, which employs both approaches!)

How the product makes you feel#section9

The purpose and function of interactive products offer ripe opportunities for metaphors, but metaphor isn’t the only way to express a central concept. For one web application project, my team expressed the essence with the phrase, “Power with flexibility.” Doesn’t quite roll off the tongue like the word carousel, but it evoked the desired feeling: that the app should make users feel like they can do anything.

We elaborated with descriptions of how people would experience unconstrained power with the product:

We also described what “Power with flexibility” meant from the user’s perspective:

• Knowledge: having the right data to shed light on immediate needs
• Responsiveness: being able to provide answers to stakeholders immediately
• Accomplishment: getting up to speed on a crucial tool right away
• Control: being able to fine-tune their content to suit different needs in different situations
• Comfort: seeing the application as an extension of one’s own thought process

Since this essence was a succinct idea, a little elaboration helped it to resonate with both the client and the project team.

How the product works#section10

Complex interactive products benefit from a central idea that describes how they work. This usually means employing a big idea to convey the underlying structure.

Shopping cart, for example, is a popular metaphor used on ecommerce sites. You could use it even if you weren’t working on an ecommerce site. The idea of “adding stuff to the cart” is a familiar metaphor that conveys a site’s underlying structure. We even relied on this metaphor on our career-guidance site: students would “add careers to their cart” after taking an assessment.

There are a few other tried-and-true frameworks for describing the structure of a website. For web applications, there are two common ones beyond the shopping cart:

• Hub-and-spoke: This is perhaps the most common pattern for structuring a website or digital product. The hub-and-spoke metaphor implies that the web application has a central screen, from which users may trigger all other functions.
• List-detail: Another typical approach consists of a list of items from which users can select for more detail—like your email inbox.

Do you have to use one of these structures? Of course not. But if your site lends itself to one of these approaches, you have your big idea that the rest of the functionality revolves around. (That wasn’t a carousel reference. I promise.)

For sites that focus on delivering content (rather than transactional functionality), the tried-and-true frameworks deal more with how the content is organized:

• Topics: what the content is about, or the subject matter
• Actions: what tasks the content supports (like researching products versus troubleshooting products)

These aren’t the only structures for categorizing content, but they are my go-to starting points.

None of these is a fully fledged design in and of itself. They are well-understood frameworks that serve as the backbone to a much larger design. They are big ideas that describe how the product works.

You don’t have to rely on an abstraction or metaphor (like the carousel) to convey the big idea, but instead draw from the emerging library of understood frameworks. That they are becoming part of web design lingo is a testament to their power and flexibility.

There’s more where that came from!#section11

Check out the rest of Practical Design Discovery at A Book Apart.