Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 17:59:00 GMT)

Building a prototype? Bring some rope.

Posted by Thu, 09 Apr 2009 20:57:00 GMT

While scanning through Allison’s copy of Designing for the Digital Age: How to Create Human-Centered Products and Services, I came across this nugget.

The problem with software prototypes

It seems to be widely understood that industrial design and mechanical engineering prototypes—from paperclips and tape to polished appearance models—are disposable learning tools. Prototyping is clearly distinct from manufacturing, so it would be ludicrous to think that even a late-stage prototype could be reused as part of the final product. In software, however, the tools used for anything other than paper prototyping are generally the same tools used for “manufacturing” (i.e., writing production code). For this reason, many stakeholders can’t see why a detailed prototype that appears functional is still many months away from completion.

It immediately reminded me of a few posts that I had written about three years ago on the topic of developing prototypes and NOT keeping them.

The author continues with…

It’s important to educate stakeholders that prototype code is kind of like the illusion of automatic doors on Star Trek—it looks like it’s working, but it’s really a guy standing behind the wall pulling a rope.

I completely agree that education is the most important aspect to managing client expectations. With regard to the amount of work that you put into a prototype, we need to be careful on how much time and energy is put into them. If we can get away with a guy (or some quick Javascript hacks) to demonstrate possible functionality, make sure we aren’t using much more than rope. Rope is cheap. Prototypes should be too.

Related Posts

Matz on Considering Interface

Posted by Mon, 25 Sep 2006 15:11:00 GMT

...back in Portland after being in London and New York City for the past two weeks. It’s nice to be home. :-)

I came across this interview with Matz earlier today. It was published almost three years ago (pre-Rails)... I’m quite intrigued by what he is advocating here…

Bill Venners: You also mentioned in your ten top tips: “Be nice to others. Consider interface first: man-to-man, man-to-machine, and machine-to-machine. And again remember the human factor is important.” What do you mean by, “consider interface first?”

Yukihiro Matsumoto: Interface is everything that we see as a user. If my computer is doing very complex things inside, but that complexity doesn’t show up on the surface, I don’t care. I don’t care if the computer works hard on the inside or not. I just want the right result presented in a good manner. So that means the interface is everything, for a plain computer user at least, when they are using a computer. That’s why we need to focus on interface.

Some software people—like weather forecasters, the number crunchers—feel that the inside matters most, but they are a very limited field of computer science. Most programmers need to focus on the surface, the interface, because that’s the most important thing.

Bill Venners: You also mentioned machine-to-machine interfaces, so are you just talking about interfaces for users or also for machines?

Yukihiro Matsumoto: It’s not just user interfaces. When machines are talking to each other via a protocol, they don’t care how the other is implemented on the inside. The important thing is the proper output getting passed correctly via the proper protocol. That’s what matters.

If you have a good interface on your system, and a budget of money and time, you can work on your system. If your system has bugs or is too slow, you can improve it. But if your system has a bad interface, you basically have nothing. It won’t matter if it is a work of the highest craftsmanship on the inside. If your system has a bad interface, no one will use it. So the interface or surface of the system, whether to users or other machines, is very important.

One of things that we’re really advocating with Dialogue-Driven Development is artifact generation. Wireframes and lightweight prototypes are great for generating constructive dialogue between clients, users, and our team. We should make sure that we understand why and how users will use an interface before we worry about the code that will drive it. Too often we fall into a pattern of thinking where we’re convinced that we can build an agnostic application that has various interfaces to a central repository of business logic and data. While we strive for this during development, it really should be focused on after some initial interaction design has been planned. Of course, this is my opinion.

So, I must ask you. When you’re working with on a new project, do you focus on interface or code implementation first?

Prototypes Are Your Friends

Posted by Wed, 07 Jun 2006 20:30:00 GMT

4 comments Latest by Danger Sat, 10 Jun 2006 09:20:47 GMT

I’d like to apologize for not keeping you updated on Project Borat. If you’d like some background, please read Project Borat, an introduction.

“In early stage design, pretend the interface is magic.”[1]

We’re finishing up Iteration 1, which is a prototype and requirement feedback process. When I used to be a house painter, we’d spend time painting small samples for the customer. The customer would come by when the paint was dry and compare the colors to what they had pictured in their mind and once there was an agreement, we’d move forward with purchasing the necessary quantity of paint for their house. Thinking back… I never questioned this “Show them samples” process as it was how the company did business… but now it seems obvious that people must that made many mistakes of buying colors that weren’t exactly what the customer wanted. Then the painters would be required to repaint. Development work resembles this and this is where prototypes come into play. Painting a house is not quite like developing an application… but that reoccurring process of encouraging customer feedback as early as possible is very similar. It is this feedback that builds confidence that you understand the customers desires. However, if you end up with too much of the wrong color of paint… you might be able to paint a few dog houses with it. ;-)

Over the past few weeks, we’ve had several meetings with the Client to discuss prototypes, user interaction, and goals. For example:

  • When User does X, what information should they be presented with?
  • What types of users will use this application?
  • What are some of the goals and intentions of the users?
  • Might a user want to do z before x?
  • Are users interested in doing something completely different?

During this Iteration we also hit a major milestone for the client. For the first time since they came up with their idea, they were able to see something visual and had semi-functional to play with. The prototype resembled what they had been thinking about conceptually for several months. It can be easy as a developer to forget the importance and excitement that goes along with seeing something that consolidates your ideas… visually for the first time. This process requires a good stream of feedback and asking specific questions about functionality possibilities and not burdening the user with too much information in certain contexts… while still providing them with enough to keep them interested.

In The Art of Project Management, Scott Berkun raises the following questions for iterations and prototypes.

  • What requirements does this satisfy? Can we verify this? (Usability, use-cases, etc.)
  • What’s good and bad about this design relative to the problem it’s supposed to solve (Pros and cons for each of usability, business, technology, considerations.)
  • What data do we need to evaluate this design? (Perhaps a usability study, an informal review by a programmer for engineering sanity, marketing, an expert’s opinion, etc.)
  • What did we learn from this design that we should keep in the next attempt? Eliminate?
  • Are there any other idea groupings or from other prototypes that we should include?

Another important thing to do during any iteration is to keep a list of open-issues. Berkun suggests using a simple tool for this. We’re using plain text files in subversion and using Textile for markup.

What’s next?

  • Idea consolidating
  • More prototypes
  • Discussing architecture plan
  • Scheduling

Until next time…

1 Alan Cooper & Robert Reimann, About Face 2.0: The Essentials of Interaction Design. Wiley 2003.

Keeping Prototypes is a Bad Idea

Posted by Sat, 11 Mar 2006 14:30:00 GMT

11 comments Latest by Perry Tue, 21 Mar 2006 01:30:46 GMT

In a recent article titled, Just Build It: HTML Prototyping and Agile Development on Digital Magazine, Garrett Dimon writes,

“You need to temporarily suspend any notions that prototyping is always throwaway work. If you approach it as throwaway work, it will be. However, if you approach it with the intention of keeping it, you can create modular code that can be reused.”

I disagree. :-)

I’m not a HTML web designer, but when building applications, a prototype should be looked at as a process in which you agree that what is built will and should be thrown away.

Why?

When you are in prototyping mode… you should be very aware of the fact that it is a prototype. This is your chance to take shortcuts, break the rules, get creative, and express your ideas on a piece of paper, in plain HTML, or perhaps you may even run ./script/generate scaffold to spit out some code that you know will not be used in a production application later on. The goal here is to figure out what direction you want to take the project and get the client to sign off on these ideas… not to build reusable and modular code. If you’re building a prototype with the goal of reusing it than it’s likely that you’re spending too much time doing it.

Just Toss It

While you might not physically toss your application into a nearby trash can, you should aknowledge and remove any attachments that you may have that suggest that the prototype was a waste of time because no reusable artifacts came out of it. It’s the ideas that are expressed here that make this time valuable. Perhaps you don’t need a prototype phase… this would mean that you know exactly what you are about to develop. If you go the route of prototyping and find it to return nothing useful… than imagine how you’d feel if you just started developing and determined that you really missed an important requirement a few weeks later.

“The physicist’s greatest tool is his wastebasket.”

- Albert Einstein

The shortcuts that you should have taken earlier have likely created too much technical debt in your code. A fresh start should be the next step. Prototyping is part of the development process but the moment you allow yourself to think that you should reuse some of the prototype in your application is when you begin to become too attached to the notion that your prototyping phase was a waste of time end energy. Go into the prototype phase knowing that reusable artifacts are not the goal of this phase. Throw it away. ;-)

“Every act of creation is first of all an act of destruction”

- Pablo Picasso

Keep The Lessons and Ideas

You don’t need to rm -rf the_prototype but you should be very honest with both yourself and your client that the prototype phase is a way to quickly express an idea or process in a both a technical (and often) visual manner.

Prototyping Generates Confidence

Clients have (many) ideas. I hate to be the one to break it to you, but it’s almost certain that they are not as confident in you as you would like to believe. Confidence evolves over time and should be nourished on a regular basis. Their ideas are important to them and they are paying you to be part of the execution of those ideas. If you even remotely sense that you are not confident in their ideas… tell them this. Prototype their ideas. It could save both you and your client a lot of time, money, and resources in the long run… especially if an idea proves to be too complicated to execute.

Ideally, this is when you both agree that this idea is a good idea and that you both understand how it will be executed. This is both a good and healthy process. :-)

Document your learnings, the changes presented by both your client and yourself, and then revisit your Use Cases.

What you are about to build is that much clearer now. This feeling of clarity is exactly why you created a prototype. Remind yourself of this.

Always Start Fresh

Now that the client and you have come to an agreement about what is to be developed… the next phase should begin.

rails the_real_app

...and remember… don’t be afraid to revisit prototyping again. If an idea is not clearly defined yet, whip up a new prototype and see what comes of it. Just keep it out of your code base…. and if it’s already happened… please Refactor. ;-)

Like I said… I am not a HTML person… reusing the colors, graphics, and html artificats that you worked on might be useful… but modular code shouldn’t fall out of a prototype.

However, prototyping is a good idea and I highly encourage it.

Prototyping can also be extremely fun!

Similar Post(s): Keeping the Code Organic, The bitter-sweet taste of agnostic database schemas