Prototype Technologies are Ruining Your Prototypes

I want to challenge our thinking on how we use prototype technology in our world of software development. Are we using prototypes to help our business users all get on the same page and visualize a solution?  Or are prototypes targeted at our internal team, so they can understand what the resulting system “should look and behave like”?

Prototyping can mean different things to different groups. For purposes of this post, let’s use this definition:

A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from.

When I researched this definition, there were some key points that consistently turned up.  They include:

• A Prototype isn’t the final product.It is designed to test a vision and illustrate a requirement for a final product. For example, if you want to design a car with the gear shift on the left side of the driving wheel, you could create a prototype with only that level of detail. It may not have a horn etc… Just enough to ‘prototype’ the proposed change.

• A Prototype is used to eliminate ambiguity. In other words, it helps drive a common vision across project participants.  For example:  “Oh… so when you said make it smaller, you really meant tiny or minuscule. I see now”.

• A Prototype is used to drive feedback. This helps an idea grow before making huge resource or financial commitments.  We might build a working prototype of an Internet Alarm Clock that plays your music stored in the Cloud on the Internet.  It may be fully functioning, but it is a one-off. Its purpose is to gather our initial reactions and generate additional ideas based on the working prototype.

• Finally, a Prototype might be a Proof-of-Concept. This is used to test the feasibility of an idea and whether the initial vision can actually be delivered with the desired results. This is more of a design based prototype.

Why We Prototype

To summarize, prototypes can be used to:

• Drive a common vision across stakeholders
• Confirm our understanding of a desired end-state
• Provide a forum for feedback among internal stakeholders and external customers.
• Act as a proof of concept, flushing out the feasibility of an idea

Most prototypes serve one or more of the above the purposes.

These days, there are many tools for prototyping.  Everything from HTML for creating  working-light-weight prototypes for review to wireframe tools such as iRise or Balsamiq.  There are even PowerPoint files with “wireframe templates” in them to build wireframes and mockups using PowerPoint and it’s native tools.

So What’s the Problem?

In spite of the great tools out there, I’ve been in situations where these tools actually get in the way of our goals. They don’t help the business users get to alignment. In fact, prototypes created with these tools can actually drive a “compromise” in their design. Let me explain using an example:

I have three business users working to define a new “quick order” system for their web site.  The Business Analysts spend a couple of hours working with them to collect their vision for the new shopping experience and all the tweaks necessary to take their website to the next level.

We take these requirements and have a designer build a quick prototype so we can make sure this is what they wanted. The final wireframes (built in HTML or another technology) are then emailed around to the business folks for feedback.

Now Volleyball Sets In!

Volleyball starts when one group, in this case the designers, emails information to the users and then the users email back their clarification or changes and the cycle continues.

It’s like each side is sending something over the wall or volleyball net. And, just like in volleyball, if one side drops the ball (or gives up) the other side scores a point.

At this point, the  challenge  is to effectively create a  common vision across multiple stakeholders using email! (Hmmm, I wonder if this is how congress works.)

More often than not, the business gets the prototype to where it’s “Good Enough” and then approves it. They want to get going and hope they can tweak it as it is being developed.

Let’s see how effective this is at achieving our goals for prototyping:

• Drive a common vision
• Confirm understanding of a need
• Provide a forum for feedback
• Checking feasibility

I would argue that this process is extremely ineffective and delivers inconsistent results.  When someone says this is close enough, are they really saying they feel like we are all on the same page?

If it DID accomplish these goals, then any system that used this approach would have less change requests, less defects and lower overall development cost.

But there is a better way. The Lo-Fi way.

Enter Lo-Fi Prototypes

Here is another way to create and finalize prototypes.  Let’s go back to the meeting where the Business Analysts were collecting requirements.  After they collected the high-level requirements, they use actual post-its that are cut into screen widgets. For example, there are post-its in the shape of data entry fields, list boxes etc. You can even use fan-folded post-its looking like a drop down box.

Now we ask the business users to actually build their screens. Using the post-its, scissors and markers, they create a lo-fidelity prototype. Whenever possible, we print out existing screens, even screens of a competitor, and mark these up with post-its and markers.

The prototype is NOT designed to flush out usability or the end look and  feel. It is used only to enable the business users, as a group, to quickly build their lo-fidelity prototypes and share their vision and intent for the system.

I’ll emphasize that it is CRITICAL they understand that the final system will be a bit different due to design requirements, usability, branding, etc…

This approach is extremely effective and scalable. In fact, I have facilitated a small group of business users using this method to create more than 50 screens and report prototypes in a session.

There are a couple of great benefits using this approach:

• The stakeholders feel ownership for the prototypes
• It eliminates ambiguity, frustration and misunderstandings due to volleyball
• Stakeholders can iterate immediately
• They work as a group, helping drive alignment which results in less rework
• Prototypes can be scanned into the requirement documents

At times, we give a few of the more critical lo-fi prototypes to a developer to create a hi-fi prototype (an HTML based prototype that can be interactive) over lunch.  And yes – I said over lunch! The users can then get a real understanding (feedback) on their vision.

So if you really want to use prototypes effectively, forget about all those fancy tools. This down-to-earth, friendly  approach will help you fast path collecting clear requirements and reduce confusion around the real needs and intent of a system, eliminating the pain of volleyball.

As a final note, I believe there is a place for using technology in prototyping. I am a fan of those tools. But I think we have gotten so technology focused, we tend to forget the real goal and use the technology appropriately.

What kind of prototyping tools does your team use? How do you think the post-it approach would go over in your environment?

Tags: alignment, featured, Lo-Fi, project success, requirements definition

Category: Business-IT Alignment, Requirements Definition, Team Dynamics, Team Performance