User Experience

Copy of 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.

User Research - Look and Listen

see-hear.png

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.

Task Based Digital Development

A person's behavior on the Web is highly goal-driven. People have something they want to accomplish, whether it's making a purchase, finding a recipe, finding a colleague or learning how to do something new. This model attempts to use the concept of user tasks to break the web design (or application design) up into a series of steps that have specific functions that contribute to efficient task completion.

Task

The overall task of the user is identified and specified. This is often more complex them one may think. Useful techniques techniques are: surveys, interviews, focus groups, user observations. For an in-depth summary of analysis options read Step Two Designs excellent article.

Listen

The goal of this step is to simply listen to what users are actually doing on the website. This is where the reality of the web site use becomes evident. A key here is to establish a measurable baseline to task completion. This will allow any improvements or changes to be evaluated using metrics, not opinions. Useful tools here are a careful review of web statistics, eye tracking and formal usability testing.

Assess

This is where everything comes together and solutions need to be developed. Task processes need to be closely evaluated and modified. Content needs to be evaluated, edited or removed (gasp!). An overall redesign of the specific area can also be called for. The scope of changes will depend on the specific area and how the new design will influence the rest of the website or application. The best improvements will often be the most subtle for the user.

Test

Here the various changes consider should be tested. This may seem obvious, but it is surprising how many times things are just incorporated because it 'seemed right'. Basic users testing  is one of the most simple methods for achieving this. In more advanced situations, eye-tracking and full usability testing can be useful. Testing should be designed to as actionable as possible, so clear conclusions can be drawn and fed back into the design process. Comparison to the baseline statistics conducted in the 'Listen' stage should be also done.  This will provide a quantifiable indicator if the design is improving task efficiency.

Modify

Based on the feedback from testing, adjustments can be made to the design (or not). In the ideal world, the task efficiency shall be improved, but in the real world, things may not be so straight forward. This is why the process is a circular one, and another iteration may be appropriate.

None of these steps are rocket science, but together can provide a framework and structure to the web and application development process that has the task and user in mind.

This is my method, what is yours ?