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

Intrinsic, extrinsic, and the magic of association

By Gordon Rugg

As regular readers of this blog will know, I have an awed respect for the ability of Ancient Greek philosophers to spot a really important point, and to then produce an extremely plausible but only partially correct explanation, sending everyone else off in the wrong direction for the next couple of thousand years.

Today’s article is about one of those points, where the Ancient Greeks didn’t actually get anything wrong, but where they laid out a concept that’s only part of the story. It involves a concept that can be very useful for making sense of consumer preferences and life choices, namely the difference between intrinsic properties in the broad sense, and extrinsic properties in the broad sense.

Here’s an example. The image below shows a pair of Zippo lighters. One of them is worth a few dollars; the other is worth tens of thousands of dollars, even though it’s physically indistinguishable from the first one. Why the difference? The answer is below…

zippo banner

Image source: Continue reading

New Hyde and Rugg website

By Gordon Rugg

The new version of the Hyde & Rugg website is now live, here:

Among other things, it contains a resource section which pulls together our articles on a range of topics, including academic craft skills for students, elicitation methods, requirements, design, and education theory.

There’s also a section about our research, plus a section on the codes we’ve worked on. Again, these pull together our previous blog articles into a structured framework.

Over the next few months, we’ll be adding more material, particularly in the sections on academic craft skills and on our research.

We hope that you’ll find the site a useful complement to this blog.


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

People in architectural drawings, part 6; conclusion

By Gordon Rugg

This article is the last in a short series about finding out what people really want. I’ve explored that topic via discussion of idealised dream buildings, to see what regularities emerge and what insights they provide into people’s dreams and desires.

In today’s article, I’ll pull together strands from those discussions, and see what patterns emerge.

part6 banner

Detail from: “Neuschwanstein Castle above the clouds” by Arto Teräs – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons –
Continue reading

Mapping smiles and stumbles

By Gordon Rugg

In a previous article, I looked at ways of systematically recording indicators of problems and successes with a design. In that article, I focused on the indicators, with only a brief description of how you could record them.

Today’s article gives a more detailed description of ways of recording those indicators, using the worked example of a building entrance.

The worked example is, ironically, the Humanitarian Building. Here’s the Wikipedia image for its entrance.


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