prototyping archives
Speed and agility are the most important attributes any design team can have, even beating out creativity and innovation.
This is because a fast–moving process that iterates frequently gets to take advantage of the natural evolution of the design, whereas a slow moving process needs to discover innovation out of the gate, which is much more difficult.”
Jared Spool, in
Prototyping’s Resurgence: Communicating the Designer’s Intent

posted by ted on Thursday, Mar 08, 2012

Going the hand-drawn route on a blog design can easily end up looking played out and cliche, but IDEO pulls it off admirably and authentically on, their collection of tests and prototypes.

posted by jason on Wednesday, Nov 25, 2009

Great interview from Mark Hurst with Brian King on the re-design of Courtyard by Marriott. A great case study on segmentation, observation, user-centered design, branding, and prototyping. Fun to see these familiar concepts applied in a domain that’s less familiar (to me anyway). I loved the description of business travelers being invited to a life-size prototype of the new lobby, built out of foam core to see how they would react to Marriott’s innovations.

posted by ted on Wednesday, Sep 09, 2009

case study

The Case Against Using Your Head

I’m an amateur singer-songwriter when I’m not at work or asleep (let’s say for now that they’re mutually exclusive), and for the last few years I’ve been writing and performing material with different bands, duos, and on my own. Throughout that time I’ve tried different things to get my songs from pen and paper to studio and stage. It’s a typical creative process – start with an idea, work, work, work, end with a performance or a recording or both. For the longest time, my process for getting from point A (“Mmmm…good idea…”) to point B (“We’re going to play a song for you called…”) was pretty straightforward.

posted by davidlindes on Friday, Aug 21, 2009

Review: Balsamiq Mockups

In an unrelated post, Jamis Charles asked, “I know this is totally unrelated, but you mentioned some time ago you started using Balsamiq Mockups. I’d like to pitch it to my UI Team. How has it been working for you? How do you incorporate it into your workflow? Has it increased productivity? A post about this would be greatly appreciated. Thanks.”

I’ll let others speak to their own experience, but here’s a quick post on how it worked for me. I was looking for something easy that would help my team focus less on pixels and colors during the planning stage, and just focus on concepts and framework. Balsamiq worked admirably for that purpose. In fact, within weeks of using Balsamiq for our weekly high-level design meetings, team members were themselves articulating the reason to use Balsamiq: “We don’t get bogged down in the details anymore!”

The workflow was something like this:

  1. I would review high level requirements, talk with the customer and mock something up quickly in Balsamiq, with sketchy notes in the margins. As promised, the tool is drop-dead simple for most things it supports. Don’t expect a freeform drawing tool, but for dragging and dropping basic UI elements, it’s very easy.
  2. Team would meet to discuss.
  3. I would take notes directly in Balsamiq, sometimes updating the mockup, but often just leaving a note in the margins for later. Because of the low fidelity of the prototype, the team was able to get past nitpicking the details and focus on the functional requirements and workflow.
  4. Once we moved out of planning into iterative development, I would refer to the mockups and the notes recorded there to create higher fidelity prototypes, using Fireworks images or HTML prototypes, depending on the need. I tried to get a cycle or two ahead of the dev team, and was generally successful.
  5. As the high fidelity design progressed, we referenced the low fidelity mockups less and less. By the last cycle or two, we were hardly using them at all anymore. I probably haven’t opened the tool in 3 months.

So in terms of productivity, our planning discussions were more productive because we were not bogged down at the pixel level. But in terms of turning the Balsamiq Mockups into production code—that was not really our intent, nor does the tool really support that.

Anybody else have a perspective to share on this or other rapid prototyping tools?

posted by ted on Thursday, Jul 02, 2009

Which is the prototype?

I got a funny request today, one that illustrates how cool our software development process is. The Lead QA on my project (let’s call him Blackbeard) asked me to put a watermark on my prototypes so he can tell at a glance that he’s looking at my prototype and not the actual working software. With multiple tabs open, it’s hard to tell which is which. And that is precisely the point! So I’m adding a watermark.

We’ve also been asked recently to put real data into the prototype to aid in the user feedback loop. My fear is without the tell-tale fake data we put in, our users might run into the same problem!

Our process we’ve developed here at the Church has the Interaction Designer working out all aspects of the user interface and feature set in a high fidelity (XHTML/CSS) prototype before the developers ever see it. This way, stakeholders and users can see what they’re actually going to get, not some bloated bullet list of hard-to-understand functions and use cases.

We then sit and work closely with the developers and QA to make sure what we’ve promised visually is being fulfilled in the working software.

The downside, it seems, is when the actual app is too close to the prototype and everyone gets confused.

posted by jason on Monday, Jan 22, 2007

The Q1 2007 issue of GUUUI points out some of the most common pitfalls of prototyping and how to avoid them in The dark side of prototyping

Some of the points mentioned are:

posted by randy on Sunday, Dec 31, 2006