Immersion is a technique where you essentially put yourself in the place of a user and use a product, piece of software or system just as the user would. You essentially become the user and you do this for an extended period of time using a clear set of tasks you complete just as a user would. For example, I used immersion once to evaluate e-texts and would actually use real reference questions from physicians and attempt to answer them using only the e-text resource. I was working in a hospital at the time and routinely used text books for reference questions coming from the medical staff. So this approach using immersion allowed me to evaluate the navigation, the overall information architecture and the indexing of the e-books among other things. I became an actual user for the project and spent more than a month evaluating the product inside and out. It was an effective method given my lack of users at the time. Since then, there have been a number of systems, interfaces and products where I have used immersion to analyze them for lack of a decent user-base with which to test anything.

I have recently immersed myself in my own company’s hearing aid products and am using myself as a test subject. Once again, I have become an actual user and am using the products as they are intended. But, there are a few problems with this approach. First, I am an expert in usability analysis and will find problems your average user probably would not find. This might not seem like a bad problem and it isn’t in some ways. But, I tend to be more demanding than your average user and thus can come up with requirements and improvements that may not be necessary. Another problem is that I am “an insider” in the sense that I belong to the company and know a lot of the “ins and outs” of the products users do not know. An example would be that I know what is possible and what is not in terms of development. I also know why products are designed as they are in many instances – the limitations and barriers that brought them to their current state. Finally, though I am a user, I am not representative of the demographics or user base in any sense. In short, I am simply not your average user. I am, what some might term as, a “super user.” This means I look for the maximum ways to utilize a product. I am the guy who uses 70-80 percent of the features in a software program – the features no one else uses. This, in a sense, makes me a tough study and a very tough user.

But, I’m not truly doing this to develop “rigorous research data” or to necessarily drive the future design of hearing aid products. I am doing this to, first, gain a sense of what the user experience is like for hearing aids. I have a significant hearing deficit and have worn hearing aids before. However, I have not worn them in years and never wore the brand of my current company. So I am trying to find my own likes and dislikes of the product. Have you ever used a product where you said to yourself: “Whoever designed this never used it!” I have. I have used software in which there is no possible way the person who designed it ever truly used it for its intended purpose. What I am trying to avoid through immersion is being a person who designs for a product (or designs a product) he never uses or used.

There is another reason I have placed myself in the role of the user – the iPhone. My company, GN Resound, is about to release a hearing aid that will connect directly to your iPhone. More on this in a later post. But, I am currently beta testing these new hearing instruments and the iPhone app that controls them. In the few short days I have been using the app, I have come across several shortcomings, a wish list of features that could be added and a general sense of the difficulties a user might encounter – all through the simple use of the application and native iPhone interface.

Immersion is a little easier with phone applications than web or desktop applications because there are usually less features. But regardless of what I am evaluating, there are a couple of techniques I use in immersion.

Develop a checklist of the features and tasks the app allows you to complete as a user. You can use documentation to complete this list if documentation for the app exists. Then I will work through this list taking notes on each of the features. Those notes will include general observations, problems I had, bugs and the overall usability of the feature. This is a good start in evaluating an app or interface. But, it only allows you to evaluate the features the design team came up with. What about features they didn’t think of? That is what my second technique is for.

Takes notes on your use of the application or interface as you use it. I will literally stop a task and quickly jot down a note when I get in a situation where a feature could be designed differently or there is something that could be added to improve the user experience. This doesn’t have to be a very formal process at all. I use Microsoft’s OneNote and just keep a list of problems and additions that aren’t covered through the checklist of features I developed. It’s a pretty simple process and you’ll be surprised at how much you will discover simply by using a product you are designing or perhaps conducting a usability evaluation of.

And that’s as difficult as it gets for me. No frameworks, interview questions, surveys or the like. It’s just as simple as using the product. I usually will use a product for a minimum of 4 weeks when using immersion as a research method. Longer is fine, but there is probably a law of diminishing returns at some point. This would depend on the complexity of the application.

There is, of course, one other caveat. You have to have enough domain knowledge to use the product. This probably is not a problem for most UX professionals working in e-commerce or app development. But, I consistently work in healthcare and there can not only be access issues to using the software, but also issues in simply using the application from a knowledge perspective.  For example, I could never play the role of a physician and use an electronic health record in practice. Even if I could, I wouldn’t have the domain knowledge to accurately find and represent problems within the system. In this way, immersion is limited in its application. But, there is still a wide field of applications where this technique can be used. And, it will save you time recruiting users, developing scripts, writing interview questions etc.

Immersion: It’s a simple, but effective method. Try it out. Become the user and you’ll discover a good percentage of the problems and pain points the user has.

%d bloggers like this: