Contents
UX is a team sport. And for the team to work well, they need to know where they stand. As a UX agency, we are working with teams, we have never worked with before. But our aim is always to understand the team we are becoming a part of as much as we can to collaborate better. That is why we developed our own UX Maturity Model.
Our UX Maturity Model arose from many questions and issues, such as:
- How does UX team involvement in product related decisions benefit us?
- Why test the product/prototype each week and with only five user testing sessions per iteration?
- For what reason does a developer attend the meetings at even the wireframing phase?
- Why meet the product team in person when we can do everything remotely?
Many similar questions come up during meetings (especially kick-offs) and answering them all and justifying the process consumes quite some time and energy. This precious resource could go to the product itself.
Why we developed our UX maturity model
While working with clients (product owners, designers, head of departments, stakeholders etc.), we observed patterns in these questions. It didn’t correspond to job or position, nor company size. It related to UX experience and attitude (openness to feedback and the ability to adapt). So in essence, the UX strategy.
Others have had similar experience and have already done very good mapping of UX maturity stages, but we felt something was missing. So we started to create our own list.
As a result we ended up with three situations (three levels, in fact). They form the basis of our UX maturity model. Note that we customized for our work methodology, so it may not work as well for others. Find the UX maturity model that best fits your needs.
Our most common collaboration setup looks something like this:
Usually, we link the users and the product. We represent the user’s needs and help the product team create a lovable product. And of course, all this needs to benefit the stakeholders too.
In most cases, we work closely with “just” the product owner, who unfortunately does not make the final decision. In many cases, we didn’t have access to C-level personnel.
This leads to slower, more difficult collaboration because we have to cross-check design questions and solutions with the PO (and the product team, designer etc) and then wait for approval from a decision maker (C-level person) and in some cases in vain. Involving the decision makers in UX workshops also gets the necessary answers.
Interested in our UX methods? Download our free e-book now: Product Manager’s Guide to UX Design.
Our UX Maturity Model
We created ours to achieve better collaboration with our clients.
Our UX Maturity Model improves our work by helping the client understand how we work. We use it more as a feedback tool. It becomes as useful for our clients as they are open to constructive feedback.
Both the client in a project or a member of the design team can use the UX Maturity Model to map the level of collaboration, separately or together. When all players participate (stakeholders, product team, design team, UX team, developers), it results in better outcomes.
How It Works and How We Use It
Our UX Maturity Model accomplishes two things:
- Identifies possible improvement points to achieve better collaboration between the product and UX teams, and
- By providing actionable feedback, it sets the next steps
The model comprises three levels and a certain number of statements for each (like a checklist). Together with our clients, we go through and check off the fulfilled/true ones. Imagine them grouped into three levels differentiating client involvement.
If we have fulfilled those from the first level, we have achieved the second level of maturity, and collaboration moves to level two. If we have checked off all level-two statements (as well as those from level one), collaboration reaches level three.
Important: we must check off ALL statements on a certain level in order to move on to the next! If even one statement from level one (no matter how tiny it may seem) is not fulfilled, it means that we stay on level one, no matter how many statements we checked on other levels.
We identify the three levels on our UX Maturity Model as:
- Interested (starting level, the base)
- Engaged (advanced, level two)
- Core Integrated (best case scenario).
Beyond the 3 levels we differentiate between two cases when it comes to applying the model:
- Case 1 – Only we deliver the design; no other team or person does.
- Case 2 – We comprise one part of a bigger design team; an in-house design team or another company may also work on the design.
The former is more complex and we will present the levels from the point of view that the UX team comprises part of a bigger design team.
We won’t elaborate on the zero level, since it typically shows hostility towards UX. Yes, even today some companies find user research unnecessary. Fortunately, there are less and fewer companies working this way.
Level 1 – Interested: UX team as a supplier
At this entry-level point, client interest in UX and consideration of it as a factor in product development should make us glad. However, keep in mind that there is much to show at this point.
Characteristics: In our experience, the client sees the UX team as a supplier at this level. This means the client has fixed ideas and would like to execute them with zero or minimal modification. They do not consider input from research a game-changing element and thus big modifications won’t take place.
As a UX team, your task is to bring the client up to speed with the UX methodology. Show them the “whys” and “hows” so they can understand the added value which UX brings to the product.
In the long run, it pays off to involve the client in every step and detail, even if it requires more attention and resources from the UX team.
Level 2 – Engaged: UX has an acknowledged importance
At this advanced level, the client acknowledges the importance of UX and probably has some experience in working with a UX team.
Characteristics: In our experience, we are considered partners. As such, we provide information supporting the decision makers and their job. They often consult us for design decisions or we even have the liberty to make changes without consultation. In either case, a well documented, transparent process needs to form the base of every design change made.
We always conduct user research in every phase of the project (sometimes even before starting, just to get the necessary domain knowledge). The research provides extra input that may help stakeholders or product owners to strategize. The findings help not only in design related questions, but also provide good intel for business decisions.
We don’t always take part in the decision making the process at this point, but rather at the next level.
Level 3 – Core Integrated: UX is an equal part of the product development
At this highest level, we have fully incorporated ourselves into the product team and its processes.
Characteristics: Fully integrated into the project, the client considers UX team equal who also take part in the decision making process. In other words, we have a seat at the table. Due to the high degree of involvement, we often consider the product our own.
We can use our full skillset in these cases, providing input to improve processes in sales or marketing. At the lower levels we don’t even dream to get involved to such degrees.
Design follow-up should appear at any level, but financial and methodological barriers make proper implementation at the lower levels difficult, even if we create a measuring system. Sometimes the client does not value following up product development enough. As a living thing, a product needs attention at every stage, and even more when reaching a stable form.
The more statements are met, the better the collaboration between the UX team and the client gets (no meetings consuming time and energy or fights with the client over methodological questions). As a result, we often end up with fruitful long-term relationships, sometimes even longer than the project timeframe.
Recommendations to the model
Timing
Timing is crucial! Certainly it needs some work experience from both the client and UX team. Best discuss the statements after at least two to four weeks of joint work, also depending on the intensity of the collaboration.
Mind the level
Before bringing up the UX Maturity Model, take a moment to imagine how the outcome can affect the collaboration in a positive way. Check the statements without the other party and make a pre-evaluation to establish a possible level.
This is a tool
Always approach the problem focusing on the solution and try to imagine how this tool may help achieve the desired outcome. If it feels like the tool does not suit the purpose, it probably doesn’t, so don’t use it.
Keep in mind that this is how it works for us. It doesn’t mean that (in this form) it works just fine for others as well. And as with any tool, it can be improved, so your feedback is welcome!
If you want to read more on our UX design approach and processes, check our Product Design book!
