08 July 2014
On Saturday twelve of us got together at The Generator in Exeter to try out a series of UX Design Games.
All the games were focussed on the project of updating the signup process for an online training business called Tapestry.
Tapestry isn’t a real project — which allowed us some free reign to make assumptions and explore some more ambitious ideas. It also highlighted difficulties in making good decisions without knowing the details about a business model or realities of a technical platform.
Attendees on the day were: @misslillybrowne, @bouncingdan, @lauranevo, @garygitton, @rupachilvers, @miriamgosling, @tomstaniford, @cycas, @Pavol, @ianmacfarlane and +Paula. And thank you to all of these people for indulging me on this experiment on a sunny Saturday!
It was reading the book Undercover User Experience Design that prompted me to run this workshop day, initially for my own interest — but it was great to see how much interest there was from other people from different disciplines wanting to find out more.
The first game we played was Design the Box. Split into small groups, the teams designed a physical box for Tapestry.
Designing the box is an opportunity to think about the business and website in a completely different context. It should help encourage greater creative thought and flag up new questions.
As with all the games it’s not about producing a beautifully designed box or even making final decisions. It’s very much a first step in the process of breaking down some preconceptions and helping stakeholders in a business recognise the benefits of asking more questions and undertaking more research to better understand customer needs.
The second game was Affinity Map or The KJ Method
In this game we focussed on the signup process for Tapestry. Everyone wrote down all the components they would expect to find on a website that would be part of what they might want to know before signing up for a paid service.
To avoid any unwanted influences, the exercise is done is silence. We spent 5 minutes writing down the components onto post-it notes before putting them all up (at random) on the wall.
It was then up to everyone to reach a silent consensus on the best set of groups for all these components. Players are encouraged to move sticky-notes from one group to another, or into new groups if they disagreed with another players decision.
What’s was interesting was how little overlap there was between components, or where there was overlap, that there were often still differences in the actual naming of the section. It highlights how little you can assume about the logical organisation of your website’s content — or the terminology you use to describe it.
Once again — this exercise is unlikely to suggest a final site architecture. It might be, for a given project, it does nothing more than demonstrate to stakeholders that they’re going to need to do a lot more work to discover a sensible content architecture for the website. Or it might be able to form a reasonable guide to base further user testing on, through card sorting or other types of early prototype.
One thing these exercises does is start off with a fairly simple overview of the project and in collaborating on ideas for design and content structure, throw up lots of additional questions.
Our third game was Mobilify — the task here was to take the signup page for the site and layout all the key components for the page in a single column — as if seen on a very basic mobile screen.
The objective is to force teams to think about the hierarchy of each element on the page.
There was some ‘creative’ interpretation of the single column — with multiple streams forming, on the basis users would see slightly different page content based on previous choices made during the signup process.
In presenting the layouts, it provoked some interesting debates about the number of options offered to users and the stages at which personal information might be required. We then worked together to agree (to some extent) on a single flow of the signup process.
The final steps were not revolutionary — but we also shed lots of ideas. Not because they were bad, but because it was recognised they shouldn’t be part of the signup form.
What the discussion also flagged up was questions over core functionality, and the recognition that it’s not possible to design some aspects of a web page without knowing more about the underlying functionality.
In a real project, these questions might be able to be answered — but it might also prove to be a point to have to discuss with developers about what can be accomplished and where problems need to be solved through programming or interface design.
For me the standout value of this exercise was seeing how easy it is for good ideas to be implemented in the wrong place.
The last game we played was six to one.
The group is split into teams of 3 or 4 and each person has to draw 6 sketches for an interface for the same page on the website (we stuck with the signup page for Tapestry). Coming up with 6 different ideas for the same page is difficult, and made more difficult still with a 10 minute deadline.
The expectation is that players will come up with the first two or three designs relatively easily, falling back on fairly conventional design approaches. But to finish six designs in the time — some of them are going to involve some very creative thought. It forces divergent thinking and will sometimes spark a revolutionary idea that would not otherwise have been uncovered.
The game outline I’d read suggested the next step should also be run individually — but I decided to ask players to work in small groups as it seemed the better ideas were being generated when people could discuss and bounce ideas off one another.
So each team spent about 20 minutes drawing up a single signup page design based on all the best ideas they’d found in the separate sketches.
Once again — the objective is to encourage people to explore new and innovative ideas that wouldn’t otherwise have been considered. An entirely new concept for a signup page might not be a great idea on a commercial website — but this process might suggest smaller innovations that can be implemented and offer a more exceptional user experience.
The teams presented an interesting diversity of interface designs, ranging from conventional and simple (which is by no means a necessarily bad thing in this context) — to much more complex and interactive. In reality I would imagine a blend of all the ideas developed here would create a highly usable and delightful signup form.
From my role facilitating on the day — it was insightful being able to listen in on the conversations between different groups. I was able to follow how seemingly small differences of opinion can lead to fairly significant differences in design solutions.
It serves to highlight that while many years experience of UX design can allow you to implement delightful solutions — your own experience alone is not enough. Every project should be started with some research and discovery with both client and users, it always throws up some unexpected requirements that past experience alone would not have helped you identify.