In our last article, we explored the elements that make up a mature UX practice and how they apply to project teams. We also looked at some ways in which we could encourage better behaviors on projects, guide teams, and design positive experiences for people. In outlining the elements that encourage the design of a humane UX practice, we considered current and future states, an academy of learning, values and beliefs, the language that a project team uses, toolkits; soft skills, or human qualities that deserve continuous practice; spaces in which to design and validate solutions, learnings from stories; and well-understood, shared artifacts for members of project teams to use in telling their common story, independent of their role on a project.
As we continue to study project teams in business, we have been thinking about the following questions:
Does a project team require defined roles to be successful?
How can individual roles enhance team performance?
To what extent do specific research approaches enlighten awareness of actual people and embed that awareness in a teams reasoning?
How might we ensure that a team’s artifacts are sufficiently relevant to connect the logic of various team members and overcome divisive reasoning?
How could we ensure that our approaches, toolkits, and language better represent hidden knowledge about actual people?
How might we eradicate fears, identify biases, and overcome false assumptions that limit team performance?
We have been observing and reflecting on project team’s behaviors and considering whether people have the time necessary to actually practice particular routines. This goes far beyond just quickly implementing new routines. Adopting the wrong routine could cause serious damage to team morale and, ultimately, negatively impact the quality of their work. So, before we jump into our methodologies or toolkits of choice, how can we help a project team to recognize helpful routines and practice them in a structured manner—giving them a better chance of contributing to meaningful projects?
So, let’s go back in time.
When Dan was in secondary school in Australia, in the 1980s, his school decided to introduce drama as a subject in the curriculum. This was new to all of the students. In rehearsing the skills that they needed to do a play together, the students had to constantly practice different routines in class—both to get better at performing and to gain confidence when in front of an audience. Practicing these routines, as individuals and in groups, involved different forms of expression, including voice, movement, mime, warmups, and script readings to name a few.
These routines enabled the students to improve various skills that they needed to be better performers, including observation, leading, listening, connecting, framing, playing, and storytelling. It also allowed the students to explore different parts of their personalities and open up beyond their other day-to-day classroom or playground interactions.
Their drama teacher was very effective in taking the lead, showing them that it was okay to take a leap into the unknown to gain confidence—even though some were fearful. He was also very skilled at connecting routines together during rehearsal, which led to the improvements that were necessary to perform a student production at the end of the year.
Projects Need Routines
On projects, we define a routine as a combination of tasks or activities that foster better habits and behaviors over time, which results in the design and development of more meaningful experiences for people. So, for projects:
What are the routines that exist today?
What routines deserve more attention and practice?
Routines of Practice That Are Prevalent Today
We have identified certain helpful project routines and observed that teams rarely practice them with any rigor—and typically fail to think about them during project planning or when bringing together a project team. Most of the time, project team members get stuck in an implementation routine that leaves them little time or attention for the other routines that we’ll discuss.
We’ll share our draft list of project routines with you, and we’d be very interested in knowing what other routines you’ve observed on projects. We’re also open to reconsidering our use of the word routine, as we try to identify the right language to communicate these ideas. We’re not entirely sure routine is the best word to describe what we’re talking about. It’s important to note—in the spirit of holistic and connected thinking—that these routines need not progress alone; some work best in parallel streams. Some of these routines do not yet exist on any projects.
Similar to Dan’s drama teacher in Australia, an owner and facilitator of these routines is necessary to ensure that we work them into our projects, that we practice them as we iterate designs, and that people get the time necessary to improve their skillsets relating to their roles.
Now, let’s get to the routines.
Exploring Courses of Action
In exploring courses of action, the team experiments with and introduces change to social, technical, and business systems that exist in the world today. This routine focuses on determining or adjusting innovative means of achieving, promoting, or delivering new solutions.
implement—In this routine, a team is heads down, trying to get solutions out the door, and does not have much time for any other routines. There is little time to plan.
experiment—A team plays with a number of options and employs user stories in talking about goals, issues, improvements, and outcomes, as well as in assessing what options to aggregate into positive outcomes going forward. (More on this later.)
explore outside worlds—A team leaves the comfort of their project room to go out and observe their customers’ world. This helps them to look beyond single, stand-alone features to holistic design solutions and map features to contexts of use—whether known or unknown.
Defining Our Intentions
In defining their intentions, team members take the time to interact with one another and their stakeholders and share existing knowledge. They develop a plan and agree on a project’s focus, exploring how it will determine the quality of project outcomes.
plan—A team devotes time to planning ahead rather than just spending time churning on implementation.
focus—A team determines what specific elements of a design they need to improve and, thus, focus on during discussions and critiques. A team deliberately eliminates other, less valuable routines to allow the project team to focus.
Generating Experiments in Advance of Judgment
When generating experiments, a team envisions changes to the situations and challenges that customers face by creating a multitude of sketches or rough prototypes. The best routines for experimentation enable a team to do this without censoring anyone's imagination.
sketch—A team works at a whiteboard or uses paper and pencil to help them quickly iterate through ideas, without committing them to code. This helps them to determine which design solutions deserve further investment of time.
envision—This routine is almost the opposite of implement. A team takes the time to consider alternative futures and explore them without critique or the constraints of operational, technical, or other realities. At this point, innovation can potentially happen—though it is not unique to envisioning.
Sharing Observations about a Situation
When sharing observations, a team comes together to read stories about human behavior and record them in the team’s collective memory. This routine enables a team to identify surprising or deeply memorable situations that deserve further analysis by the whole team.
tell stories—A team shares the stories that they’ve collected during user research with other team members, interprets the stories, makes sense of their observations, and determines what artifacts would give their observations and insights life.
share assumptions—A team lists their assumptions—discussing their source and the evidence available to support them—and either challenges or accepts assumptions or sets of assumptions. This helps a team to prioritize certain features by determining what features deserve more of the team’s time, focus, and attention and what features require more research or further design iterations.
Interpreting Everyone’s Observations
In interpreting observations, a team must make sense of what they do and don’t know.
deconstruct—A team looks at the available data together and makes sense of it by applying different lenses, then determines what it means.
aggregate—After deconstructing and making sense of the data to determine what it might mean, a team aggregates groupings—for example, features and feature sets, a roadmap, design principles, or target goals for the next release. Aggregating helps a team to take stock of what they’ve learned and decide whether they must iterate the project team’s artifacts.
join the dots—A team joins observations and insights from their various artifacts. For example, what issue is a persona having that may have implications for designing a screen or affect an interaction in a customer journey and could impact the overall offering. This helps project team members to look beyond the viewpoint of their own function and explore other parts of the story that could help a product or service to be more successful.
Identifying Prior Assumptions
In identifying assumptions, a team takes a pause from their work to reflect on the evidence they’ve gathered, the approaches they’ve taken, the experiments the project has generated, and the team’s own reasoning to identify their biases and open their minds to external criticism.
walk the wall—A team displays its project artifacts on a wall and collectively reflects on them to understand how all of them interconnect and determine whether there are any issues or opportunities that deserve further attention during the following weeks. For example, they may describe a story that relates to a persona, walk through a layer of the journey map, or list out their assumptions that deserve further investigation through user research.
reflect—A team has the time and space to rise above the project details for a bit and reflect on what the team has learned and how they might improve the ways they work and practice together.
assess assumptions—A team again has an opportunity to list out their assumptions or sets of assumptions and discuss their source and the evidence available to support or challenge them. Doing so enables the team to determine what features to focus on and set priorities.
critique—A team critiques the design and captures structured feedback to improve the design in future iterations. The team can use learnings from a critique to discover unknowns that require further user research.
These are just a few of the routines that we’ve observed on projects. What routines have you noticed during your project work? Are there some that we’ve missed and deserve more attention?
UX Hong Kong 2015
We founded UX Hong Kong in 2011 to bring all product and service design disciplines together—including research, marketing, design, technology, and business—and provide a gathering place for people who are interested in and passionate about designing great experiences for people and helping businesses to create a better world for all. UX Hong Kong is now its in fifth year, and we have a great program planned for 2015.
Daniel is based in Hong Kong and helps companies in Asia like PCCW, HSBC, CSL, China Light & Power, Sunday, Cathay Pacific, Marriott, ADB, and Yahoo! China make their products easier to use. He has also worked with Telstra Australia and IBM. Daniel has spoken on Usability in Hong Kong, China, Singapore, Malaysia, United States, and Australia, helping to develop new groups of interest in the region. He recently co-wrote and released the Usability Kit with Gerry Gaffney. Daniel is a founding member and President of the UPA China Hong Kong Branch, co-founder of the UPA China User Friendly conferences, and holds a BS in Information Management from Melbourne University Australia. Read More
Jo Wong has practiced as a usability consultant in Hong Kong for the past 10 years, working with companies such as PCCW and CSL. She specializes in conducting usability tests in both Cantonese and Mandarin. She is a member of the Usability Professionals’ Association (UPA) Hong Kong Chapter and promotes usability through her work with the Internet Professionals Association. Jo attended Melbourne University, completing a Bachelor of Social Science Information Management. Read More
As a Product-Portfolio Manager at Nokia, Michael led design-research planning, portfolio studies, and work practice innovation projects, all of which represent boundary objects. Michael’s work introduces human-centered reasoning as a practical way to reorient profit-and-loss decision making and create value for people. His prior work in the domains of corporate strategy, design strategy, consumer insights, business-process design and concept making, and industrial design enabled each silo to reason more clearly with each other through design thinking. Prior to receiving a Masters in Design Methods from the Illinois Institute of Design, in Chicago, Michael was a Professor of Industrial Design at Humber College, in Toronto. Michael is particularly interested in the topic of mastery and the forces that confound it during innovation planning. Read More