by Ian Hooper on March 20, 2009
One of the great things about my job as an Interaction Designer is that I get to constantly learn about new professions, people and workplaces. Understanding the use context for the software I design is a basic starting point for any project. This means learning about who the target user is, how they work and where they work. This kind of workplace anthropology is one of the things I like best about user experience design work. However, the reality is, it is hard to have regular and sufficient access to your target users, and in some technical or specialized domains, the complexity of even understanding what they are doing can be a fulltime job.
This is where the role of an in-house subject matter expert (SME) can come in. An SME is someone who has been trained and has worked in the area that is being targeted for the new application. At Autodesk, we have found that pairing SMEs with Interaction Designers is the most efficient and successful way of meeting user centered design goals.
The subject matter experts participate in product definition, concept designs, defining user personas and more. At first it may seem that the capabilities and responsibilities of a SME would overlap too much with those of an Interaction Designer. One might think that having both roles on a project is redundant. My experience has shown that, in fact, the different perspectives, education, and training creates a synergistic effect that is greater than either professional working alone.
Subject matter experts really understand the problem space. They have a deep and intuitive understanding of what works and doesn’t work in the task flows. They often have a vision of what a possible solution may look like. Possibly most important of all, they bring a passion and determination to the project. There is no better cheerleader for producing a better design than someone who has lived through the experience of using a sub-optimal solution.
Interaction designers are good at diagnosing and articulating a problem. We are able to observe the workflow, identify the goals and generate problem solutions from a more detached perspective. Designing without bias allows us to differentiate between general problems in the task flow and personal pet peeves. This outsider relationship to the problem puts Interaction Designers into a better position to make the kind of conceptual leaps necessary for true innovation.
Practically speaking this means that the research and design tasks will need to be shared. In a recent project where I was working very closely with an SME we took turns owning each of the design process steps. The SME started with the initial requirements and product concept definition, which he elicited through a series of customer visits. At those same visits, I was developing our product personas and generating use case scenarios. Coming from the perspective of the product personas, I was then able to work with the SME to refine and prioritize the requirements. He in turn was able to use his real life experience to spot gaps in the use cases and to provide some measure of validation on the personas.
During the subsequent ideation, reflection and refinement phases we would each take a part of the application to take the role of design lead. This back and forth, iterative way of working allowed us to largely work in parallel to each other and thus get more done. Much like ‘pair programming’, an extreme programming technique, we share the design work so that the knowledge base for the design is distributed and so that multiple perspectives are incorporated. At the same time, this method provides the checks and balances we needed to keep the design aligned to our user’s goals.
By closely involving the SME in the interaction design of the product we have found that both parties benefit. The interaction designer gains ready access to deep domain expertise while the subject matter expert can engage with the user centered design process to produce the most appropriate solutions. Which, really, is the biggest benefit of all.
Comments