What I did when I wasn’t online

IMG_5303

For the third summer in a row I have suspended my Facebook account. At the same time I eliminated posting to Twitter, Linkedin ( Admission: I was involved in some interesting heated discussions regarding Design Unicorns ) and Instagram  ( I do have a lot of shots saved for later).

Many have asked me why I do this, and the simple answer is

I need less distractions, digital distractions.

Actually, I need less distractions, period, and this seemed like a good place to start

Part of the break was to document what I actually did and get an idea of what the tradeoff has been. Granted some of these things may have done in part otherwise, but nowhere close to this the list below.

I think the biggest difference I noted by eliminating social media was that things slowed down considerably and has allowed me to have time for focus, reflection and reading.

Good things, basically. And it didnt cost anything.

Some highlights

An excellent overview of collaboration, the design process and the role of conflict in this process Design Together

I really can’t recommend this book enough Notes to a Software Team Leader

From reading this book, I got the tip of another book  Mindset, which I also found very interesting. The discussion  of Growth and Fixed mindsets was spot on and I recommend this book to anyone with school aged children.

I didn’t completely make it through On Looking: Eleven Walks with Expert Eyes. An entertaining book about how to ‘see’ the world around you by following experts around one block in NYC.

I watched this great documentary about NYC street photographers Everybody Street that I can highly recommend.

If you like Italy or Steve Coogan, or both, the film A Trip to Italy is worth watching.

In preparation for M and my trip to California I re watched Sideways - great movie.

My advice for becoming a UX designer

Nice description the visual aspect of Design - The Perception of Design is How Something Looks. This is something that comes up in my work on a daily basis.

I thought this was interesting read about restaurants and how they use psychology to manipulate customers.

Since I had taken a break from most social media I thought this view of what different social media platforms does to you as a person as telling. I can agree with a large part of what the author says.

The Men Who Made Us Spend - This compelling three part BBC documentary explores the fears we’ve always had about consumer culture.

Oh yeah, and I caught up on some blog posts here and here (warning, geek posts)

Actual physical social interactions:

M and I tried to be active during this month and the super Swedish weather helped in this regard.

After visiting Rosendahls trägård on the way back we had a spontaneous dinner at Oaxen Slip on their outdoor deck. Oaxen Slip is, in my opinion, one of the best restaurants in Stockholm at the moment.

Visited some very good friends at their summer house on Muskö in the Swedish archipelago.

Visited Per Axbom twice at his wifes summer house in Bro. They have an incredible deck and are generous hosts.

Finally, we finished July off (actually the 1 of August) by attending the Stockholm Music and Arts Festival on friday to catch Chrissie Hynde and Jill Johnsson

So there you have it. I will definitely repeat this next year.

Jag är nöjd.

Building UX Culture within an Organisation

In the previous post I wrote about what Design Studio was and wasn’t.

I wrote that it was ‘Not a Verb, but a Culture’, and since then have been thinking about Culture and how to change this. Culture is a complex, and living in another culture myself then the one I was born in, has given me a great deal to think about over the years.

To me culture is something that develops as a result of a set of common beliefs and practices.

Shifting culture comes down to constant communication of your beliefs, setting good examples and highlighting positive outcomes.

I also believe shifting culture, like making any change, requires  time.

While implementing Design Studio in our development process our team has worked on improving UX understanding and building a culture around this. This has been a symbiotic relationship in that the use of Design Studio plays a large role in this culture shift.

Our efforts have fallen into some basic categories:

1. Define your UX beliefs and philosophy 

A UX belief is a shared point-of-view. Working with a central UX team, buy-in is extremely important for success. Our UX beliefs are reinforced and demonstrated through processes, design approaches with members outside the UX team in the product development process.

So what are our beliefs ?

I would say we we have two -

In the case of our team, and likely because I come from a user research background, we believe strongly in a deep understanding of the user needs to be in place before products are developed. To support this belief, we invest time in end-user research focused on “contextual inquiry”, or interviews conducted in the environment where end-users interact with our products. We operate within a continuous software delivery system and frequent customer validation is also crucial for effective UX

Secondly, our always team strives for a high level of collaboration both within our group as well in the product development teams. Design Studio is a large tool that we use in this collaboration. We develop complex products and collaboration insures good designs and effective communication with all roles in the Product Development team.

2. Describe and document your process , tools and outcomes 

A set of beliefs will remain an abstract philosophy, until you put them into practice. In order for remove abstraction you must make your beliefs real and actionable. To do this you must go through an exercise of defining your Design process, guidelines and outcomes.

You must begin the documentation with the Design process. Documenting the design process is essential to communicate your practice within the organisation and key stakeholders. You need describe the process from high-level process (why) down through the (what) and finally describe the details of the (how).  Drill down into the tools and artefacts that  support the process.
In our case this documentation has included:  Design Process description - a presentation describing the major activities and how these integrate into the software development cycle. Role of User Research in the UX process - a  presentation that describes the User Research, guidelines how to conduct research as the well as communication of the results into the organisation.
Description of Design Studio in the Development process- Collaborative Design is an important part of our process, so this process is described in detail

3. Communicate your story and share your knowledge.

Once you have documented your philosophy, beliefs, and process,  you must be able to tell a story about your practice and benefits.  Depending on your organisation and the amount of technology focus, your UX practice will likely operate in a different way. Stories uncovered from research about real users interacting with our products and  how this relates to the UX process is a good way to do this.

Although we don’t have our own room all team members are encouraged to post recent designs on the walls to demonstrate where we are in the design process. In our case we also have a Yammer network that is used frequently to post images, wireframes and prototypes for feedback from persons not located in Stockholm. This has proved very effective in spreading our message.

Once presented, and internalised by others, the beliefs and practices will form a culture. Hopefully this will be a shared “practice-able” culture.

As my friend and ‘twitter sage’  Daniel Szuc says:

Be the practice you seek others to be, this requires hard work

I will let you know how this goes.

Design Studio after one year. What Design Studio is not.

A year has passed since I started using the Design Studio method within our company.  What started as an experiment is now an assumed part of our product development process for three products and development teams. As the use of this technique has grown, and its value recognised, I have begun to see some challenges that come with increased scale. I also became aware of what Design Studio was not.

A Final Solution 

Problem + Design Studio ≠ Final Solution

As the Design Studio was integrated into the development process for each User story we conducted at least one session. The output of this session was generally enough for a design to be refined and a set of wireframes or prototype to be created. After some time, I noticed that some of the teams develop a bit of

 ‘ Lets do a Design Studio so I can get my wireframes’

type of sentiment. A bit of the ‘check box’ mentalliy was slipping in. When this wasnt the case or we had to conduct more then one session, the teams became impatient. This is still an ongoing struggle, but I usually start every session with the following:

Warning: Design studio will not result in the final design.

Then repeat this.

Wrong Mindset -

Over time I began noticing a large amount of idea ownership. Persons or groups that developed ideas seem to have difficult letting them go. They presented them enthusiastically and did not accept critique. In some extreme cases, there was ‘competitions’ between ideas to see which ones that made it through the convergence stage –  I think competition can be healthy and I found this encouraged a good exchange of ideas, but only as long people were willing to let their ideas go. Ideas are very personal things and people develop intense pride and ownership of them. However, it isnt until we let the ideas go and see if they fly do they have any long term value.

Is not a verb, but a Culture

When I first encountered Design Studio in Architecture School the term was not used as a verb, a method, but more of a place. A Design Studio was a messy place, with half finished models, empty soda cans and pens and paper everywhere.  It was a place of collaboration, exploration and experimentation. The space facilitates brainstorming, critiquing, presenting, prototyping, sketching, researching, synthesizing, and many other activities that figure within the design process. Sometimes it smelled like pizza.

After one year I can see we have a bit to go to develop this type of culture. It is my hope that over time, and by making some incremental changes, we can approach this.

A fixed formula – mix it up

After a few months of having at least one Dersign Studio session per week, many of the developers became very familiar with the process. So much so, that they pretty much began sketching when they entered the conference room. This want ideal since I really wanted people to approach solving the design problem with a fresh (somewhat) perspective. I learned through this that people are creatures of habit and take comfort in these habits. It is at this point that I began to mix things up.

Slightly different methods – since this point I have been on the look-out for some slightly different sketching methods. I decided to use the Brainsketching method and found this to be very interesting and greatly appreciated by the team. I cannot comment on the quality of the ideas, but there is definitely a higher sense of collaboration around the resulting ideas produced

Environmental changes – during this time I began to concentrate of the physical environment. I was a bit limited since the sessions where held in a conference room. I usually waited for everyone to come in and sit down, then I invited everyone to stand and then exchange seats with the person directly across from themselves. I had experimented with music a bit, but made a point to always have music playing when people came in and during the sketching sessions. I am a big jazz and low-fi fan so played a mixture of Jan Johansson, French FIP radio, the Dining Rooms, Philip Glass and Mike Oldfield. 

Lean UX 14 reading list

A full week since the Lean UX 14 conference and I finally have the time to reflect a bit.

It only took a few sleep-ins, Easter holiday food and some red wine for my brain to contract back to its normal state after the stretching during the conference.

All of the keynotes were excellent and I found myself making notes of some new books referenced to add to my reading list.

Here are some of the books I noted, either directly from the presentations themselves or from the conversations between sessions.

teaching smart people

1. Teaching Smart People How to Learn New Things, Chris Argyris

idealized design

2. Idealized Design: How to Dissolve Tomorrow’s Crisis…Today, Russell L. Ackoff

3. If Russ Ackoff had given a TED Talk (Ok not a book, but an excellent video)

the principles of product development

4. The Principles of Product Development Flow: Second Generation Lean Product Development, Donald G. Reinertsen

Creativity, Inc

5. Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration, Ed Catmull

The art of action

6. The Art of Action: How Leaders Close the Gaps between Plans, Actions, and Results, Stephen Bungay

training from the back of the room

7. Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn,  Sharon L. Bowman

This book was discussed in one of our breaks when discussing workshop facilitation methods

Designerly Ways

8. Designerly Ways of Knowing, Nigel Cross

I am sure there were many more from the different workhops that I did not attend, so let me know of any recommendations you have.

For now, this will add to my never ending reading list. Thats a good thing, right ?

Design Studio in the Wild

If I have a thousand ideas and only one turns out to be good, I am satisfied.

Alfred Nobel

A year and half ago I left the consulting world and began working at a product company.

It was an exciting move, and I was very quickly thrown into the world of software development, a world very different from the one I had left.

I was given a word of advice from another UX designer already working in the company early on.

‘Just keep ahead of the developers, if you get behind with the wireframes you are dead’

The products were very technically complex and the interaction challenges considerable. I started creating some fairly hi-fidelity wireframes, presented them to the dev team then spent the next day having them explain to me why the technology would not allow me to do what I wanted.

It was at this point I realised this was never going to work. I needed something else.

As a person, I have always been someone that needs to talk and draw through ideas for them to make any sense to me.

Creativity and new ideas came from the the connections I made when I sketched or discussed the issue.

I went back to my colleague and asked about trying to work visually together with the developers.

I was quickly warned:

‘Developers will never draw – they just want to code’.

Deep down, I didn’t believe this, more over I didn’t want to believe this. This did not remind me of the developers I had worked with previously.  I was determined to give this a try.

So I took baby steps. Things were rocky in the beginning, but once I started, enthusiasm grew very quickly. Now, developers come to me and ask when we are going to ‘sketch and stuff’

Enter Design Studio

I first encountered a form of the Design Studio methodology in Architecture School.

The premise was we were given a design challenge, produced a set design alternatives, got feedback (sometimes harsh – it was called ‘crit’ a shortening of critique), then modified the design and repeating the process.

Using my Architecture School experience as a base, the method I use today has been inspired from the works of  Will Evans, Todd Zaki Warfel and Jeff Gothelf . I could never have succeeded with out reading their ideas on this subject. Standing on the shoulders of giants.

I have used Design Studio method in any situation were I want to generate a number of ideas, get feedback, prioritise alternatives then converge on one solution (s).

I have found this method very effective within the Agile process when User Stories are employed to manage development work. User stories establish good boundaries that complements the Design Studio process well.

User Story -

All development work for product development is done using creating a backlog of User Stories, prioritising this backlog then working on each User Story using Kanban principles. Product releases occurred every month

Since I view the creation of the user stories as the first part of the design process, it is important that these are well developed and appropriately granular.

At the beginning of each User story I facility a Design Studio with the development team, Development Lead and Product Manager (not always possible) to kick the User Story off. This is the ideal group since Design, Product Management and Development are all represented.

From my experience this method as a number of key advantages:

Improved quality of ideas - by getting the technology issues up as soon as ideas are considered the overall quality of the design solutions is higher.

Communication – since the entire dev team does this together a common understanding is created through the process.

Insight into other persons processes - The points where everyone shares their work-in-progress are often inspiring. The participants see an idea spawn further ideas, which in turn, spawns additional ideas. By seeing how different people with different backgrounds attacked certain problems allows everyone to broaden their range of solutions.

Sketching

When I have done this with any new group I usually spend time talking about sketching. Sketching is not art. Sketching is getting your ideas out of your head and on to paper. Things dont have to be perfect. If you can draw some basic shapes anyone can sketch.

I usually like to have people sketch on A3 size papers divided into 6 panels. This works well for describing flows and the panels are big enough to comfortably draw most things.

I encourage people to use rather thick markers so as not to go into very many details. I have tried Sharpies, but prefer Pental Sigma pens instead as they are more common in Europe and don’t smell as much. I let people use regular pencils, highlighters and various colored Post-it notes to add the rough details they need.

Design Studio Sketching

Design Session

Total time: 2.5 hours

This is an approximate structure that has achieved the best results in the context or my organisation (your milage may vary).

1. Introduction to the user story and any related scenarios. I spend about 15 minutes setting the stage, reviewing the user story and background. I prepare the room by posting on the walls any relevant personas, user tasks maps and interaction patterns.

2. Iteration One – individual sketching. 5 min. Each person sketches as many solutions as possible in this time.

3. Critique/ Feedback – consolidation. 3 min per person. Each person posts their sketches and presents the designs. The rest of the group gives feedback.

4. Break – At this point about 90 minutes has passed. Time for some Swedish coffee and a break.

5. Iteration Two – group consolidation: at this point it is usually possible to consolidate things into ‘design themes’ that represent some major ways of thinking. Depending on how big the group is and the number of themes, I will break members up into smaller groups. Each group is tasked to work on a specific design theme. I have the group appoint one person to draw then give them a time to refine these designs into one (or as close as possible). 5 min

6. Group presentation. Each of the remaining group presents the refined design to the rest of the group. Usually after a discussion the two (rarely more then two) designs can be merged into one design

By now we have converged on one design that will address the User Story.

I find that letting things settle over night then meeting again the next allows people to reflect over things and any issues to bubble to the surface.

A proud developer reviews the task breakdown.

Task Development – 1-2 hrs

Once the design is established we meed a second time within the group. Before this meeting I have documented the design in a lo-fi format (Balsamiq/Omnigraffle or clean sketch) and then meet the entire team once more. During this meeting the team then goes through the design and breaks it down in the necessary technical tasks.

1. I begin by posting the final design wireframes, user flows and personas on a wall. I then give the team 5 min to come up as many tasks and dependancies that they can.

2. Each member then begins to post the tasks they have identified next to the relevant area of the design or user flow on the wall.

3. Once everyone has posted their tasks then these can be discussed and consolidated to what will be implemented.

4. These final set of post-it notes is then transferred directly onto the Kanban board to be planned.

At the end of this process, the team has generated ideas, developed a design for the problem and broken it into technical tasks.

Design Studio repetition -

The first few sessions with the development team where tough. It was a new way of working with methods unfamiliar to most of them. As time went on, people became more at home with the techniques and I started to see the sessions themselves begin to develop with less input from me. Certain background information was no longer needed and the later session could tackle more difficult problems at greater detail. Once people are familiar with the process, it’s fast and efficient to work through a design challenge and generate great solutions. The team was developing.

I realized I had achieved my goals when the team then started to automatically schedule multiple design studio workshops into every User Story – without me mentioning it !

Swedish National Museum Experience Journey Map

Last week I met with up with my friend Kajsa Hartig that works as a Digital Navigator at Nordiska Museet in Stockholm. We had been trying to link up and visit the Swedish National Museum that is going to be remodeled and had an exhibition that highlighted a large interactive touch screen based exhibition about the remodel of the museum (we thought). We picked a date and visited the museum but sadly the exhibition was no longer being showed. This is what we deduced, since no one seemed to have any recollection of the exhibition despite me reading an article in the Swedish newspaper describing it.

I found the entire visit a bit frustrating but things were saved by a good cup of coffee and chat with Kajsa. During the conversation, I explained to her I was confused over that so many museums seem to miss some basic elements when people visit them. The trend from physical ownership to access via technology is something that is increasing (cars, music etc) but yet museums have been dealing with this for years in that they display very valuable and rare objects. A key part of having access to these objects is insuring that the user experience is at a high level. We started discussing this issue further and I began to describe my recent experience working Customer Journey Mapping. I felt this technique could be very valuable in the museum world. I began sketching my experience as I prepared for todays visit and the events that followed in order to demonstrate the key points.

After the visit, I had a spare moment and sat down and refined my sketches  to demonstrate how this could work.

My Experience Map

Let me start by saying this is the information for one person, me, and to get a more general view of an organization’s user base one who need to conduct similar research for a larger group of persons. This group should include users that representative an accurate cross section for this organization. This would allow patterns within user groups to be established and documented using segmentation techniques or user personas.

The first diagram shows my journey divided into some basic steps. Each step refers to a mental mode I went through for the journey – research, enter/ticket, exhibition, break coffee, exit and post visit. Within each mode I then noted key experience points and if I viewed these as positive or negative.

The second image demonstrates which channels I used to interact with the museum as I passed through various mental modes. For each experience point, I also indicated my mood at the time – happy, frustrated, confused etc.

If I had to summarize the visit I would say the weak points were:

  • Information gathering prior to the visit via the website could have been improved. National Museums website is good, but jammed with information. Some different graphics choices (typography and white space)  could have made the information more easily readable.
  • No Mobile website. In the beginning I was simply looking for the opening hours and I was taken to the normal website via my smart phone and forced to navigate to the ‘About Us’ (Om oss). There was considerable pinching and expanding involved.
  • The information/ ticket is almost hidden from the visitor when they enter. I found this odd since this is central for all visitors. Fortunately, there are many helpful staff that directed me to the correct area.
  • The personal at the information desk was very nice, but wasnt very informed of the present (outside the information brochure) exhibitions and had no idea of past exhibitions. I also thought the response ‘why dont you buy a ticket and see if the exhibition is here now’ was a bit poor.’ I turns out this what I ended up doing, and the exhibitions wasnt there after all. I did see some other lovely artifacts !

Overall the visit to the museum was very pleasant but two areas needed additional thinking – access to information surrounding the exhibits and design of entrance/ticket areas.

Bringing the outside in using experience journey maps

Experience journey maps are a tool to help bring the outside world into an organization. They are a tool that can help bring customer stories to life. An entire story. Not just the piece one silo or function within an organization normally may encounter.

And as we map out the customer’s story, our organization’s own story becomes visible. And often what’s revealed is an incomplete fractured story.

By using experiences maps organizations can identify areas where information and technology can be introduced that improve these fractured stories. I am convinced that all museums would benefit from understanding their users better and then to match their offerings to insure a consistently positive experience for all groups.

References:

Visualizing the customer experience using customer experience journey maps

Improving the Starbucks Experience

How to create an Experience Map

Experience Mapping — a useful tool to gain customer insights

Mapping the customer experience with customer experience journey maps

How an MBA meets the silos challenge of UX

When I was applying to one particular job at a UX form in Stockholm the issue of my MBA came up in the interview.

‘ How is your MBA useful in the UX area ?’ they asked.

Now, I had never given this much thought and had seriously considered removing the MBA from my CV but my pride (and all the hours I put into to it) forced me to leave it on. Usually I just didn’t mention it much.

I don’t remember what I answered exactly, but it centered around strategy and analysis…..or something. As I remember it could have been a better answer.

I think partially I was a bit embarrassed of the degree. This is especially true in Sweden, where it isn’t so very well known outside from the top schools in Europe and the US and thus hard to relate to. Since it wasn’t a ‘design’ degree it somehow didn’t go over as relevant.

Advantages of an MBA in the UX area

Having worked a few years now in a number of UX agencies in Stockholm I have definitely seen the value of my MBA.

1. Ability to conduct analysis – this is probably the most valuable area that I learned from my MBA. The ability to structure, analyze, then communicate the results to an audience has been invaluable in my UX.

2. Real Cases – We were always exposed to the basic theories in various areas, but there were ALWAYS coupled with real case studies. Very little purely theoretical examples.

3. Education based on frameworks and mastery in applying them. No absolute right and wrong. – Now I have read some criticism of MBAs recently in light of the value of design thinking in business. Basically the argument goes – MBA education encourages one answer to the case while design thinking embraces multiple possible outcomes. In my experience this can’t be farther from the truth. For most cases we could propose many solutions as long as they could be justified. Believe me, if you have studied enough theories and frameworks you can justify anything. The best case studies that I did were ones that I combined frameworks from multiple areas to justify a innovation solution. Sounds a bit like design thinking doesn’t it?

4. Consider things in their entirety. By the end of your program you are encouraged to think holistically and apply your knowledge across many operational areas.

This last point bares some further explanation, since I think it is particularly relevant.

The Challenges of Silos

I have just finished following the UXLX event in Lisbon on twitter and noted the continuing discussion around ‘silos’ in organizations and how they limit effective UX thinking. I have been involved in the UX area for a few years now and attended a handful of conference. In all of these conferences, this issue of ‘silo crossing’ always comes up in varying degrees. Clearly this is an area of frustration.

The discussions seems to follow a similar patterns with a good dose of hand wringing.

‘The managers in department ________ just don’t understand the value of what we are doing… ‘

We need to ‘cross the silos’ or ‘ get a seat in the C-suite’ or something similar…

My true belief is that to integrate UX thinking into organizations will require people to meet somewhere in the middle between the silos. I agree with Peter Merholz that UX should be seen as a strategic effort as well embody tactical solutions (methods and tools). Until this is achieved we all will need to understand the other side.

To effectively eliminate silos (or at least minimize the effects), UX practitioners need to understand the other silos. To understand persons working in other silos we need to understand their motivations and how they define success. One way to do this is through business education.

When you look the core of a typical general MBA curriculum, you see a couple core areas:

1. Strategy
2. Finance
3. Marketing
4. Human Motivation – extremely valuable.
5. Some sort of Quantitative Analysis

All of these areas of knowledge have been beneficial, but what they have given me in my UX work is understanding.

Understanding of other departments and what their function is in an organisation and how they measure success. What makes them tick if you will.

Crossing Silos.

‘Understanding other silos can make yours better.’

@kimgoodwin

Now I am not suggesting that all UX practitioners drop their wireframing tools and head off to business school. This is overkill.

But I do think that UXers should take the time to educate themselves in the basics of how businesses operate and organize themselves. Maybe shift the spotlight of their view point a bit more over to the other silo.

And UX consultancies and other organisations; the next time someone shows up at your door step with an MBA under their belt, give them a chance, they may just surprise you.

You never change things by fighting the existing reality. To change something, build a new model …

You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.

Great post The Problem With “Innovation” in which he cites the above quote from Buckminster Fuller and points out that what looks silly, superficial, inconsequential and downright distracting when they’re first proposed can “suddenly” have fundamental consequences for society as a whole. Or, as the author puts it:

New models create new markets, but they’re often misunderstood at the outset. Stupid checkins reshape how we explore and experience the real world. Prepaying for tick tock watches reshapes financial markets. Silly status updates spark revolutions. And grainy glitchy video calls cut into the commercial air travel.

Something to think about.

User Research – Look and Listen

During the last few months I have been involved number of projects that involved a considerable amount of user research and testing. Through this process, I have interviewed over 50 persons for a number of digital and physical devices. There are already a large number of posts discussing user research planning and structure so I didnt really see the need for one more. What I did want to document, is the ‘people’ aspect of the research and summarize which techniques that worked well for me.

1. Listen – If I say listen, this is a bit obvious, but I am surprised at how many people that don’t really listen during user tests. Whether this is to get through the test as fast possible or an over concentration on the task at hand, people sometime fail to listen. To assist the dialog I often try to use the same terminilogy as the participants. An exmple of this is when I interviewed bus drivers as part of a new instrument panel study I asked them which term they used to describe the panel anc continued to use the same term. (Interestingly, this was not the same term the manufacturer (client) chose to call it.)

2. Use two people to conduct a user test if possible. This will depend on the client, scope of the project and overall goals but overall results improved. This will allow one person to facilitate the interview itself and fully concentrate on the test person. I find that test persons are quite sensitive to distracted facilitators and the overall quality of the results are better. The second person can then concentrate on documenting the research and making sure the technology is working (which is often a challenge).

3. People don’t open up until they are comfortable. For some test persons this never happens, but for most some simple techniques can insure this happens fairly quickly. If the test scenarios don’t require it, try to keep the lighting as low as possible. I try to have ample space to conduct the interview. No one likes to feel cramped. Water, coffee, fruit and candy all help to get test persons to exchange freely. In general, I often start the interview with a few non-intrusive background questions. It is important to view the interview person as an individual and not just a ‘cog in the research machine’.

4. Don’t help too much. I am quite guilty of this. Very often we designers, after spending countless hours thinking about a solution, have a difficult time just letting people be in their attempts to understanding the interface. The goal of the research to to get feedback of the process and the outcome and things take time.  Be patient – just give it five minutes, before jumping in.

5. Don’t use a script. When testing people try to be as authentic as possible. The same rules apply to presentations as well as interviews. When someone sits and reads a script, test people sense this and I believe react accordingly. Very often the script is pre approved by the client to insure that everything is included in the test. In this case, I usually take the script and distill it down to a few keywords and then ‘talk’ around each these trying to weave the questions in tot the discussion. Improvisation is key here.

These are what I have come up with so far.

If you have any more good tips let me know.