I had a diverse and interesting week this week. I spent the beginning of the week jumping between writing up a few academic papers and intensively writing a new app for my research using the Flickr API. The end of the week was rather different with the latest IT as a Utility workshop “Design approaches for IT Utilities: a two day quest for the optimum interaction design models for IT utilities”. The first day was rather strange for me as it was held at the IBM South Bank location and I found myself sat with IBM folk from my old team! They explained how user experience design is changing within IBM and discussed familiar issues around UCD in such a large developer led organisation. Very different presentations were given by the participants from SmartLabs who bring a much more user centred perspective with a focus on accessibility and diversity. The rest of the time was spent in various discussions stemming from questions raised by the presentations.
The second day of the workshop was hosted by ustwo at the Tea building. This day could not have been more different, with a very interactive hands on activity demonstrating the user centred design process that is used at ustwo. The differences started with the location. Having visited a few IBM locations around the world, South Bank tries hard to be interesting, but is still rather grey and tired looking. The ustwo offices in contrast were interesting to be in, a bit quirky, colourful, with many things to look at, and seems like a good reflection of the personality and culture of the team.
Going into the day I wasn’t quite sure what we were going to be doing, but it soon became apparent that we were going to be doing a design and prototyping exercise. In itself not anything new, I’ve done all of the activities when helping to design new features or interfaces on different projects, but I’ve never actually done it in quite those circumstances. We were split into groups of 3 and each group was given their own brief based upon real customer examples. What was fun about these though was the high level of the briefs. The briefs were for mobile apps and covered real world problems or ideas that could be easily understood, rather than the much more technical complex and vague requirements that come with working in a deeply technical or abstract environment.
Our brief was to create an app that could help users to report problems they see on the transport network and track those problems. The first step was to create a persona based only on a photograph and to create an empathy map based on her thoughts, feelings, and what she sees, hears and wants. We created the persona Natalie, who is a 27 year old high-flying TV director living in Chelsea. She commutes to work every day using train and buses, has a boyfriend who also travels. We came up with different problems that she might see, what she would think about them and what she would do. Because we were very focused on her problems we ended up with some quite dark thoughts about the kinds of problems she might want to report and how she felt about them. But we also came up with lots of ideas at this stage about what an app might be able to do to help.
The next stage was to decide how the business goals mapped to the user goals and determine what the UX principles would be for designing the app. I found this task a little tricky because of the ambiguity of the business goals. Actually a very real world problem. I felt that changing the language used would help to clarify what the customer wanted and how that would relate to what the user wanted. It also made me realise that my dominant user focused perspective I find it slightly difficult to change perspective to put the business needs above those of the user. Doing the right thing is of course a balance!
The next stage was to storyboard. We decided to storyboard different scenarios that we could use in our prototyping individually and then vote on the best one to take forward. Our three scenarios included different features that the app could do, such as notifying a friend if you raise a problem indicating a delay and how you could check the transport route you intend to use for problems and then choose a different route. The scenario we chose to take forward was the simplest example, which was to have the user report a blocked toilet on a train. The problem is successfully reported and a cleaner is sent to solve the problem at the next station.
The next step was to generate the task flow for the user from the chosen scenario. This included the messages that the user would receive from the app as well as the taps and decisions that the user would make within the app.
The next step was to construct paper prototypes of the app using a mixture of drawing and cutting and gluing pre-created icons and user interface elements. The screens on the paper prototypes were used to create interactive prototypes on an iPhone using a rather cool bit of free software called POP. Using pop you can photograph the prototypes and then add hot spots to the photos and link them to other screens. When you ‘Play’ the prototype a user can click on the parts of the screen to make the app move to the next appropriate screen. If they click on something that isn’t linked the software shows the hot spots so they are not completely stuck. Once we had created the prototype we moved onto user testing.
For user testing we swapped round a bit and had 2 testers for each team, one at a time. I got to be a tester for another team testing a pill-taking app. I’ve done lots of usability testing as the interviewer or observer, but only a few times as the test subject. It is always great fun and I enjoy giving feedback, although being careful about telling them what I would expect and why rather than telling them how I think they should design whatever I’m testing! For our app we had lots of good feedback, mostly ideas rather than issues, which is what you would hope with two designers on the team! The limitations of mobile (and platform familiarity) for the design is where we had differences of opinion – it was tricky to keep the complexity down – putting too much on a single page or having an extra page for the user to wade through. This is where paper prototyping is brilliant though, because not only can you throw away what you already did, but you can create different designs and see how they work at the same time and very rapidly.
With the changes made on paper, the POP prototype was updated. And then we were ready to share our story with the wider team.
The day ended with a beer and some great and creative discussions with members of ustwo and the other workshop participants. As well as the very strong user focus, I was also impressed by the creativity and broad thinking I saw at ustwo. Quite a contrast to the other ‘new media’ companies that I have visited in the last couple of years that seem to be all about marketing and swishy graphics!
All in all a fun and inspiring day.