Personas, prototyping & usability testing

How many times has someone told me (non-techie)… oh but this should only take so long and how wrong they were. I have also been in various situations where prototypes are formed from a programmers mind to present information because they have not had a spec. Most prototypes I have been involved in have gone to production, more often than not. There are even those times where one internal person sits and thinks up a design spec and then gives it to the developers to implement. Most of these projects have high support costs associated with them and have frequently changing requirements.

The most effective projects I have been involved in have been those that have been designed by a professional outside company. Why? They do proper usability testing of their designs I suspect. If you do not have the funds to get professional help in design or… you have a development team that has to do everything (more common), then it should be up to the team to participate in some proper usability testing. It will further increase the time… but the after-market support should be less. What are some of these tools.


Think of a person and describe their characteristics that define him/her. Maybe even include a paragraph about what that persons typical day is like. What you have effectively done is create a persona. What helps in design is to think about different segmented markets as personas. It has various problems with it, but still works as a very effective tool in formulating discussions and making progress in effective design.

Personas should:

  • be edge cases. They are extremes.
  • have a face. To give some connection to the persona.
  • have sliders for opposing characteristics. To say how much they like X or are outgoing, etc.
  • be visual. It is important to keep things simple
The reason you have personas is to aid in helping develop and detail a scenario. Remember the rule of seven when developing personas and their defining attributes.



Once you have some personas, you can work on developing scenarios. Scenarios include information about goals, expectations, motivations, actions and reactions of your personas. They are used for functional requirements. Similar to use cases.


Prototypes should not be software prototypes in the first phase of the project. They are expensive and time consuming. Do a paper based layout, which is quick to make and quick to destroy. One day of writing on paper costs far less than a week of software prototyping. The paper based prototype can also be used to test with user groups.

Once a paper based prototype has been confirmed and is getting difficult to manage, move it over to some prototyping interface tool in software. It will take longer but will be functional and easier to roll out to more user groups or larger ones. You can also get a better feel for how things progress from one state to another.

Only after this last stage should you progress to a more solid software prototype.

Few things to note with prototyping:

  • User requirements will change frequently as you present them with designs (cheaper on paper)
  • Paper is lean in comparison to software.
  • Document why things are wrong. This is to highlight future design concerns and to document why things changed.
  • You want to be wrong more than you want to be right. It gives a far better understanding of the system.
  • Avoid illusions of greatness in your design. It is easy to believe that your design is perfect and it will work. You are only one persona… Be accepting to dropping and modifying your design.

Divergent vs. Convergent thinking

It is important during the process of prototyping to distinguish which thinking paradigm you are currently in. Divergent thinking is coming up as many ideas as you can. Keep the weird ones and work with them. You must refrain from convergent thinking when you are thinking of ideas. Convergent thinking is where you refine and narrow your ideas down to a few. Too often people try to do both. Whilst you are developing ideas you are trying to refine them. It is important to get your team or yourself to understand that now is the time to think divergently and not to critique and refine. It will be more productive if you do.

Remember to continuously refine after each stage of divergent thinking. If you do not, you will end up with a major mess that you have to work with going forward. It will  become difficult to maintain the momentum and be difficult to convey what your thinking is. There needs to be defined time allocation to both and complexity should only be reduced in a convergent step.


There are various things you should consider when testing your prototypes.

  • DO NOT test your own homework. Get other people to test your design.
  • DO NOT intervene during testing. It is very tempting, but you are an observer. Let the person think out loud for a count of 30 before intervening.
  • Refrain from answering the questions that are posed your way. The person needs to figure it out for themselves. You will not be there to hold your real users hands.
  • Use different testers for each test. This will prevent your testers from learning the system and accepting “better than before” mindsets.
  • Avoid illusion of greatness. Remember there are no such things as perfect prototypes. They can and may be shoddy.
  • You want to fail fast coupled with iterative testing.
This is a lot of work. It is time consuming. But it will really save a large amount of time when the product is being developed and when it goes live. There are major cost savings that can come from this approach. If you do not have the resources to continuosly test, then try to do it at least once. You will gain the most benefits near the beginning of the project, but never forget the accuracy you can get from testing later. Ideally you want to test continuously throughout the process, but practically you might only be able to test at the beginning and the pre-release of the product. How often do you test?