Communicating Design Concepts Without Getting Skewered

We have a saying around the office: "If you can't explain the design, it must not be right yet." It's a reminder to designers to not get so caught up in idea generation and specifying details that we lose sight of creating a coherent big picture for the design.

We need to exercise the ideas we generate by articulating them coherently; chances are high that if we can't describe our "great idea" with clarity, it's not such a great idea, after all. It's amazing how many design ideas seem just dandy on the whiteboard, then deflate like a punctured balloon when poked at with the sharp pencil of design communication.

One of the more difficult communication milestones during a design project is the design "vision." This is the point during the process when the design is far from complete, but the design team has a clear idea of the overall concept, navigation structure, and main elements of the application, product, or service, and the relationships among those elements. At this point, feedback is crucial for the design team: all of the remaining detail work hinges on these concepts. Getting them wrong now, and having to change them later, means weeks of wasted time and effort.

Of course, presenting design concepts that aren't fully baked has its own set of challenges. Share something that you haven't exercised enough to see if it holds together, and you risk losing credibility. Wait too long to make sure that everything looks perfect, and you'll have a hard time keeping people's feedback at a conceptual level (not to mention making it difficult to meet deadlines).

We've found there are some critical components to successfully communicating a conceptual design framework to a product team.

Have a good story to tell

Because you don't have all of the design details figured out yet, it's ineffective to simply walk through the anatomy of the interface and describe features and controls. Rather, come up with a couple of key scenarios that will show off the most important facets of the design, and that show how a user achieves a goal—from start to finish—using the new product. Not only will this help you focus your walkthrough, it will resonate more with your audience. Human beings think in stories, and contextualizing the proposed design solution with a story helps your collaborators imagine what the eventual user experience will be like.

Spend some time crafting your scenarios, and make sure they are real-world examples of the activities your users will actually perform. Avoid creating a Rube-Goldberg-esque scenario full of unrealistic workflows just to show all of the different screens in your design. Rather, show off your design by communicating how smoothly and efficiently an archetypal user can complete a particular task or related set of tasks in order to achieve a goal that is important to them.

Each scenario should contain:

• Several high-level screen sketches that show each major screen or area that the user navigates to while completing the tasks within the scenario

• Text or verbal descriptions of the main actions the user takes

• Mention of any time lags or interruptions that occur during the scenario

• Appearances by other users involved in a multi-person workflow, as appropriate.

Present design at a level of fidelity that matches the fidelity of your thinking

Have you ever presented a design concept to colleagues, looking for feedback about the overall concept, interaction workflow, or other big idea, only to wind up facilitating a debate about what shade of blue to use in the title bar, or whether or not to use buttons with rounded corners versus sharp edges?

Chances are, the design sketches (or, more likely, the prototype screens) that you presented were too detailed. When people review screens that contain real data and have visual design applied to them, it's easy to think of the design as finished; it feels less malleable. It is harder for people to evaluate high-level concepts when their eyes and attention are drawn to the multitude of details—many of which probably won't have been well thought through yet, since this is an early draft of your design—that are visible in the screen drawings. The result is a whole lot of feedback, but not at the level of detail that you need to understand whether or not your concept is working.

To get people to focus on concept, don't provide any details that may distract them. Present design sketches (and calling them "sketches" helps reinforce this idea) that clearly do not have "real" visual design, and don't fill out the screens with real data. People will start focusing on the data rather than the concepts.

An example of a "framework" design sketch

Some good ways to keep design sketches at a high level include:

• Use a low-fidelity drawing tool such as PowerPoint or Visio. If you are using a pixel-rendering tool such as Macromedia Fireworks or Adobe PhotoShop, consider creating a vector-based template that forces you to draw in blocks instead of pixels.

• Don't use real data. Insert one or two examples of real data to communicate the kind of information that lives in a particular area of the interface, but use gray bars to simulate the rest of the text.

• Only label key controls. People in your audience may get hung up on the names for controls, which is a distracting detail when you are looking for conceptual feedback. You should be able to describe the kinds of controls that will exist in different areas of the interface, but having an exhaustive list at this point is premature.

• Don't apply a real visual design. Use some background color and shading to communicate a high-level of visual hierarchy (traditional black-and-white wireframes are hard to evaluate because all information and controls are presented as peers), but don't get detailed with color or visual elements.

Get all the decision-makers together in the same room

In some large companies, this task is more difficult than doing the design and developing the product. In order to get the feedback you need to go forward with confidence, though, it's vital to get the key constituents from marketing, development, product management, and any other important internal stakeholders together. Meeting with them individually will give you good information about individual perspectives, but it's equally important for people to see and understand the reactions of others in different departments. You'll be able to facilitate discussions about technology, time, and budget concerns, and enable your team members to consider the whole picture as they make prioritization decisions.

Carve out time in the schedule for design communication

Communicating design does take time, no doubt about it. But it will save a lot more time by reducing the thrash that occurs when developers don't have a clear understanding about what it is they are supposed to build.

How many times have you worked on a project where product decision-makers don't really know what the product is going to look like and how it's going to behave until they see a coded prototype? And how often did they say, "Wow, that's neat… but it's not really what I had in mind"?

Ouch. Back to the drawing board.

Filed under: Communicating design, Features

---

---

Post a comment

---