UX Tips: UX Maturity Model
Lately, I’ve been considering the future of UX. Recruiters often reach out to me looking for candidates for job opportunities they have open. I’m often stunned by the breadth of expertise UX applicants are expected to have: business analysis, visual design, application UI design, usability research, project management and programming skills – skills covering all aspects of the project lifecycle. Which prompts the question: should one person on the project team really be responsible for all aspects of user experience? Would it be more reasonable to expect that user experience is not one team member’s job but rather the responsibility of every member of the project team – from project manager to developer, business stakeholder to visual designer?
Likewise, we regularly talk with folks struggling to sell UX and usability in their organizations, even when their organization fully acknowledges it has a problem. The UX champions are often frustrated and beaten down, and in some cases, it’s been a several years long struggle. The problems they’re encountering are usually one of the following:
- Political struggles prevent adopting UX as a solution. The central problem in these cases is usually low trust between the team advocating UX and the other teams.
- The organization wants to adopt UX as a solution, but there’s disagreement about how UX will impact their workflow, budget, and their customer experience.
- UX is embraced as an organizational strategy only to come under scrutiny later for failing to provide measurable value.
In a mature organization, should there even be a conversation about UX as its own distinct activity? Shouldn’t the user/customer’s wants/needs/motivations be the focus and priority of every job position in the organization?
So how does an organization adopt and integrate UX into its culture, and, perhaps more importantly, how does the role of UX in the organization evolve until its totally integrated? Over the years, several UX Maturity Models have been proposed, but even two of the better models we’ve found — Bruce Tempkin’s Customer Experience Journey (2008) and Tomer Sharon’s UX Research Maturity Model (2012) — don’t reflect our experience trying to establish user-centered cultures at many organizations. Bruce’s model is written from the perspective of somebody on the outside looking in. It’s missing an understanding of the politics and dynamics of how an organization integrates UX into its culture, and this limits its utility to UX champions trying to convince senior management to commit to UX. Tomer’s model might be useful to a consultant trying to identify a difficult client, but it’s too simplistic to be of any value to a UX champion trying to create change. Any large organization will have varying levels of buy-in and staffing across multiple groups (simultaneously approaching maturing and immaturity), and UX professionals need to understand how to be successful in those environments. Most of us don’t want to flee from a challenge as Tomer would recommend we do.
So we set out to create Normal Modes’ own UX Maturity Model based on our experience introducing UX to large and small organizations. We’ve adopted Bruce Tempkin’s five stage structure, but you’ll notice that the stages of our model focus more on the early stages of adoption (where the struggle is most acute) and on the internal dynamics. We hope that his model will provide comfort, guidance and professionalism to champions as they navigate their way toward better applications.
Normal Modes UX Maturity Model
Stage 1: Unimportant
No institutional consideration for how users engage applications. If a user has difficulty with the application, the user is often belittled and/or mocked. Technology/design team is arrogant in their assessments of how applications should be built and defensive about any feedback which criticizes the application. Product/project team is bewildered about how to improve application for better outcomes.
UX isn’t even on the radar as a possibility. If awareness exists, the concept is often derisively considered a frivolous activity, akin to “putting lipstick on the pig” or adding in wiz-bang features of little substantive value.
Stage 2: Exploring
Little institutional awareness of how users engage with application. Using more organized language from previous ad hoc reports, users now state the application is “difficult to use,” “difficult to learn,” “cluttered and ugly,” and/or “unusable.”
One or two like-minded individuals from the product/project team begin to research user-centered design as a way of mitigating future issues. Armed with information about another way, they approach members of the team and leadership about their findings.
RISK: Feeling ineffectual, team members move on to “more solvable problems,” like feature enhancements, complete redesigns of the application, or other jobs (internal or external).
Stage 3: Emerging
Personas emerge as a tool to connect team with users. Pilot programs may emerge, though methods for obtaining user feedback are poorly structured. UX is considered a “nice to have” optional add-on feature to the application, so the ability to quantify investments is explored. Many still view UX as simply pretty “design.” UX is seen as a zero-sum game versus technical imperatives and business objectives. Funding and staffing for UX efforts is limited.
The concept of UX as an institutional value is a political battle between two sides: the dogmatic believers and the skeptical/no-frills/paternalistic traditionalists. Believers are hampered by their naïveté & lack of specificity, but helped by obvious application problems coupled with user feedback. Traditionalists are aided by a strong institutional legacy that protects or promotes their dismissive/hostile attitude toward UX/usability, while they’re hampered by feedback from the application’s users.
RISK: Unless organization leadership signals approval for UX in both financial and symbolic ways, UX efforts will collapse and team will revert to Stage 1.
RISK: Frustrated early adopters may flee to more mature organizations and efforts will revert to Stage 1.
Stage 4: Committed
Projects strive to balance business, technical and user needs with great success. UX is the responsibility of several specialists who have titles like UX Designer, Information Architect, and Usability Specialist. Major portions of the application are overhauled, often in a phased redesign. Usability testing, if conducted, is at least partially outsourced. Quantifying the ROI on projects includes UX.
Some traditionalists remain skeptical. Users and UX-related roles momentarily marginalize all other project roles in terms of perceived importance. The potential negative effects are somewhat neutralized by the organization’s excitement over seeing positive feedback from users and visible progress toward successfully meeting project objectives.
RISK: Identifying and hiring qualified UX-related job candidates.
RISK: Excessive focus by UX team on meta activities that provide little residual value.
RISK: Never progressing to a point where UX is the responsibility of the whole team, not just individual contributors.
Stage 5: Mastered
UX is an institutional value that every member of the organization shares equally in upholding. Feedback about the application’s usability is captured proactively and transparently with a in-house usability lab, even if uncovered issues cannot all be resolved in the immediate future. The development teams use a robust design patterns library to facilitate rapid development, with assistance from a UX expert as needed.
Every team member’s contribution is known and valued. Users are treated with dignity and respect.
RISK: Slip in application’s performance as hubris leads team members to make false assumptions for complex or tricky issues. Lack of ongoing education, which can be expensive for such a large team, may play into hubris, knowledge, and limited skills. (Dunning-Kruger Effect)