Entries in user experience (2)

Friday
May132011

paper prototype

Paper prototype is a usual method used in testing design concept with end user. It is often recommended to designer as there is not much technique barrier - paper, scissors, pens for drawing and post-it notes are pretty enough for the task. I used paper-prototype in different contexts: signage design, web design and even in writing and teaching.

For those who are not familiar with the concept, here is a fairly self-explain YouTube video:

My recent paper prototype test was last week, testing two sets of user journey for a client project. The functionality is relatively simple; the focus is mainly on how user may read different elements on a screen and what their expectations are after finishing task on each screen.

 

Some reflections here: 

  1. think of realistic test stories and a lot of them
    Like any type of testing methods, paper prototype is only one of a set of tools to interact with your participant and probe information. Paper prototype lets the user to experience a story and try to interact with the proposed system in means as intuitive to them as possible. Good setting allows participant to really engage with the story you propose, thus, may leads to more validate test results.

    For example, I tested a jounry happens after the user purchased a number of things from one place. So my example is Tesco, and I mocked up a Tesco shopping list to help user to get themselves into the role and related the test case to their normal daily interactions, even though the test itself has nothing to do with Tesco.

    Prepare for a number of story lines, and make sure your design template is flexible enough to allow different scenario to happen naturally. Make a lot of small bits that can be replaced quickly is a good tip, also, maybe colour code different bits according to different storylines so you won’t lose count during the test.

  2. pilot with a number of people before go out to real test
    Test the test - this may sounds a bit funny but really key. I piloted it with 4 before I move on to real users, and again this is a very small test I did. In pilots, you learn two things (at least): 1) get familiar with your script. Especially while testing complicated tasks playing the role of a system and record user interaction as a solo tester requires a number of rehearse; 2) it reveals user reaction that you have not covered in the script. As designer, we become blind to the interface we designed. It always takes someone else to spot the most stupid mistakes. Also, it gives the tester a chance get a sense of how user might wish to interact with your setting and how easy they can follow your script. Do they wish to write or draw on your prototype? Would you need different colour coded paper for different path? Pilot gives you chance to think and learn by doing.

  3. prepare for extra sketch on the set
    No matter how well you prepare, there will be things pop up totally off the script. If the user suggested some interaction that I have not considered, then extra paper for sketch some scenario on the set might be helpful. I actually like these moments, as it is often very inspirations moments. I prefer to let these moment push the boundary a bit – letting user dominant the story and play along with the participant until we are seriously off the script. That is when the meaty stuff comes out. Forcing participants back to the script can make good test efficiency, but it might stop them from telling me what they honestly think, and start to treat the session as test to themselves - which should never be the point of any type of user testing. Again, a balance tricky for any tester, often the situation depend whether it is as inspirational piece you are working on, or you just want a clear answer: A or B?

  4. think carefully about how to collect and record user feedback 
    To be honest, I did not film my test often, sometimes due to short preparation time and more often I knew I won't have time to go through them afterwards. But if it is a piece of work involves different tester and might require review in the future, filming is always worth it. Personally, I find that I try to listen more carefully if I know there won't be a chance to go through the interview/session again. Well, I know many won’t agree and I welcome debate... What I do think any tester should spend some good time consider carefully before going into a test is how you want to let your participant give you feedback.

    Some prefer to test in silence because it represents a more realistic and objective interaction a user can have with the system. It allows the user to make decisions without influence from the tester. Then tester and participant can have an review on the session and ask couple of questions to clarify certain points. I tend to use probe questions during the test, but try not to give away too much answers in the conversations. I found these small talks build a trust between the participant and tester, thus they tend to reveal more about their doubts and thoughts. Whichever way, make as less influence on participant’s decision-making as possible.

    Personally, I likes to make small notes on the set, even when there are filming on set, to remind myself of ideas or to check out certain point user rise. Also, I put aside a lot time after each test to make reflective notes. For estimate, a 20 minute test, I will leave at least 10 minutes for notes taking after each session when my memory is still fresh and stimulated by the conversations. If there is a queue of participants, don’t forget to count the note-making time in.

  5. reduce information noise
    Remove elements from the paper prototype that will distract participants. Having said that I would let user go off the script, it does not mean let things get in the way. Paper prototype is so easy to create, it is hard to resist the attempt to add another link somewhere on page, even if you have not thought through what that link does or why it is on that particular page… reduce information noise sounds like a tricky business, but actually really easy to be spotted in pilot test, and all you need is to cut things off the page!

 

 I am no expert in paper prototyping, but I picked it up totally by accident thanks to student project I did back in my Masters at Dundee University. For those who wants to look more into this as a technique, Wikipedia is a good place to start. There is also a book devoted for this one technique. Also, it appears often here and there in all sorts of collection of design tools: e.g. Service Design Tools <- my favourite!

Also, found this brilliant step-by-step how to make your iPhone paper prototype – can’t wait to try out so give me a iPhone project please :)

My colleague just showed me this fab little toolkit for paper prototyping from UXPin  - I am happy with my post-it notes, but their kit does look very professional!

Tuesday
Dec072010

A life swinging between UX and SD

Think I really should reflect a bit more on my life after join LBi and my swing between the worlds of UX (User Experience design) and SD (Service Design) till this point. I was introduced to various UX events and presentations by my dearest colleagues. It's been definitely a wonderful journey so far working in big agency like LBi, but what I am sharing here is more of personal reflections on the relation and differences between SD and UX - the two design disciplines which both claim to concern mostly with people and experience.

First thing I notice, is the use of language. For example, the use of 'User Experience'. When I start hanging out in the UX crowds, I realise we are talking about 'user experience on digital devices' in most cases, but substituted with the word 'User Experience'. While in SD, 'User Experience' stands for a more holistic concept that involves inter-person interaction and how individual interaction with their communities in real world. On the surface, it seems just a use of word, but the meaning we give to words defines our perception of the world around and our roles. Of course, it is fare enough that every discipline has its own (yet interrelated) definition of certain word, as far as we are aware of these limits in inter-disciplinary communications.

Couple of weeks ago, I ran an internal session with a group of UX designers at LBi, looking at the three roles of service designer and link it to stories in UX design. For the session, I modified the term into Navigators, Facilitators and Maker to fit their specific vocabulary ( For original concepts on these design roles, please see the summary of my thesis ) We had some fantastic discussions about what in Service Design practice might be meaningful for UX designers. Again communication came up, along with language, such as ‘Do we need to have MBAs (to be strategist)?’

(more picture from Flickr)

A second thing I notice is this emerging ‘schools of thinking’ in both SD and UX. Both disciplines have people from different types of training or professional practice. Individual who works under the same job title might have completely different approach. It is not the different personality types I am talking about here (which you get often in team-building exercises).  It is a school of thinking that people brings with them this belief of what their profession is all about. This hugely impact how people prioritise activities. A behaviour science training UX designer might put more emphasis on analysing the basics than a UX designer from a developer’s background who is happier to ‘fail quickly to succeed fast’ with assumptions. It can be frustration. And it can be confusing for client who has experience working with one type but not the other. The practitioners in these situations may find it hard to describe what they are experiencing, but it exists and should be acknowledged.

A third point is regarding the methods we can borrow from each other. Three month habiting in UX world has opened my eyes to the secret beauty of statistics and quantitative methods (while used properly). I was impressed by the conscious efforts put into balancing the use of qualitative and quantitative methods in understanding and solving problems. Qualitative methods have been in favour by designers for many obvious reasons – rich, engaging and do not ask for good mathematical skills. Yet, I feel the need to justify the use of quantitative methods in Service Design to create a more hybrid approach. Thanks to the very talented media and SEO team, I was shown how quantitative data can serve as an effective tool in monitoring prototyping process and estimating its impact on user behaviour (people don't always do what they say). Imagine how traditional techniques like A/B test and multivariate test can actually mimic in real life scenarios or in physical service ecology. It might seems terribly rigorous at first, but I believe there is value to bring in some sort of modified version of quantitative methods for the use of Service Design. It can then provide good argument in measuring and support business decisions for the stakeholders who are more figures sensitive. UX has been juggling user research for a fairly long time and has learned a lot from other disciplines such as science and arts. Looking into how they have balanced different methods in exploring and measuring digital solutions, it is inspiring to combine the best of the two worlds.

What I found above are the inevitable meesy nature of young fields. As we are expanding our design activities more into ‘new’ contexts (be it emerging technology or grass-rooted social innovation) and multi-disciplinary teams, this is the perfect time to talk about how should we be cautious about the language, assumptions and methods we bring from our own history, and also how we can construct a ‘neutral’ platform to create meaningful conversations.

Think I really should reflect a bit more on my life after join LBi and my swing between the worlds of UX (User Experience design) and SD (Service Design) for the past weeks. I was introduced to various UX events and presentations by my dear colleagues. It's been definitely a wonderful journey so far just for the experience of working in big agency like LBi, but I am sharing here is more of personal reflections on the relation and differences between SD and UX - the two design disciplines which both claim to concern mostly with people and experience.

First thing I notice, is the use of language. For example, the use of 'User Experience'. When I start hanging out in the UX crowds, I realise we are talking about 'user experience on digital devices' in most cases, but substituted with the word 'User Experience'. While in SD, 'User Experience' stands for a more holistic concept that involves inter-person interaction and how individual interaction with their communities in real world. On the surface, it seems just a use of word, but the meaning we give to words defines our perception of the world around and our roles. Of course, it is fare enough that every discipline has its own (yet interrelated) definition of certain word, as far as we are aware of these limits in inter-disciplinary communications.

Couple of weeks ago, I ran an internal session with a group of UX designers at LBi, looking at the three roles of service designer and link it to stories in UX design. For the session, I modified the term into Navigators, Facilitators and Maker to fit their specific vocabulary ( For original concepts on these design roles, please see the summary of my thesis ) We had some fantastic discussions about what in Service Design practice might be meaningful for UX designers. Again communication came up, along with language, such as ‘Do we need to have MBAs (to be strategist)?’

(more picture from Flickr)

A second thing I notice is this emerging ‘schools of thinking’ in both SD and UX. Both disciplines have people from different types of training or professional practice. Individual who works under the same job title might have completely different approach. It is not the different personality types I am talking about here (which you get often in team-building exercises).  It is a school of thinking that people brings with them this belief of what their profession is all about. This hugely impact how people prioritise activities. A behaviour science training UX designer might put more emphasis on analysing the basics than a UX designer from a developer’s background who is happier to ‘fail quickly to succeed fast’ with assumptions. It can be frustration. And it can be confusing for client who has experience working with one type but not the other. The practitioners in these situations may find it hard to describe what they are experiencing, but it exists and should be acknowledged.

A third point is regarding the methods we can borrow from each other. Three month habiting in UX world has opened my eyes to the secret beauty of statistics and quantitative methods (while used properly). I was impressed by the concious efforts put into balancing the use of qualitative and quantitative methods in understanding and solving problems. Justify the use of quantitative methods in monitoring prototype and its impact on user behaviour (people don't always do what they say) and it provides good arguement in measurement and support business decisions.

What I found above are the inevitable nature of young fields. As we are expanding our design activities more into ‘new’ contexts (such as service innovation and social innovation) and multi-disciplinary teams, this is the prefect time to talk about how should we be cautious about the language and assumptions we bring from our own history and also how we can construct a ‘neutral’ platform to create meaningful conversations. Having said that, UX has been juggling user research for a fairly long time and has learned a lot from other disciplines such as science and arts. Looking into how they have balanced, yet diversed, their methods in exploring and measuring digital solutions, it is encouraging to combine the best of the two worlds.