Magga Dóra

Magga Dóra

User experience designer with background in psychology and computer science. Loves anything and everything that has to do with user behavior. Also loves travelling, photography and teaching. Please refer to her CV for details. One of the founders of Arctic Girl Geek Dinner - Tæknitátur.

Watch me at TEDx Reykjavik in 2009

Read more posts by Magga Dóra.

Portfolio and more information
My LinkedIn profile

So, in terms of Legos. What do you need?

Many UX design problems are about creating something to replace something else, to fix a situation that is currently not working. This could be a gaping void in a product market that needs to be filled but it could also be replacing manual processes and old legacy systems within a company.

The first step in this sort of design is to understand what this thing you are designing needs to do. The obvious answer is getting the people that are going to use your product to tell you. It seems like a straightforward thing to do but you run into a snag:

People don’t want to talk about what they need, they want to talk about what is wrong.

A discussion of the current flaws will lead you nowhere. If you only address the things that are paining people you will create something that might work as a band aid on the current situation. You will have improved it slightly but you won’t have solved the problem.

So it is really important not to have that discussion, but it’s hard. This is in part because we find it easier to talk about things that are salient to us (because we remember them very easily), in part because it is good to vent about things that are troubling you but it is also because people in general find it difficult to talk about things abstractly and generally.

It’s our job to get them to do exactly that. How?

  • Take control of the conversation
  • Supply a vocabulary / framework / metaphor to work within
  • Give them something hands on to do that generates artifacts that they can use to further the discussion

A few years back I accepted the challenge to help a call center improve their service. The company’s products and services had exploded and the call center had literally over 60 different tools that they needed to service different types of customers and different types of products. Training took weeks, staff churn was around high, all in all not an ideal situation.

I spent days in the call center, getting to know people, listening to them describe the situation. I had managed to fix a few low hanging fruit and so we were ready to move into the big project.

When I called them in for the first meeting I explained that we weren’t going to talk about the current problems. Doing that is like trying to understand the shape of a mountain by listening to descriptions of each rock. We were going to step back from the mountain and admire it from the other side of the fjord. This way when the discussion sidetracked into too much detail on what was going on in the call center we could classify that as a rock, put it down and back away again to take in the whole of the mountain.

Then I put them through an exercise in abstract thinking: I asked them to describe the current situation to me in terms of a car. As if their job was to be a driver, what sort of card had they been supplied with.

It wasn’t until our third meeting that I asked them to tell me what they do. What constitutes a typical service call from a customer. And then I upended the Lego box on the table.

I held out a Lego block and I asked them to define different things that they need in the call in terms of different color blocks. Is green information about the customer and yellow information on the products currently on offer? Good. What else?

When they had defined the different colored blocks I asked them to build me a house. The house would represent a typical call. The basis was what they needed first, the thickness of each layer how much of it they need.

This caught on really well with the teams. They would grab blocks, define them, use them in conversation, throw them at each other. They had a language, and they were off.

The results were so useful! Using this technique I was fishing blindly but it worked. I had a much better understanding of what the customer representatives do and what they need in order to do that. I had a way to compare needs between units within the call center (sales vs. tech support for example) and I could use that to identify what should be built for them and even how to prioritize that so that we could address the biggest issues first. Now I could begin sketching the interface.


No Comments

Your thoughts:

* Pretty please