Distracted by Shiny Things

This blog likes to talk about ways to improve your chances of delivering a successful software project.  One of our mantras is the use of software prototyping, but a recent conversation got me questioning whether building a software prototype might end up creating its own problems.

“Whoa!” I hear you cry.  Take a second to pick yourself up the floor; calling prototyping a liability on a site hosted at softwareprototyping.net might seem like a rather chilly day in hell.  And you’d probably be right, but I try to present the upsides and the downsides with a (relatively) impartial hat on.  Or at least that’s the plan.

So, software prototyping creating its own problems?  Surely some mistake?

Well, to answer the question: generally, no, software prototyping is usually a highly effective way of steering the early stages of a software project, therefore increasing your chances of success.

However, if we widen our brief and consider requirements prototyping – i.e. the use of prototyping techniques as a core part of the analysis and specification of a new system – we hit across a small problem.

This is illustrated best with the story of Jeff*, at the time a divisional director in a large financial organisation.

I was involved in the design of a considerably wide-scoped prototype.

Using the techniques of requirements prototyping, I was able to bring in feedback from users, stakeholders and technical analysts to help shape the design.  This was going rather well; hard work but with each revision showing real progress towards a killer design.  Along the way, however, Jeff started to sniff around in an example of classic hit-and-run micromanagement.

Despite concentrating on building up the shape of user journeys, exploring the effectiveness of our interface and so forth, Jeff really wanted us to devote our time to ‘making it look just fantastic‘.  Which, unfortunately, involved endless fiddly adjustment to such things as the precise placement of fields, the exact colour of text, whether this image looked professional enough and so on.  All very interesting, but somewhat missing the point of the prototyping process.  All this served to do was divert significant time and effort into polishing the finest details of a prototype whose main purpose lay elsewhere.

On reflection, and in Jeff’s defence, it was pretty clear that he believed in making everything look as slick and professional as possible.  He knew that the project could gain support from his superiors only if the prototype gave the illusion of completeness, and so in a way he was right to push for consistency and professionalism in the appearance.

Our failing (as a project) was in letting him do this at far too early a stage.  After all, we hadn’t decided if we were going with User Details Capture Journey A, B, C or D at that point, so polishing them all to a high gloss was always going to be overkill.

What I learned from this was that the production of any tangible output – be it a paper design or a full interactive prototype – invites attention from those who don’t understand its role, its place.  Even though they may be senior, important people, they may not be important to the project itself.

Sometimes, these people get distracted by shiny things, colours, minor details.  This isn’t a problem if they remain as observers or on the fringes of the project, but can be a serious risk if they attempt to push their way into the proceedings.  As prototyping practitioners, such people really slow down the responsiveness of the prototyping process and dilute the benefits of prototyping.  In other words, these people cause more harm than good.

The skill is recognising these people and finding a way to either educate them to the purpose of the prototype or reducing their involvement/exposure to the team.  If they really must have their fully polished, ‘slick’ design ideas visualised, then at least explain to them that it simply isn’t realistic to do this over the entire prototype.  Offer to ‘polish’ up a portion of the prototype once the fundamentals are stable.  In other words, don’t wallpaper the living room until you’ve finished building the walls…

As a final word, don’t take this article as a negative reflection on the use of software prototyping techniques – there are far more benefits than drawbacks…

* name changed to save on blushes and prospective lawsuits…

Here are some links to other articles which might be of some interest if you want to know when software prototyping is appropriate:

About John Clark

My name is John Clark and I previously ran a software house called Reynard Thomson, from which this blog originally grew. In the meantime, we launched a video-based user testing service (Kupima) which didn't really take off, and I have since moved into a new field specialising on software-based research & development consultancy. I'm active on LinkedIn, and would love to connect to anyone who has an interest in software prototyping or R&D: http://uk.linkedin.com/in/jtclarkuk/
This entry was posted in General Business, Prototyping and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>