Ever since I first saw The Apprentice, I have secretly yearned to be a contestant on the show. It’s not being on TV that appeals, nor the prospect of sitting in a pretend meeting room whilst a small angry man shouts obnoxious remarks at me. Rather, I just want to have a go at the team assignments and see if I could do any better than the chaotic attempts we see on screen.
Unfortunately, anyone with work to do, or a desire to retain any sort of respect in the eyes of others, cannot really go on The Apprentice. This is why I was very pleased to try out my potential Apprentice skills in the safety of a classroom.
Our ‘Lord Sugar’ was significantly less intimidating, in the guise of former Apple genius Bruce “Tog” Tognazzini (http://asktog.com). Over a period of three days, Tog taught us the fundaments of usability design and ran practical exercises that made a high-speed demonstration of the design process, from gathering requirements, to brainstorming, designing and prototyping, and basic user testing.
The scenario was about addressing concerns over the declining numbers of private pilots in the US. How could we develop a usable product or system that would help make flying more accessible or enjoyable? We started by interviewing a government official (Tog in a hat), then interviewed a pilot (Tog in a hat), and finally interviewed the pilot’s wife (less convincing, but yes another hat), to identify potential user requirements. We were then led through two structured brainstorming sessions to identify solutions and create basic system architecture and design, applying the usability fundaments learned during the lectures.
Whilst requirements gathering and wire framing are a standard part of my work, the next part of the challenge was new to me, and I cannot wait to put this technique into practice with my clients.
Paper prototyping is a process whereby you make simple paper wireframes or mock-ups of your system design and test them with real users before even starting development. The idea is that you can be certain that the workflow and interface layout is usable before its too late to change it.
It is an agile way of testing a product before you have even started making it, so you can be confident that the product will work from the very start. And its great fun – one person gets to play ‘the computer’ and has a set of screens, pop-ups, dialogue boxes etc to put down on the table in front of the user as the user interacts with the hand-drawn interface.
So during our brainstorming sessions, our team (Tim, Gabriella, Fairoz, Wanbun and me) designed an application that could be used by pilots and co-pilots in-flight when they hit rough weather and had to re-plan their itinerary. I think our concept was fairly good, but having only 30 minutes to consider our design and make our paper prototype meant the realisation of the concept was pretty ropey to be honest.
Our design consisted of a map with restaurant packages attached to various airports, which could be selected and then tailored with different restaurants, hire cars etc on the second screen. The task we gave our participant in the user test was:
“Get a suggestion of where to go. Tailor the suggestion by choosing an alternative restaurant serving Spanish food”
This was the only instruction our user was given, and sadly she had no idea how to use the interface and struggled to complete the task. This reflected very badly on our design! However – and this is really the point of the process – we found this out very cheaply and easily, before anyone had started coding any computer systems. Compare that to including user testing right at the end of a project and realising at the 11th hour that your system is completely unusable, and you can see the enormous potential that this method has in developing usable and useful software. In the real world you would spend more than 30 minutes making your designs of course, and you would go through multiple rapid iterations to reach a usable design, changing the design and retesting again and again (rather than just giving up after the first test!). You may even test and iteratively develop multiple designs at the same time to reach the goal faster.
So all in all I think the exercise was a real eye-opener. Our user did not think in the way we expected her to or visualise the screens in the way we anticipated. I think next time I watch The Apprentice I am going to have a little more sympathy for the teams as they bumble through the tasks producing ill-thought-through products. I now realise that working that quickly with a team of people you hardly know is really challenging even when you have a highly skilled, co-operative team.
