This is UX Design at Bixal.

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:

Approach & Mindset

How do we think and talk about our practice?

The golden circle

What is the why, how, and what of the UX Design practice?

The hierarchy of UX needs

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.

Hierarchy of UX needs

The experience design landscape

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.

Scopes of experience: different levels of interaction between individuals and organizations

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.

Service Design progressively impacts all levels of experience

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?

Our team primarily works at the interaction level while keeping in mind the journey level

Human-centeredness vs. other approaches

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.

Organization-driven design

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.

Human-centered design

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.

Activities & Outputs

How do we do what we do? And what are the outputs of those activities?

Agile mindset and levels of confidence

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.

Over time, we move from more abstract assumptions and solutions to more tangible ones

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 things become more real, by talking to people and building things, we become confident

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 Playbook

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.

  1. Understand what people need
  2. Address the whole experience, from start to finish
  3. Make it simple and intuitive

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.

The Methods

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.

Questions and methods from a research iteration plan

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.

Mapping to an agile project framework

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:

Organizing plays and methods into epics, stories, and sub-tasks


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 Designer

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 Researcher

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.

Levels of product zoom from Org Design for Design Orgs

UX Design

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.

Collaborating with each other

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.

Measures of success

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.

The outcomes model

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:

The outputs model

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:

Thank you!

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: