This is UX Design at Bixal.
A charter for the UX Design practice.
A charter for the UX Design practice.
The purpose of this charter is to define the practice of User Experience (UX) Design, as it exists today at Bixal. The content is based on a number of discussions and workshop sessions over the past year, including the most recent practice area charter activity in June 2020.
The charter contains the following sections:
How do we think and talk about our practice?
What is the why, how, and what of the UX Design practice?
This is a slight variation on Aarron Walter’s “hierarchy of needs of users.” When considering what people need, there is a priority, beginning with a foundation of usefulness. But any solution should include aspects of all three components.
Where does UX fit in among HCD, CX, and Service Design?
In User Experience vs. Customer Experience: What’s The Difference?, Kim Salazar of NN Group discusses scopes of experience at three levels: interaction, journey, and relationship. These roughly map to UX, HCD, and CX.
Because Service Design incorporates the design of the organization itself (people, processes, and props), and how it supports the overall customer journey, it is present at all levels, but in varying degrees.
The UX Design Team primarily operates at the interaction and journey levels. We are usually focused on a particular channel (e.g., a website) or a piece of that channel, but we’re also considering the context of the end-to-end journey of the customer: What did they do before this interaction? What will they do next? And what is their motivation?
What does it mean to have a human-centered mindset?
To understand the HCD mindset, it helps to consider the alternatives. If you’re doing organization-driven design, the priorities come from the top down. They typically define the technology constraints and the humans and their needs are an afterthought.
With an HCD approach, you start with the human needs, and you keep them central throughout the process as you factor in organizational priorities and technological constraints. This roughly maps to the IDEO concept of Design Thinking that balances viability, feasibility, and desirability.
Referring back to the levels of experience (interaction, journey, relationship), HCD is less an applied practice than a mindset that must be fostered throughout the whole organization and individual projects. It involves multiple disciplines on the project team (not just designers) and multiple departments within the organization. You can try to do UX Design without an HCD approach (which is a situation we sometimes find ourselves in), but the results are usually less-than-satisfactory.
How do we do what we do? And what are the outputs of those activities?
With an agile mindset, the way we conduct our practice is less about following a prescribed set of steps than working iteratively from a point of more abstraction to a point of more tangibility.
As our understanding becomes less abstract and more tangible, our level of confidence increases.
In the discovery and research iterations, this means talking to clients to better understand the goals of the project and talking to the people we’re designing for to better understand their needs.
In the design and development iterations, this means prototyping our hypotheses and validating our assumptions.
As we learn more about the people we’re working with and designing for, our level of confidence about what to do increases. And as we prototype solutions and test them, our level of confidence about whether we’re on the right track increases further.
The framework we use to communicate and validate this approach is the Digital Services Playbook from the U.S. Digital Service. The first three plays constitute a “definition of done” for major components of a project.
Do we know who the primary users are? Have we articulated what needs the service will address? If yes, we can proceed with a higher level of confidence. If no, we should do another round of research activities to answer those questions.
Are we using language that is familiar to the primary audience? Are we using language and design consistently throughout the service? If yes, we can proceed with a higher level of confidence. If no, we should do another round of design exploration and test again.
Sometimes these questions may already have answers. Not all projects start at the same point or run for the same length of time. And sometimes we’re not the only team working on a project. By approaching a project with questions to answer instead of steps to check off, we can adapt to different situations.
We have a collection of activities and tools we call the Bixal Methods that we’ve begun adapting from the original 18F version. Depending on what questions we have at a given point within a project, we choose an appropriate set of methods to conduct within an iteration of research or design.
Instead of mapping the methods to specific “phases” of a project, they’re organized by the “goal” at a particular point in the project in terms of the questions you’re trying to answer.
Each method includes a description of what the activity is, why to use it, and how to conduct it. This approach gives us a consistent, scalable framework for collaborating on and defining our key activities and deliverables over time as our practice grows and evolves.
While the Playbook and Methods provide guidance on what to do on a project and when, they don’t describe exactly how to organize and track that work within an agile project. Here’s how we’re currently thinking about it:
This approach helps avoid practice jargon and makes it more clear to all stakeholders (project team, practice leads, clients) what we’re actually doing and what to expect in terms of timing and output.
Here’s an example of how this might be structured in a Jira project:
How do we organize ourselves around these activities?
The UX Design Team currently consists of two primary roles: UX Designers and UX Researchers. More detailed information on each role — and the related skills and levels — is available in our Capability Framework.
UX designers collaborate with the whole team (client + delivery) to create and refine products and services that meet both audience needs and organizational objectives and are enjoyable to use. They consider both the end-to-end flow of the whole experience and individual touchpoints throughout the customer journey.
This role includes the following skills we look for and foster in our teammates:
UX researchers conduct research activities with actual users and communicate findings to help the whole team (client + delivery) develop a deep, shared understanding of the people who use their products and services. This research informs strategy, content, and design to reduce risk and increase the likelihood that implementation will meet audience expectations and achieve organizational objectives.
This role includes the following skills we look for and foster in our teammates:
Also, as a part of our personal and professional growth within the practice and our careers, we establish annual intentions, which are described in more detail in the UX Design Team Handbook.
How do we work with other practice areas on a project? And each other?
In the work we do for clients, we don’t think about it in terms of practices. These are same silos we advise our clients not to create. Nor do we think about it in strict, linear phases. This is the same “waterfall” approach we advise our clients not to wade through. Instead, we think about our collaboration in terms of the whole product we’re delivering and who does what at different levels of product zoom.
These levels are defined as Strategy, Structure, and Surface (along with The Big Picture) by Peter Merholz and Kristin Skinner in Org Design for Design Orgs. At each level, different members of the team are focused on different aspects of the overall product.
The UX Design practice is involved at all levels of product zoom. This is what our expectations are of collaboration with each of the practices at each level.
This level includes the vision and purpose of the project, along with with planning and constraints.
This level includes the foundational elements of information architecture, user flows, brand language, and design systems.
This level includes the tangible elements of typography, color, layout, UI, and interactions.
The Learning Practice is mentioned separately here because it’s a completely separate “product line,” with its own levels of zoom for each product it delivers. A Learning product also entails strategy, structure, and surface, but the team makeup is slightly different because of the specialized nature of these products. Instead of organizational goals, there are learning objectives. And the Instructional Designers essentially fulfill the role of UX Designer in this context.
We have established a variety of activities to encourage different aspects of knowledge sharing and collaboration across the UX Design Team. Most of these are geared towards increasing visibility and awareness of what the others are doing since we not frequently working in projects together.
How do we know if the project was successful?
“When measuring the effects of implementing a user experience, we need to look at the intended outcomes of the design. A UX outcome is the change we see in the world because we’ve done a great job implementing our design.” — Jared Spool
This is not something we currently do in any formalized way. These are two approaches we might implement moving forward, though one is more feasible than the other.
If we truly want to measure outcomes, we can return to the conceptual frameworks described above for the UX Hierarchy of Needs at the interaction level and the HCD Mindset at the journey level.
For each level, we could evaluate our solution against the criteria and make a determination about our degree of success on a given project. This would be ideal, but this approach is very difficult, if not impossible, with the way our projects are currently procured, staffed, and delivered.
Interaction level:
Journey level:
A more practical approach would be to measure and evaluate our actual activities as a proxy for success, with the idea that assuming we are able to do these types of things, it should result in positive outcomes (though it’s certainly not a guarantee.)
This is only a start, but the criteria could look something like this:
This charter is a living, transparent document and is open to feedback. If you’re part of the Bixal organization, you can leave feedback using this form. Otherwise, you can create a new Github issue.
These are the primary resources mentioned in this charter:
