The key aim of the resulting work is to initiate the design of a product's user interface as early on in the product development process as possible. This involves lots of user testing on prototypes of increasing fidelity to assess the overall functionality and to ensure the final product is functional and easy to use.
But the problem with this has always been a case of the proverbial chicken and its egg. Product development of electronic interfaces have typically been tackled from a 'bottom up' approach, whereby the inner workings of the device is developed first, then tested, and then case and interface built around it. That is partly because in the past very little could be tested until something usable was made; how can someone fully test how easy a mobile phone is to use without a working mobile phone?
The problem with this bottom up approach is that even once the electronics is all working and being tested by a focus group of 'end users', it becomes very difficult and expensive to then alter all those electronic parts and functionality once it's found that none of the users can use it. So sacrifices are made, and more often than not its the usability that suffers.
The alternative method is from a 'top down' approach, where the design, usability and interface are all but defined at the start and then the technology built in afterwards. The work Steve and PAIPR are doing provides the tools that allow this approach to work.
Several tools and systems have come out of the work at Cardiff. One of them is called the IE4 (pictured above). This is a small, battery powered device, which on its own is no bigger than a small pack of matches. As the name suggests, the IE4 is in its forth generation after nearly 10 years of development. It contains a Bluetooth module and has a 20-pin connection at the back along with a breakout-board to make it easier to work with in the early stages of prototyping.
|The IE4 interface Prototyping tool|
The device works by simply connecting to a computer via Bluetooth and acting as a control device, such as a mouse or keyboard. The inputs can be added to the pins of the IE4 in the form of buttons, sliders, joysticks, sensors or other input components. These can then be arranged on the surface of a to scale appearance model with the IE4 neatly tucked inside of it out of the way.
The computer reads the inputs as mouse movements or keyboard presses, and these can be configured to trigger on-screen actions such as menu systems, animations or control dragable objects. In theory anything can be controlled, and the complexity and difficulty of the virtual mock-up is determined only by how far you want to take the simulation and what program you use to do it. You can make something quite complex in Adobe Flash, or save time but still get a decent result in something such as Microsoft PowerPoint.
|Photo from paipr.wordpress.com|
The IE4 allows you to create devices that are meant to control virtual interfaces wirelessly from a distance, or just use the computer screen as an effective example of how a screen built into the device would respond - all while being able to quickly build and test mock-ups that effectively trial interface designs of a product.
The facilities for user-centred design testing and analysis at Cardiff are very good. They even have a room which contains 4 HD cameras focused at one desk in the middle of the room. Scenes and scenarios can be set up and users or focus groups can test products and prototypes while being monitored remotely from a room elsewhere in the building. As well as simply recording the actions visually onto tape, data can be collected indicating things like the number of time certain controls were used, or time the user spent reading each menu screen. This gives designers and clients a very detailed analysis of the performance of any one interface.
The work done at Cardiff is very applicable to my work and I can learn much from it. It has made me think much about the kind of prototyping I am trying to teach with my resources. A prototype can come in many forms, not just a polished, fully to scale, working model that fully represents the finished product, but it can also be an off-cut of polystyrene foam formed roughly to fit in a human hand. And from a usability perspective, there is no reason why as much can be learned from the latter as the former.
Questions arise over the real purpose of a prototype, and what information we as designers need to get from them. Does the test user even have to control the device themselves? What if they only think they are controlling the device, and actually someone else is manipulating the prototype like a puppet, reacting to what the user does. This technique, dubbed the 'Wizard of Oz' method, is very powerful because the 'puppeteer' can control the system in real time, react to the user and simulate as many different scenarios as he or she likes without stopping the simulation to alter the prototype. They can throw in bugs, alternate routes navigation or different functions very quickly without the test subject knowing any different.
Shouldn't we be teaching designers the most effective ways of prototyping for designing and then support it with the necessary electronics and interface design skills? Rather than teach them that the polished end product is really the only real kind of prototype, when really its just the one that would matter in a sales meeting.