Iterative non-functional prototyping

By Gordon Rugg

Sometimes, product development is straightforward. The client tells you what they want; you produce it; they’re happy with it, they pay you, and everything is fine. This is known in the field as the waterfall model of development; once the client has signed off on the requirements, the process then moves irrevocably onwards, like a river going over a cliff.

When you and the client are dealing with familiar territory, this approach usually works reasonably well. Sometimes, though, things don’t work that way. You’re particularly likely to hit problems when you’re developing something that’s new territory for you and/or the client.

One common problem involves the client changing their mind part-way through development.

Another involves the client being unhappy with what you produced.

Communication problems are another frequent source of trouble, with you trying to make sense of just what the client wants, and getting more and more frustrated.

If you’re in that situation, or you think there’s a risk of getting into it, you might want to try iterative non-functional prototyping. It’s a lot simpler than it sounds, and it’s a fast, cheap, efficient way of getting to the heart of what the client wants, particularly when clients don’t actually know just what they want at the start. It involves looping through mockups systematically until the requirements are clear.

This article gives a short introduction to the core concepts and the process. It should be enough to let you get started; there’s supporting material elsewhere on this blog which goes into more detail about the underpinnings, which I’ve linked to within the article.

Waterfalls and loopsbannerv1Images from Wikimedia Commons: Attributions are given at the end of this article

Continue reading

Beyond the 80:20 Principle

By Gordon Rugg, Jennifer Skillen & Colin Rigby

There’s a widely used concept called the 80:20 Principle, or the Pareto Principle, named after the decision theorist who invented it. It’s extremely useful.

In brief, across a wide range of fields, about 80% of one thing will usually come from 20% of another.

In business, for example, 80% of your revenue will come from 20% of your customers. In any sector, getting the first 80% of the job done will usually take about 20% of the resources involved; getting the last 20% of the job done will usually be much harder, and will take up 80% of the resources. The figure won’t always be exactly 80%, but it’s usually in that area. Good managers are very well aware of this issue, and keep a wary eye out for it when planning.

Here’s a diagram showing the principle. It’s pretty simple, but very powerful. However, that doesn’t mean that it’s perfect. It can actually be developed into something richer and more powerful, which is what we’ll describe in this article.

eighty twenty

Continue reading

Observation, stumbles and smiles

By Gordon Rugg

If you’re designing something that’s going to be used, as opposed to something decorative, then it’s a really good idea to make it fit for its purpose.

How can you do that? Observing the users is a good start.

“Observing” is a broad term that includes various specialised forms of observation and analysis. In this article, I’ll describe a simple way of doing basic observation of users, which involves watching out for four key alliteratively-named actions:

  • stumbles
  • scowls
  • swearwords
  • smiles

It’s simple, but it’s powerful, and it usually catches most of the main problems, and it gives you a good start towards designing something that the users will like.

Not great art, but useful: Four things to watch for in task analysisbannerv1

Sources of original images are given at the end of this article

Continue reading

Requirements, evaluation and measurement: How to tell if you’ve met a client’s goals

By Gordon Rugg

This article is part of a series about the problem of identifying and clarifying client requirements. In this article, we’ll look at the issues involved in measuring and evaluating a product, both qualitatively and quantitatively.

elephant scales

https://upload.wikimedia.org/wikipedia/commons/5/54/Elephantidae-scale.svg

Continue reading

Definitions of “good” design: User-centred design in three layers

By Gordon Rugg

Design is a subject that tends to provoke strong emotions.

It’s also a subject where people tend to have opinions that appear deeply conflicting.

This article looks at why this situation arises, and at how we can move beyond it.

800px-Bambouseraie_de_Prafrance_20100904_110

https://commons.wikimedia.org/wiki/File:Bambouseraie_de_Prafrance_20100904_110.jpg

Continue reading

Client requirements: Why clients change their minds, and what you can do about it

By Gordon Rugg

This article is one in a series about the problem of identifying and clarifying client requirements. This episode looks at why clients often appear to change their minds dramatically, and how you can handle that problem within your development process.

Readers who like the extended metaphor of the client requiring an image of an elephant might like to know that we’re continuing with it in this article. Readers for whom the novelty of that metaphor has worn thin might like to know that we won’t be using it much.

So, why do clients appear to change their minds radically? It’s often because of a very simple reason that is easy to handle.

Continue reading

Client requirements: Finding boundaries, constraints, and the shape of the elephant

By Gordon Rugg

This article is one in a series about the problem of identifying and clarifying client requirements, using the ongoing semi-humorous example of a client’s requirement for an image of an elephant. This episode looks at ways of establishing the key issues in the client’s requirements when you’re trying to trade off costs against risks.

Continue reading