Showing posts with label user research. Show all posts
Showing posts with label user research. Show all posts

Friday, October 10, 2014

Creating a Cultural Fit: Using ethnography with users and stakeholders

ARTICLE NO. 1323 OCTOBER 9, 2014


“The power of authoritative knowledge is not that it is correct but that it counts.”–Brigitte Jordan
They stride into the arena wearing the maize and blue. They are tall, strong, fast, and confident they will conquer the world. It wasn’t easy getting here, but after countless hours of practice, weight training, and gut-busting cardio workouts, they have arrived. The price is high. It costs thousands of dollars a year to play at this level, but without access to the best coaches, facilities, and technologies, you might as well just go home.
It’s six-thirty in the morning in January, and as I watch our fourteen year old daughter’s volleyball team make their way to the court, my feelings are mixed. I’m not happy about waking up at five o’clock on a Saturday to drive for an hour through the snow. A few years ago, I’d have laughed at this elite sports scene. Now I’m a part of it. Claire is staying fit, making friends, building self-confidence, learning teamwork.
Still, it’s over the top. Our club makes me uneasy. What bothers me most is the uniforms. They are beautiful. Since our club is run by the University of Michigan, our girls are decked out in blue and gold. While a lot of teams satisfice with cotton t-shirts, we have personalized, lightweight, wicking Nike jerseys with matching shorts, warm ups, and backpacks. As our girls prepare to play, I can’t help feeling we’re on the wrong side of the tracks. And sure enough, we are crushed by the t-shirt team, just like in the movies. Later, after a day of losses, I tell Claire not to worry, it’s the first tournament of a six-month season, the team will get better.
Of course, it was all downhill from there. Our coach was a hard-ass all season. One girl was berated for not hitting hard enough. Later it turned out her finger was broken. Claire was told she couldn’t take a break even though she felt sick. Soon after she was vomiting into a bucket. The girls were taught how to trick the referee. They were instructed to lie. The coach invited them to voice complaints. Claire did so and found herself benched. The parents weren’t any better. Our alpha mom reduced other moms to tears, taunted the opposing teams, and paid for weekly private lessons with the coach. This looked like pay-to-play corruption to us, but several of the parents said that’s simply how you play the game.
The next year we switched clubs. The new one was a little less expensive and a whole lot better. When the coach told the girls it was okay to miss practice for homework, since education is more important than volleyball, he actually meant it. When we lose a game, you won’t hear a word from our alpha mom. We don’t have one. The girls practice in an old warehouse, no windows, flickering lights. It’s nothing fancy. Neither are the uniforms. And that’s the way we like it. We found our fit.

Cultural Fit

In the 1990s, as co-owner and CEO of a consulting practice, I hired and managed several dozen employees. Mostly we got it right, but once in a while we hired someone who didn’t fit. The consequence of a cultural mismatch is often compared to an immune system response. It’s not a bad analogy. The first symptom is inflammation. This pain is followed by isolation of the foreign body. But in organizations, there’s no need to destroy the antigen. Few people endure outsider status for long. They quit. At the time I thought there was something wrong with those people. My enculturation was complete. Now I know it simply wasn’t a good fit.
As a consultant for two decades, I’ve been a tourist in all sorts of cultures. I’ve worked with startups, Fortune 500 companies, nonprofits, Ivy League colleges, and Federal Government agencies in multiple countries. My clients have included folks from marketing, support, human resources, engineering, and design. Being exposed to diverse ways of knowing and doing is one of the best parts of my work. But my interest runs deeper than cultural tourism. Over the years, I’ve realized that understanding culture is central to what I do.
First, as an information architect, I must understand the culture of users. When I run a “usability test,” evaluating the system is only half my aim. I also hope to uncover the beliefs, values, andbehaviors of the people who use the system. Before imposing my own theories, I want to see how they define their world. What can we learn from their use of language and the way they sort concepts into categories? Which sources of information and authority do they trust? What is the meaning behind their behavior? For years, I’ve used lightweight forms of design ethnography as part of my user research practice. It’s helped me to better understand and design for oncologists, middle school children, university faculty, bargain hunters, and network engineers. And, as the systems we design only grow more rooted in culture, I’m convinced we must dig deeper into ethnography.
Second, as an outside consultant, I must understand the culture of the organizations for which I work. Today’s systems aren’t only integral to the lives of users, but they are progressively part of the way we do business. To improve user experience, it may be necessary to change the org chart, metrics, incentives, processes, rules, and relationships. Connections and consequences run all the way from code to culture. Software that doesn’t work “the way we work” will fail like an employee who doesn’t fit. So we must also study and design for stakeholders. In my research, I always interview a mix of executives and employees about roles, responsibilities, vision, and goals. And I’ve learned that if I don’t ask the right questions in the right way, or if I don’t listen carefully and read between the lines, I may mistake the surface for substance and invent a design that won’t fit.
Bi-cultural fit
Figure 4-1. We must design for a bi-cultural fit.
In short, the right design is one that fits the company and its customers. A mismatch on either side results in fatal error. We must use ethnography with our users and stakeholders to search for a bi-cultural fit. This is tricky since culture is mostly invisible. That’s why we should start with a map.
The right design fits the company and its customers—a mismatch on either side results in fatal errortweet this

Mapping Culture

Edgar Schein, professor emeritus at MIT and the father of the study of corporate culture, offers a useful definition.
Culture is a pattern of shared tacit assumptions that was learned by a group as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and to be taught to new members as the correct way to perceive, think, and feel in relation to those problems.
Culture is a powerful, often unconscious set of forces that shape both our individual and collective behavior. In an organization, culture is reflected in “the way we do things here.” It influences goals, governance, strategy, planning, hiring, metrics, management, status, and rewards.
And culture is an artifact of history. Organizational culture is rooted in the values of the entrepreneur. In the early days, as leaders struggle to build the business, the beliefs and behaviors that lead to success are internalized. Eventually they become taken for granted, invisible, and non-negotiable.
At this point, it’s difficult to decipher the culture without a compass or map. Fortunately, Edgar Schein’s model offers the orientation we need. We can use his Three Levels of Culture to ask questions about any institution.
Three levels of culture
Figure 4-2. Three levels of culture.
First, what will a visitor see, hear, and feel? Artifacts include architecture, interior design and layout, technology, process, work style, social interactions, and meetings. Who’s the boss? How can you tell? Is there music? Are people talking? What do they wear? Where do they sit? When do they eat? What makes ‘em smile? Artifacts are easy to see but hard to decode. The art on the wall is visible but what does it mean? Why’s it there? Artifacts aren’t answers, but they raise good questions.
Second, what are the mission, vision, and values? How about goals, strategy, brand? Websites, annual reports, and those colorful posters so artfully framed in the lobby offer a place to start, but interviews with insiders are the only way to the truth. Espoused values are hard to miss yet often inconsistent with behavior, which is why we need “informants” to help us see what’s really going on. If teamwork is a core value, why are individuals so competitive? If the organization is user-centered, why doesn’t anyone talk to users? It’s vital to listen carefully as insiders may not know or be willing to tell the truth. Dissonance and its justifications serve as keys to the invisible culture. Entry is earned by paying attention.
Third, what are the tacit beliefs that are taken for granted and non-negotiable? Level three is all about history. What were the ways of the founders that led to success? Are they still valid or holding us back? When we fail to seize the future, it’s often because we’re blinded to the present by the radiance of our past success. Assumptions are the bedrock of culture. They are hidden and resistant to change. As organizations grow, technologies advance, and markets evolve, friction between old assumptions and new realities is inevitable, but people don’t question what they can’t see. This is where an advisor can help. Only insiders can effect cultural change, but it often takes an outsider to sketch the map.
Intertwingled



Read more about how everything from code to culture is connected in Peter Morville's new book Intertwingled: Information Changes Everything.In it, he connects the dots between authority, Buddhism, classification, synesthesia, quantum entaglement, and volleyball.

A Pattern for User-Centric Organizational Change

go to article

Published: October 6, 2014
“During internal UX design presentations, many UX designers find themselves faced with well-meaning stakeholders who believe that their needs are highly representative of the needs of users, or customers.”
During internal UX design presentations, many UX designers find themselves faced with well-meaning stakeholders who believe that their needs are highly representative of the needs of users, or customers. For example, in recent months, stakeholders have told designers on my team:
  • “I prefer using a house icon instead of the word Home in the navigation, and I am sure that our users would feel the same way.”
  • “I used to be in the same field as our users five years ago, so I am sure that I know what they want.”
  • “If this is too difficult, we’ll just put more information in the training manual. That is what our users would expect.”
Rather than seeing this type of response to design decisions as an obstacle, I encourage my team to see this as an opportunity to help stakeholders understand that they are not representative of users. In all of the cases that I mentioned, my team already had direct user feedback that indicated the stakeholders’ assumptions were in fact incorrect. However, even this type of data may not be enough to change such deeply held beliefs.
On projects, for example, I have seen limited success when using tactics like providing access to usability test–session videos as a means of helping internal stakeholders to understand current user needs. While such an approach is helpful in building stakeholder understanding of specific user needs relating to a particular project, this type of learning is not necessarily portable across an entire organization.
After closely observing this organizational dance for several years, I conducted some research on how to help non-UX employees to develop a deeper understanding of user needs. The research that resulted from my curiosity about this issue eventually evolved into my doctoral research topic.
During that research, a pattern emerged that revealed a gap in UX professionals’ typical list of truisms. While “Know your users, because they are not you” is already on that list, we should add “Know your internal stakeholders, because they are not you” to the list. UX professionals are notrepresentative of the average employee in an organization.

The Listen, Learn, Act Framework

“I have been working with my team to develop the Listen, Learn, Act framework into a UX pattern for customer-centric organizational change.”
Employing this new point of view, I began to research a more systemic way of communicating current user needs to stakeholders—that is, non-UX employees. I created an initial, three-step framework—Listen, Learn, Act—to support more systematic user connectedness. During my research, I found that many non-UX employees feel frustrated when
  • they want to listen, but do not have access to voice-of-the-customer (VOC) data
  • they want to learn about, but do not have a clear sense of their firm’s customer-centric vision
  • they want to act, but first need to engage in training so they can learn how to apply customer-centric behaviors in their daily work 
Conversely, UX professionals—who are often more directly connected to user needs—become frustrated when internal stakeholders cannot understand how a design fulfills known user needs and, thus, their rationale for design decisions.
More recently, I have been working with my team to develop the Listen, Learn, Act framework into a UX pattern for customer-centric organizational change.  Communicating this framework using the familiar construct of a UX pattern has helped the designers on my team to tackle the problem of the stakeholder-user disconnect as a design problem instead of an issue relating to organizational politics. By applying this type of design thinking, we have reconceived our typical UX artifacts for the purpose of communicating with an internal audience and bridging the stakeholder-user gap.

Listening

“We start by listening and applying qualitative analysis practices to UX artifacts….”
In applying this pattern for customer-centric organizational behavior change, we start by listening and applying qualitative analysis practices to UX artifacts such as
  • Usability Reports
  • Ethnography Studies
  • Usage Metrics
During our analysis, we apply qualitative thematic coding across various customer-feedback listening posts.

Learning

“During learning, we take our coded themes and translate them into a customer journey map.”
Once we have a strong coding pattern in place, we can move on to the next phase in our pattern for customer-centric organizational behavior change, whose goal is to discover insights and learn from our data.
During learning, we take our coded themes and translate them into acustomer journey map. During this mapping process, we first create a simplified story about the customer’s journey when using our product. We then leverage this storytelling framework by inserting our coding from the listening phase so we can generate a data-driven storyboard. To increase the perceived validity of our journey map, we very carefully map our insights back to specific data sources. This approach has the added benefit of showing when it’s possible to triangulate a customer need across multiple listening posts.
Our goal during this learning phase is to create a journey map that both
  • conveys what our data shows is most important to customers
  • is comprehensible by a typical internal stakeholder in under ten minutes
The process of achieving this ten-minutes goal usually involves some pretty ruthless editing to ensure very succinct communication.
With this journey map in hand, our next step during the learning phase is to communicate the map broadly across the organization. By presenting this conceptual framework to our stakeholders, we build a common understanding of user needs—long before we present any design concepts. Because we have taken the additional step of tracking our data sources, stakeholders who remain skeptical can go back to the original data to review our analysis.

Acting

“We map our design rationale directly back to specific elements of the journey map.”
Having achieved an enhanced level of organizational understanding, we can then move on to the next stage of our pattern for customer-centric organizational behavior change and act.
During this stage, our primary action is to communicate a design solution and provide its accompanying design rationale. What makes this different from the way others might leverage journey maps is that we map our design rationale directly back to specific elements of the journey map. By delivering design documents that cross-reference our journey maps, we fully realize our pattern for customer-centric organizational behavior change. This approach lets us
  • build a common understanding of customer needs through easy-to-understand customer-insights education—using our journey map
  • deliver our design rationale within the framework of this common understanding of customer needs
By tying our design decisions back to the journey map—our common organizational knowledge base—we make our decisions less mysterious to our stakeholders. This can reduce the friction that is often associated with the socialization of a design.
Prior to the introduction of this pattern for customer-centric organizational behavior change, UX designers had tried to accomplish too much during a single design presentation meeting. They attempted to get stakeholders up to speed on user needs, while at the same time defending their design solutions. During those meetings, many stakeholders had seemed overwhelmed by the amount of information the designers were communicating to them, causing them to fall into the familiar pattern of assuming they were representative of the user.
Although this may seem counterintuitive, we actually gained greater efficiency by having two meetings instead of one. Separating user-needs education—our journey map presentation—from the communication of our design rationale—our design presentation—helped our stakeholders to more effectively digest the information.

Becoming Customer Centric

“To become customer centric, an organization must derive its goals from VOC data.”
To become customer centric, an organization must
  • derive its goals from VOC data—listen
  • communicate these goals broadly throughout the organization—learn
  • help employees to achieve these goals—act
By using this pattern for customer-centric organizational behavior change, UX professionals can position themselves as customer-centric change agents and create broader-based organizational support for their design solutions.
- See more at: http://www.uxmatters.com/mt/archives/2014/10/a-pattern-for-user-centric-organizational-change.php#sthash.e3Ykzsny.dpuf

Wednesday, September 24, 2014

Designing Around the Whole Story with User Narratives

ARTICLE NO. 1295 AUGUST 25, 2014

go to article

User narratives are becoming more popular as a tool for experience design. User stories, those discrete morsels of information that give us personas and a sense of action and motivation, are nothing new to design practitioners. User stories are often the trees, however, and the big picture—the context and purpose of the story—is the forest that designers fail to see. Taken alone, it's difficult to see how the user stories fit into the overall experience.
User narratives link a set of activities together in a seamless flow. They describe specific activities within a work environment, presenting a “day in the life of…” view of the user experience; using a persona to give the experience life, but providing context and embedding experience goals into the story. This narrative is the first step in designing an experience, serving as a framework for creating the flow and the screens that support that flow. Throughout the process, the narrative surfaces requirements and keeps the focus on both the end user and the context of use.

Creating the Narrative

At Kronos Incorporated, an enterprise software company, we recently embarked on a major new initiative to accelerate into the cloud-based market, and the UX team was tasked with evaluating and evolving many of Kronos’s previously held assumptions about their products and users. Rather than using existing products and well-documented solutions as the starting point, the team wanted to start from scratch and encourage new thinking. We decided that a user narrative could encapsulate requirements, personas, use cases, and work context in one short document.
We had developed personas prior to starting the new initiative, and now the product manager and interaction designer focused on three primary users, fleshing out the stories to highlight each user’s goals and actions, and linking them together in a linear fashion.
The narratives focused on the day-to-day actions of the employees using our products, beginning with their time spent prior to their arrival at work. Moving through that arrival and into their experience on the job, we explored the ways they planned, monitored, and executed tasks throughout the day.
We actively removed any “how-to” descriptions, eliminating the solution-oriented language that has a tendency to creep into requirements, and concentrated, instead, on the why. Focusing on the intent and on the user’s motivation allowed us to create an extended user story that did not prescribe a solution, but instead articulated a series of interconnected business needs. Then we color-coded the value proposition within each narrative, visually depicting how customer benefit from our products throughout the day.

The Narrative in Action

The end result was a non-technical, entertaining description of the expected user experience that mapped product requirements to larger business goals, positioning the narratives in a way that resonated with senior management. Howard Edwards, a Home Depot employee and Patriots fan, is the star of one of the narratives. Below is an excerpt:
“After hanging up his coat in the break room, Howard is ready to work on his first task of the day, which is building a Fall Colors paint display. Howard is easily able to “punch in” and record details about the task he is working on. He can also look at information related to the task like: how long the task is expected to take, and what is the average time it has taken employees at other Home Depot stores in the region to complete the taskHoward is excited to see if he can do it faster than his colleagues. He also sees that there is an employee discussion thread related to this task. Howard joins the thread, which says that the stand used to build the display has a faulty leg, and that it has toppled over in several stores. The recommended fix is to prop the display stand up with a can of paint to keep it from falling over.”
Value Propositions:
  • Effective planning
  • Productivity
  • Membership in a community
The individual narratives varied in length, from 500 to 1,500 words. This easily digestible format made each narrative easy to present at the beginning of a meeting, and equally consumable to people unfamiliar with the project and those intimately involved.

Narratives Have Power and Prowess

The power of user narratives lies in this accessibility and in their chameleonic nature. In the early planning stages at Kronos, we used the user narratives to provide a sense of scope so we could begin identifying workflow and information architecture that would address the user needs. Later, the narratives were an effective primer for bringing senior project sponsors up to speed about who and what the team was designing for, and for onboarding new people into the project.
The power of user narratives lies in their accessibility and chameleonic naturetweet this

Using the narratives brought a refreshing new way to express the big picture and the details together in an engaging story. We found people identified more quickly with the business purpose instead of weaving their own story out of the functional requirements.
A good narrative will transform itself to meet the needs of the team employing it. Developers may create a user narrative to visualize the system as it will be used by a specific group of people, revealing use cases and requirements that might have otherwise remained undiscovered until the application was built. By using a narrative as an introduction and a leave-behind piece, stakeholders—including architects, testers, and service design teams—are able to understand users and their needs, serving to promote a user-centric view even as the UX is just forming.
Because narratives strive to answer questions about who and what and where, when, and why things are done—staying away from how things are done—they leave room for design teams to interpret the narratives for their own process. The narrative that developers use to optimize efficiency could be used to pitch an idea to venture capitalists or stakeholders. That same narrative could be adopted by researchers to help with usability testing, and by the marketing department as the basis for a campaign.
A narrative can go as deep as it needs to, for as long as it needs to, which is invaluable during fast-paced development, using lean and agile methodologies. In these environments, requirements are often being defined simultaneously with interface design. Starting with a narrative means that a team can identify the requirements and get feedback before designing, putting the focus on therequirements and not on the design itself.

Presenting Your Narratives

The very nature of a narrative is compelling to audiences. Humans are more likely to retain facts when they are embedded in a story—the narrative allows us to make an emotional connection with the information, resulting in higher levels of understanding and investment in outcome.
Understanding this, and realizing that the narratives could have a powerful impact across departments, our team wanted to present them in a dynamic way. We introduced the narratives to the company as part of a project kickoff, initially focusing on securing funding and resources while also confirming direction.
Given the diverse level of audience members, we elected to use a Prezi animated slideshow to bring the story to life in a very fluid way, using the narrative as a script while presenting photos of people, places, and things that contextualize the narrative within a realistic setting. We presented specific screen concepts of UI designs, highlighting how narratives drive design by focusing screen design.
Prezi slideshow
The Prezi presentation was compelling

Conclusion

Our user narratives were received positively throughout the company, and have become an integral and ever-evolving part of our design efforts. We plan on continuing to use the narratives as a central theme, serving to connect what can at times be an overwhelming number of functional details that are produced in a product development lifecycle. They provide a consistent storyline to ground planning discussions right up to launching and training, and rescue related conversations from edge cases and dark alleys. Put simply: We love our user narratives.

Image of hardware store employee courtesy Shutterstock

ABOUT THE AUTHOR(S)

User Profile
Marc Cajolet has worked as an interaction design manager and UX strategist for 10 years at Kronos Incorporated.
User Profile
Sarah Bloomer has been working in the UX field for about 20 years, establishing companies in Australia and the United States. Currently, she runs her own consultancy, providing design facilitation, customer experience research and interaction design. She also works with UX teams, helping with set-up, training, mentoring, and coaching.
User Profile
Alexandra Stevens is an experience designer at Sarah Bloomer & Co., a Boston-based UX consultancy.