sUppORTinG THE UniniTiaTED in

practicing UcD is vital to helping non-UX practitioners acquire an understanding of this new mindset.

Maria Ralph, aBB corporate researchpetra björndal, Kth and aBB corporate research

UsER- cEnTERED DEsiGn

i n t e r a c t i o n s . a c m .o r g6 0 i n t e r a c t i o n s m a r c h – a p r i l 2 014

ll

sa

on

sd

ee

sr

ne

m a r c h – a p r i l 2 014 i n t e r a c t i o n s 61i n t e r a c t i o n s . a c m .o r g

ph

ot

og

ra

ph

by

mu

rr

ay

th

om

ps

on

Lorem Ipsumin field studies is not something all non-UX professionals will welcome with open arms. There is usually some hesitation toward meeting end users, which is often linked to either the viewpoint (“We already know what users need, so why do we need to talk to them?”) or the need to build something as soon as possible, since time and money are key driving factors. So taking the time to talk to end users can be a source of frustration and anxiety.

In industry, the longstanding approach to product development has focused on the inclusion of all possible functions and features (often from customers’ wish lists), rather than on patterns of use typically found after conducting field studies. These features are often based on ideas stakeholders have collected over the years from project meetings or from sales personnel. Although this material can prove valuable, the project team needs to understand that this material alone is not enough to capture the project requirements, and that engaging in user studies brings a newfound, valuable perspective by revealing important patterns for how people work.

What is interesting, however, is how team members’ opinions change once they start to conduct field studies. There is often a shift in thinking when team members realize their mental model for how they think certain tasks are done differs from how those tasks are done in reality. Understanding that the product they are developing is only a part of the user’s world, not the entirety, and that other aspects of the user’s work environment need to be taken into consideration is often an eye-opening experience.

Conducting field studies is a skill that UX professionals have learned over many years and after many studies of their own. Supporting non-UX professionals in the art of interviewing and observation therefore requires a practical approach. A good place to start is to practice with mock interview sessions whereby a UX professional watches and provides feedback to non-UX professionals. This is particularly important since the non-UX professionals will engage in

More and more companies are starting to embrace user-centered design (UCD). This is encouraging for user experience (UX) professionals; however, it does provide its fair share of challenges. These challenges are especially evident when UX professionals cannot actively participate in all projects within a company but need to provide support for this way of working.

One solution is the transfer of basic knowledge from UX professionals to the project team (e.g., developers, product owners/managers). With this approach the UX professional acts to support and guide the project team on how to conduct effective UCD. But it is up to the project team themselves to take responsibility for doing the actual work.

So, how can UX professionals best support project teams in adopting an effective UCD way of working?

First, even before the real work has started, everyone involved needs to commit and to trust that a UCD-focused project can be successful. Although this may sound trivial, it is the key to success for any project team that chooses to use UCD. To achieve this mindset, the existing mental model of non-UX professionals needs to change from being product focused to user-needs focused. It’s important for UX professionals to support this change by referencing material such as past projects to convey that using UCD is an established way of working. This will ease the minds of team members who are unfamiliar with this process. But embracing UCD requires an open mind, which does not come easily to everyone. So it should be recognized that some team members might take longer than others, require a little more support during the process, or not make the switch at all.

sTaRT WiTH WORKsHOpsOrganizing a workshop is often a good place to start. Workshops help bring team members together and can be an efficient use of everyone’s time. They help clarify misunderstandings and miscommunications that often arise. They also provide an opportunity to engage in practice sessions to reinforce key ideas. But for a workshop to be truly effective, all of the key players (e.g., project leader, product manager) in the team need to commit to and understand the central parts of the process. Otherwise, the rest of the team will waiver in their commitment as well.

An introductory workshop should provide an overview of the UCD process. It should also try to show how UCD relates to the team’s current way of working. Topics such as the differences in how requirements are gathered (stakeholders versus end users), use cases are written (technically oriented versus more general context-based), products developed (build versus prototype), and testing conducted (unit testing versus user validation) can all be addressed. Likewise, scenarios, personas, conceptual design, and redesign (areas not common to most industry projects) can be introduced and discussed.

REqUiREMEnTs GaTHERinGAs UX professionals know all too well, the requirements-gathering stage of the UCD process is of utmost importance but can also be a source of frustration. Gaining access to end users, dealing with language differences during interview sessions, and ensuring the questions asked capture what is needed are only a few of the hurdles that non-UX professionals will quickly learn they need to overcome. However, engaging

Understanding that the product they are developing is only a part of the user’s world, not the entirety, and that other aspects of the user’s work environment need to be taken into consideration is often an eye-opening experience.

i n t e r a c t i o n s . a c m .o r g6 2 i n t e r a c t i o n s m a r c h – a p r i l 2 014

lessons learned

real interviews on their own and need to have a good grasp of the basics beforehand.

But in projects things do not always go according to plan. So the team needs to be flexible. This can be seen when interviews cannot be done in person or time limits restrict the types of questions that can be asked. So part of the learning process also involves how to handle cases outside the norm of running a typical study. Some workarounds that have been used for these cases include using video conferencing to conduct interviews and prioritizing a questionnaire beforehand to accommodate time limits.

WRiTinG scEnaRiOs anD pERsOnasIn many industrial applications, using scenarios and personas remains a new concept, one that can be seen as unnecessary. Since use cases are often the main means for relaying requirements, there is frequently an uncertainty expressed among non-UX professionals as to whether scenarios and personas bring anything relevant to the table. The challenge lies in trying to convey the importance of including these components in order to capture both contextual information and to paint a picture of the types of users who will interact with the system. This process also requires a bit of creativity, which can be a challenge for more technically minded team members. To communicate this in an effective way, team members need to see this as a way of “setting the scene” in much the same way as writing a play. Providing what is often considered obvious material can at times turn out to be not so obvious to other team members. Once non-UX professionals engage in both writing and discussing scenarios, their importance becomes much more evident and appreciated.

One of the most important aspects to convey to non-UX professionals is that they need to know their audience. Producing scenarios that focus exclusively on technical details will tend to alienate those team members unfamiliar with this level of detail. Likewise, writing scenarios that are too high-level can also be problematic since they may not provide sufficient

information for technically inclined team members. What appears to work well is the use of high-level language throughout the scenario with a sprinkling of technical content (e.g., describing a work environment and text editor being used). This way, all team members can relate to and participate in scenario discussions and give important feedback, which may have been missed otherwise.

Scenarios in general can be written in different ways, for instance, present-based or future-based. Present-based scenarios focus on current work practices that define the problem domain, and future-based scenarios discuss how problems encountered might be addressed. Using both types of scenarios provides the team with a solid foundation for making design decisions later in the project and gives new team members an opportunity to understand the context and scope of the work.

In addition to scenarios, personas developed need to be carefully thought out. It is often the case that the development of personas results in a direct mapping to a role or job title that has been identified (e.g., manager, sales representative). However, it should be emphasized to non-UX professionals that this mapping can differ between users. The team needs to focus on extracting the key needs and goals for different users, not just their responsibilities, since these can overlap (e.g., mechanical installer and a service technician), while their goals and needs can differ (e.g., one user needs to focus on speed and the other on accuracy). Once the team has agreed on the persona set, there is a loyalty that develops over the course of the project whereby team members will stand up for different personas (e.g., “John would not accept not seeing the time here”). This provides a richer interaction between the team and a deeper understanding and commitment from the team toward trying to meet the end user’s needs.

cREaTinG UsE casEsIn typical industrial projects, use cases are often the main source of information for capturing and transferring system requirements to the development team. They are typically used to outline more detailed

material and are written in a style that speaks to more technically inclined individuals. Trying to change this approach toward writing use cases with a broader audience in mind does not always translate easily for non-UX professionals.

What needs to be understood are the dynamics of an industrial project team. Members of the team bring different expertise to the table, and are often distributed across different locations. From software architecture, coding, design, management, sales, and so on, each of these individuals interprets information in differing ways and with differing cultural perspectives. Software architects and developers, for instance, find high-level use case descriptions too vague, since there is not enough detailed information about what should be implemented and how. Working with a multidisciplinary distributed team requires the format of the use cases created for the project be agreed upon by all team members.

Another issue that can arise during the use case development process is the temptation by team members to already provide design solutions in the use case descriptions. If team members are prepared to revise use cases when changes are made further down the line, then this approach can work. The danger lies in forgetting to make changes to the use case descriptions, thus creating a mismatch between what has been implemented and the solution presented.

DEsiGninG a cOncEpT Making sense of how people will interact with a system always involves a bit of sifting through the rubble. Sorting through all the scenarios, use cases, and so on can be daunting, especially for the uninitiated. So, again, the use of workshops helps to put things into perspective.

For the conceptual design (i.e., affinity diagram creation) stage of the process to work, a participatory approach is needed whereby all members of the team need to be present in the same room. The importance of this is quickly evident if you have ever tried to run one of these sessions via video conferencing. People sitting in different locations become easily distracted by emails,

m a r c h – a p r i l 2 014 i n t e r a c t i o n s 6 3i n t e r a c t i o n s . a c m .o r g

Lorem Ipsum

interact with the system. This can result in features being added, deleted, and added again after lengthy (and sometimes heated) discussions within the team. But this part of the process is essential and should be encouraged to ensure that everyone has a common understanding and is in agreement with the decisions made.

pROTOTypinG anD vaLiDaTiOn By this point the team’s urge to build something has been suppressed long enough, and there is an increasing need to see something concrete. Enter

urgent phone calls, or the coffee stain on their desk. So the first rule of thumb is to stress to non-UX professionals this basic need. But again, in industrial projects this may not always be feasible, so once again flexibility is the key.

The design process itself can take several days, so a workshop run over two to three days is a good place to start. Having this type of workshop is well worth the effort since it is during this stage of the process that team members start to see how their earlier efforts are beginning to pay off. But the reality is that this may still not be enough time to complete the

initial conceptual design. Follow-up meetings may be required, especially when dealing with complex systems.

The conceptual design stage can begin by prioritizing scenarios and associated use cases. This will drive the workshop and help everyone focus on selecting the most important tasks, rather than on trying to cover everything. This will also provide the team with the scope for the prototype to be designed later.

Once scenarios and use cases have been identified and agreed upon, the team can then begin extracting the main features users will use to

i n t e r a c t i o n s . a c m .o r g6 4 i n t e r a c t i o n s m a r c h – a p r i l 2 014

lessons learned

the prototype. This part of the process is usually welcomed since there is a newfound sense of relief among the team that they will finally get to build. But there needs to be some restraint. Supporting non-UX professionals during this part of the process means constraining them slightly in the design choices they make. The team can’t get carried away with their new prototyping tool and fall back into the trap of adding too many potentially unnecessary features to the design.

This part of the process is also a good opportunity to show non-UX professionals the basics for spotting

common usability issues that can be detected early on. Providing simple heuristics, for instance, can help the team see where they may have gone wrong in the past, and improves awareness and provides a newfound perspective they can use in future projects.

Feeling somewhat more comfortable having gone through the prototyping stage, non-UX professionals need to then engage in validating their prototype. But testing in this context does not

involve the usual suspects (i.e., unit testing, regression testing). Testing with real users and a prototype will be uncharted territory for the team, so having practice sessions to go over the basics is important to provide encouragement and to boost confidence. It is in engaging in this final part of the process that the team will put the last piece of the puzzle into place, and in doing so show the real value of employing UCD in their project. All that is left is analysis of validation results, redesign, product development, and product launch.

sO, can WE REcOMMEnD THis appROacH? Although not ideal, this approach provides a first step to enabling project teams to see the possible benefits of using UCD, and will help them take the initiative to include UCD in future projects. For this approach to succeed, the team needs to be truly open to accepting this new way of working. In addition, the support of management is critical with respect to believing in the process and supporting the needs of the team (e.g., providing budgets and resources). In our experience, a key factor has also been to have a go-between person in the project who is both a domain expert and also highly interested and willing to learn about users’ needs. But most of all, time is the ultimate ingredient in the mix. It is a long-term process for the team to digest and to buy into this approach, so it’s essential to give them enough time to change their way of thinking about users and to effectively support them throughout the process.

Maria Ralph graduated with a B.sc. degree in computer science and a ph.D. in systems and computer engineering in the areas of human-robot interaction and usability. she is currently working as a scientist at aBB corporate research in Västerås, sweden, conducting research in industrial UX. → maria.ralph@se.abb.com

petra björndal is currently a ph.D. student at Kth (stockholm, sweden) in hci, and is also currently employed as a scientist at aBB corporate research in Västerås, sweden. she has worked as a UX practitioner for over 10 years. her research focuses on user-centered product and service design processes. → petra.bjorndal@se.abb.com

Doi: 10.1145/2566463 © 2014 acm 1072-5520/14/03 $15.00

m a r c h – a p r i l 2 014 i n t e r a c t i o n s 6 5i n t e r a c t i o n s . a c m .o r g

ph

ot

og

ra

ph

by

mu

rr

ay

th

om

ps

on