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

Advertisements

Getting an overview of the literature via review articles

By Gordon Rugg

Review articles are an extremely useful resource when you’re starting a literature review, and when you’re about to start some new research. However, most students have never heard of them.

In today’s article, I’ll describe what they are, how to find them, and why they’re so useful.

Continue reading

Finding the right references, part 2: Getting a first overview

By Gordon Rugg

In a previous article, I looked at some issues that affect how and why finding the right academic references can be difficult. In today’s article, I’ll look at how to set about finding those references, beginning with the familiar problem of reading lists.

Some lecturers supply reading lists; others don’t.

Reading lists can be very comforting, because someone else has already done the thinking for you, and has told you what you need to know. There’s also the nice implicit message that you only need to know what’s on that list, so there’s a limit to the work ahead.

It’s a comforting feeling while it lasts, but there’s usually a small voice at the back of your mind asking what will happen when you leave university and enter a world where nobody is likely to give you a reassuring list of the things that you need to know.

Which brings us back to the lecturers who don’t supply reading lists, and who expect you to find information for yourself, with only a few words of guidance, such as “Weber’s work on bureaucracies is the place to start” or “Good question; that’s a classic sociotechnical problem”.

Where do you go from that sort of start? Your friendly librarians will usually be very happy to give you good advice about how to locate information online, and often, that advice will find you exactly what you want. However, there are some other quick and dirty methods that you might find useful. They’re what this article is about.

Continue reading

Design Rationale, part 1: A tale of reasons, raccoons and cat flaps

By Gordon Rugg

Often, a small example can give key insights into bigger, deeper questions. The saga of our cat flap is one of those cases. It’s an apparently trivial problem that leads swiftly into important, difficult questions like how to tackle design decisions, and how to identify design options that you might easily have overlooked, and how to spot design problems in the first place.

That’s how we ended up as one of the few the families in England to have a raccoon flap in their back door, rather than a cat flap. It’s an excellent example of design rationale – the reasoning behind a particular design decision. Like most problems involving design solutions to client requirements, it takes us into the difficult territory where human beings have trouble establishing just what they want and why they want it, and where designers are trying to find a way of tackling the problem that’s systematic but that can also capture the often messy requirements and constraints affecting a particular problem.

I’ll tell the cat flap story first, and then work through the insights that it gives about design rationale.

Continue reading

The observational techniques

By Gordon Rugg

Sometimes you can get the information you want via interviews and questionnaires. Often, though, you can’t.

For instance, if you want to know how long the average visitor spends on your website before leaving it, or what percentage of the population don’t have current car tax displayed in their car, or just how a skilled tennis player holds the racquet for a forehand, then interviews and questionnaires won’t get you very far.

In cases like the ones above, you’re trying to find out what people actually do, as opposed to what they say that they do.

There are various techniques that can be used for this. I’ve grouped them together under the label of “observational techniques”.

Continue reading

Our main posts: An overview by topic

By Gordon Rugg

This article gives an overvew of our posts so far on three main areas.

Two of these are about research methods and development methods, namely elicitation methods for gathering client requirements, and systematic approaches to visualising information.

The third area involves our Verifier approach for tackling long-standing problems, which we’ve applied to the Voynich Manuscript and to the D’Agapeyeff Cipher.

All the material listed below is copyleft Hyde & Rugg; you’re welcome to use it for any non-commercial purpose (including lectures) provided that you include the “copyleft Hyde & Rugg” acknowledgement with any material you use.

Gathering and clarifying client requirements

We’re posting a series of tutorial articles on a wide range of methods, and articles about the bigger picture of requirements gathering. The main articles that we’re posted so far are as follows.

Continue reading

Knowing the unknowable, revisited: Why clients can’t know their requirements, and some ways to fix the problem

By Gordon Rugg

Why don’t clients and customers make their mind up about what they want?

There are several reasons, all of which make sense in hindsight, but that aren’t immediately obvious.

This article is a short introduction to one of those reasons, that can be handled swiftly, cheaply and easily. I’ll return to this topic in more depth in later articles.

Continue reading