My previous post on user experience methodology was on wireframing. I described my preferred method of sketching, or ‘low–fidelity wireframing’ (or the appropriate fidelity of wireframing’, depending on how you look at it). I wrote that wireframing should be quick, throwaway, collaborative and iterative: the first step in a process leading on to the much more serious business of prototyping.
I ended that post with the caveat that UX methodology should be flexible in its focus and scope. Beware of those who preach a unified prescriptive UX or design methodology! Product or service, client and end user: all change, however subtly, with every project. Understanding and adapting to this is vital. As Bill Buxton puts it:
“There may be as many approaches to sketching interaction as there are products to design.”*
How we approach prototyping at HighWire is defined by the nature of our content platform. Our platform is set up to enable our front end developers to take a concept from our UX team and quickly implement it into a working prototype. These concepts could be expressed through sketches on post-it notes, high fidelity Photoshop mockups or simple interactive wireframes built in HTML. What is important is the speed in which they can be turned into a working prototype in context with all the other elements and features our platform provides, ready for testing, either by a group of users or our own QA department.
Data, data, data
Another great advantage of prototyping on our platform is that we can easily load our clients data sets. By supporting standard markup definitions such as NLM (JATS), TEI and DocBook we can quickly load client data into our platform. By mapping each of these standard markups into a defined standard for metadata (Dublin Core) we have a solid basis on which to build features without having to worry about the original encoding of the data. This even comes in useful when loading data that is not in a supported standard, as we just have to perform a mapping from the supplied data into Dublin Core and it will then load into our platform.
Once loaded, we can perform quick data analysis using the Apache Solr search index. This enables us to pull out lists of values from the data and spot anomalous values. So as well as being able to quickly realise concepts from our UX team, we can also quickly see how our clients data is being displayed. From my point of view as a UX practitioner having access to client data early on in a projects lifecycle is invaluable. Our user testing activities – A/B or comparative testing, task based user testing and so on – all benefit by being able to put an accurate simulation of the end product in front of our testers.
Paper is best
It‘s not all about code and data and our prototyping activities are not restricted to our platform. We sometimes do a little paper prototyping, mainly around specific UI considerations. How an advanced search unit could work across different platforms with different data sets, for example. By moving and folding paper and making simple drawers, windows or sliders we can quickly get a feel of how an interactive element behaves. I have always been a fan of this ‘low fidelity’ approach (as you might be able to tell). I see paper prototyping like this as a simple extension of the sketchbook activity any decent interactive designer or UX professional undertakes.
I have also had the pleasure of working with a game designer by the name of Ciaran O’Connor. Ciaran is a fan of paper prototyping for the testing of game mechanics – playing with Ciaran’s paper prototypes was always an insightful exercise. Issues in game mechanics that would previously only be evident on playing a build of the game could now be identified and ironed out at a much earlier stage. But what was really interesting to me was not the problem solving, but ideas for the addition of extra features that resulted from ‘playing’ the prototype. So the power of ‘playing’ a paper version of a digital game was twofold – a method of identifying and solving issues and as a creative tool for improvements and embellishments.
So at HighWire we are lucky to be able to rapidly prototype on an existing responsive platform with real client data, across a variety of devices. Without the usual fidelity issues and by using our clients content we can serve up a much more authentic experience for the user groups we test on.
We also see the value in simple interactive prototypes and paper prototyping for testing interface functionality. And with all our prototyping methods the aim is not only to detect and fix problems, but to see opportunities for the future development of our products and features.
A final comment – we also try not to get hung up on deliverables – we don’t fetishise the process. What is of real interest is the user insight we can gather and how quickly we can add that insight into our production processes.