Have you seen the keynote of Stephan Frickas at the RE ’12 in Chicago? His team created a simulated environment and let real users experience prototypes to figure out, if the requirements (and the design) fit. It’s killing or curing the user centred way! 

Bill Buxton with his great book Sketching User Experiences even coined the matching terminology. It’s about sketching an experience of a world not quite real yet, letting users experience this world while doing what they assumingly will do in the future, observe them and talk to them and in this process start to understand, what the world tomorrow and the requirements really could be.

User Experience Sketching

Stephen Frickas presented a very sophisticated simulation in order to verify the outcome of agil iterations. Thus his tool operates between trees and road (see this article for stars, clouds, trees and roads). Sketching user experience is actually even more useful when killing or curing of ideas that are so brittle even the most daring agile programmer does refuse to write production code.

Do requirements help here?

So, there is this insight, the first brittle glimpse into a promising future, how to proceed? If you are more into the requirements world then you might start conducting interviews with Stakeholder, run creativity workshops with VIPs, put down a claim and start compiling a perfectly phrased feature list, that then would be formally reviewed by subject matter experts and management. Once the review passed, the product can be developed and sold.

Even while such a procedure is commonly accepted and done, it has a very specific downside. It relies on the guessing skills of those involved and how well they can anticipate how the future will look. It is however bound to fail if they don’t. If a team is dealing with something innovative on clouds or stars, then per definition, the people do not know how the future is going to be. So writing down a feature list might really be a bit wasting time.

There are several promising approaches to deal with this difficulty, the user-centered approach presented here is to create the thing as quickly as possible, let users try it, variate it and learn from it.

The famous chess automaton that entertained the upper classes in the 18th century is a wonderful illustration. People could actually play chess against a computer 250 years ago, even though the technology needed wasn’t even science fiction at that time. Just stowing away a human chess player that replaced the thinking machine was enough to create the illusion. One way of sketching user experiences is creating such an illusion with the simplest means, cardboard, scissors and pencils can even suffice to do that.

Science fiction – designing a possible tomorrow

Talking about science fiction. Science fiction books are nothing more than an experience of a future world not feasible now. Isaac Asimov’s three laws of robotics are a discussion about ethics that becomes more and more relevant for our modern society. Jules Verne in his short story “La journée d’un journaliste américain en 2889” depicted a world, where people used video telephony, solved the energy problems thanks to solar energy and one person ruled the world as a result of his monopoly of information. We’re closing in on that. Storytelling is a simple way of letting other’s experience a future world and what it could be like and start a discussion about it.

More hands-on again is this well-known example: Carrying around a block of wood, using it as it were the nifty device the inventor imagines it to be and to figure out what makes sense to use it for, is another reported technique, e.g. attributed to Jeff Hawkins when creating the initial Palm Pilot. This time it is the team experiencing what is talked about and they just try it out themselves.

Tons of examples like this exists and show how the basic process works. By making something hazy very concrete and by experiencing it, a team can start learning about what will really matter to users later. It needs creativity in how to simulate a future and what to simulate. It will however allow to write a list of requirements that do not so much rely on guessing but on experience.

A fast and effective feedback loop

A bit more theoretical background may be helpful. If methods allow for quick iterations, the team can try out several options and variations and learn about different solutions. The faster the team can interate, the better the team can learn. Second, the more reliable the results are, the more sure a team can be to have learned something relevant. And this is the major difference between creating a feature list by guessing or by experiencing a mock-up: reality.

The message is very simple: Add reality in how you’re working and you get much better results. The quicker you can iterate, the faster you get these better results. And that’s the user-centered way of killing or curing ideas along the road from stars to road and what the UX professionals do: experience the future, now!