UIEtips: Exploring the Problem Space Through Prototyping

Jared Spool

September 20th, 2012

In today’s UIEtips, I discuss the difference between mockups and prototypes and how the four stages of a prototype helps you understand a design problem. Here’s an excerpt from the article.

A mockup shows us a possible solution. It asks the question, “What do you think of this direction for our design?” Whether the mockup is a sketch or a fully-rendered interactive experience, it’s looking at whether the ideas contained would be a good solution.

Prototypes are different from mockups. They don’t focus on the solution, but on understanding the problem. They ask the question, “What happens when we try this?” Maybe we learn it’s the right idea, but more likely we learn something about the problem we didn’t know before.

Read the full article, Exploring the Problem Space Through Prototyping

Learn to prototype in HTML and CSS
Excite your team and clients by demonstrating your ideas through interactive designs. At Nathan Curtis’s daylong workshop at the User Interface 17 Conference in Boston, November 7, he’ll show you sketching techniques and HTML and CSS coding tips you can start using today.

What process do you go through with your prototypes? Share your thoughts below.

5 Responses to “UIEtips: Exploring the Problem Space Through Prototyping”

  1. Dan Olsen Says:

    Jared,
    Great post. I like your framework. It’s great to see you using the phrase “problem space”. I discuss it in most of the talks I give on product design, which I post on SlideShare:
    http://www.slideshare.net/dan_o/early-stage-web-product-management-by-dan-olsen

    Rapid prototyping is become an increasingly important skill set, so it’s great to see UIE emphasizing it.

    Dan

  2. Meghan Ede Says:

    I have an observation about prototypes.

    I’ve often seen designers create “prototypes” that work inside specific systems, either built in-house or bought, like PowerPoint. They test the design by having users go through, page by page, and ask them to indicate what they like and don’t like.

    How does that approach – fixed step flow – fit into your model of prototyping?

  3. Meghan Ede Says:

    Another thing I often see when teams evaluate prototyping tools:

    “can we re-use the code”
    (i.e., can the coders incorporate the prototype, as-is, into the “real” code).

    Thoughts?

  4. Jared Spool Says:

    Meghan, there’s two ways it fits into how I’m thinking of prototyping:

    First, the conversations that go into the creation of the prototype or mockup contribute to the team’s understanding of what they are trying to build. Often, there is value that comes about even before the team has shown it to any prospective users.

    Second, when watching users perform tasks with the prototype, it gives a way of exploring the interface between how the design performs and what users need. With a well constructed experiment, you can learn a lot. (Unfortunately, many experiments are not well constructed and often take teams down a wrong path. An article for another day.)

    As for utilizing the code produced by the prototyping tool, that typically not really valuable. Those tools are not good at producing efficient, productive code. Plus, if it’s a prototype and not a mockup, then it won’t really represent what the user is likely to be delivered. The final design will look very different, so the code the tool produces isn’t valuable.

    In any given project, the best teams use five or more formats of prototypes, including sketches, workflow diagrams, clickable prototypes in Acrobat or Keynote, JQuery-built HTML prototypes, or working code to test performance-type issues. Teams that think they can get away with a single tool and format probably aren’t using prototyping to its fullest.

  5. Darren Hemming Says:

    I mainly write HTML prototypes which include CSS and Javascript. That seems to give the customer enough of an idea about functionality, and provides something for the developers to work against.

    The limitation of this approach is sample data. I can only really provide one level of data e.g. figures for a single day, which is limiting for solutions with lots of views.

    So in those circumstances I either provide a detailed accompanying document or produce a fuller model in something like Expression Blend using sample data.

Add a Comment