Problem-solving in design is less about the screens, and more about the relationship of the person using your solution to what they consider a successful outcome.

Early in my career, I designed screens by leveraging my background in debate.  I would take a series of observations, outline a plan and then describe projected benefits.  It was very efficient and structured, and had it's justifications built in.  The problem was, as in a debate, there are always two sides, and having the design advocate for one solution based on cherry-picked observations is missing the point.  We are not our users, and need to fall in love with the problem, not the solution.

More recently, my problem solving has more to do with storytelling.  I need to understand the characters, their background, their motivations, what is holding them back and what they dream of.  Not every character is the same, but every character is the hero of their own journey, and our role as designers is that of the mentor, guiding them through their experience to achieve their goals.

Finding that journey, and understanding I am not at the center of that journey, is critical.  Once you really understand the journey, laying out screens to support it is nearly secondary.

When I was in college, one of my best friends, Kevin, was an English Lit major.  I often asked him what he expected to do with a degree like that and his answer was simply, "Tell stories."

He did eventually publish two books (I have copies of each on my bookshelf), but held many other jobs before that happened.

No matter if he was working as a call center representative, marketing copywriter, or account manager, he was still writing.  It was only recently that I saw how his job and mine are similar.  Being a storyteller requires understanding his audience, structuring the presentation of knowledge and delivering a desirable experience.  He was analyzing and writing "The Hero's Journey" while I analyze the Client Journey.

The Hero’s Journey is a common story structure for modeling both plot points and character development. A protagonist embarks on an adventure into the unknown. They learn lessons, overcome adversity, defeat evil, and return home transformed.  Think of all of your favorite stories and you can see how the structure is used.  Harry Potter, Star Wars, The Matrix, Spider-Man, The Lion King, Lord of the Rings - they all follow common themes.

Likewise, the Client (or Customer) Journey follows similar themes, regardless of your industry.  The points can be expanded and detailed filled in, but you will nearly always see overarching stage of the client experience.

• Awareness occurs when the client first hears about your market offering and becomes interested.  Much of this research is done through brokers or word of mouth, but our web and marketing efforts are a critical part of the client experience.  

• Consideration allows us to deepen our relationship with the client through an experience that feels like a conversation.  We have to create a compelling story for our clients, lay out the benefits and overcome resistance, and provide calls to action all while letting our clients get to know us, our values and principles.

• Acquisition is when the client commits to taking action. This step can include purchase, options, configuration and installation.  We have to ensure the client understands what they've purchased and reinforce the wisdom of that decision.

• Service, in my industry, is delivering on the promise for the duration of the contract.  Providing status updates, ability to submit claims or administer the policy are all important day-to-day activities and must be handled properly to encourage renewal.  During service is also a good time to describe additional features or services for increasing customer entanglement.

• Finally, Loyalty happens when the service contract is complete, or the client is back in the market. A lot of retention and loyalty comes down to your customer’s experience, and it is much less expensive/more lucrative to keep a current customer than to try to find new ones.

In client experience, we have to find ways to really understand what our clients' needs and concerns are.  We map the client journey to identify what key moments are working, which ones are causing pain and which ones could be even better, leading to more client satisfaction.  By anticipating and overcoming objections, and making the administration of the tool as smooth as possible, we can keep the client happy and engaged for years to come.  And that gives us time to tell more stories.

Knowing where you're going does not always required you to know where you've been.

I teach orienteering and GPS navigation to Boy Scouts, and hear a lot from older Scouters on both sides. Map and compass guys always tell me they would never trust themselves to a battery-powered device when they are in the wilderness, and GPS guys scoff at the sets of directions like “go 342 degrees for 120 feet” and can’t believe anyone still does that.

On the one hand, if you use a map and compass, you have to have a better feel for the topology around you and understand each step (pardon the pun) of getting from point A to point B. If you use a GPS, it doesn’t matter where you start, you can get to point B as long as you trust the technology implicitly and it doesn’t fail.

I see parallels in the discussions I have at work sometimes. There are older coders (like myself) who grew up with computers we programmed from the ground up, going through DOS and Unix commands, working intimately with the file system, and understanding HTML from the foundational levels. That gives us a strong background on which to understand the performance model of the software and what could be wrong when things don’t work as expected. On the other hand, younger coders don’t care that you used to have a DOS layer with Windows on top and a browser above that. They have been digital natives their whole lives and can take for granted much of the early years of computing because they rely on tools and frameworks that shield them from the minutia. They have difficulty when the code doesn’t perform as expected, because they don’t really understand everything that it is supposed to do in the first place. Having said that, they also can keep pace with change better because they don’t have a ton of bad habits to break, and they don’t have the same blinders on about what is possible and what isn’t. Not knowing something is impossible is often the first step to making it possible.

I am grateful I grew up when I did and have an understanding of what came before, while being able to take advantage of tools that don’t require me to code everything by hand anymore. It’s a balance that everyone has and I’m sure years from now the young coders today will be complaining that the new coders of the day don’t understand the CSS and Javascript libraries they are using in the next generation of technology. To quote Battlestar Galactica – “All of this has happened before, and all of this will happen again.” So say we all.

The design principles and processes I follow came from working with many organizations, with varying levels of established design principles.

Design Principles

 Respect the entire journey

 Be clear and transparent

 Inspire confidence in action

 Innovate intentionally

Design Process

I follow the double diamond design process to design the right thing and to design the thing right. Here are a few points of emphasis in my approach:

1. Know your users inside and out.  Focus on performance context and attitudes as well as their behavior and attitudes.  

2. Fail fast! Whether it's a concept, prototype or beta product, get something in front of users or stakeholders quick so you can learn and align.

3. Scale, don't skip UX activities. Maybe you don't have time for the ideal discovery and synthesis activities with authentic users, but it's critical to fit some research into the amount of time given to accomplish a task.  Something is better than nothing.

4. Do as little as required to get to shared understanding.  Don't get stuck researching endlessly, or let perfect become the enemy of good enough.  You should always plan to validate and refine as your understanding of your clients and their tasks evolves.

5. Invest more time in discovery and validation to mitigate risk.  The cost of bad assumptions is always higher than upfront research.

6. Rely on design systems and style guides to reduce design times.  The consistency gives users confidence and helps cement your brand.

7. Design is never done - After the design is accepted, designers must stay involved in handoff to the engineers and a partner in scaled agile development, to ensure the design remains desirable, feasible and viable.  Once in production, designers must start testing all over again to uncover performance hurdles, bugs and design changes to continually improve.

In 1959 Donald Kirkpatrick introduced four levels of evaluation to the learning profession: reaction, learning, behavior, and results. These same levels can be massaged to describe the impact of XD. Thirty years later, Gloria Gery courageously informed us all that we might as well just weigh our students before and after learning, rather than use the metrics we were still using to determine the effectiveness of what we do for organizations.

Current tools and models for measuring design

Many organizations begin and end with user satisfaction measurement.  Measuring the user satisfaction is not enough. Although it is a good product metric, it doesn’t provide the information needed to the design team itself to improve upon.

Design maturity is hard to act on

Design maturity describes how well an organization listens to customer and user input, and how customer and user-centric its design processes are.  Design maturity results in stronger development processes that deliver more consistent products, services, and experiences that delight users, win customers, and enable true differentiation for your brand.  

The next question is, how do we evaluate design maturity?  There are many models out there to describe the continuum on which organizations exist.

• Deloitte has 4 levels

• Invision has 5 levels

• Nielsen/Norman originally had 8 levels, but now has 6 levels

For the purpose of this article, let's use Nielsen Group’s current scale as an example:

While design maturity scales like this are a great way to better understand where the design is at your organization and what it should aspire to, its interpretation can be subjective:

• Executives might argue that the team is on stage 4 because it has a dedicated budget within the company.

• A design team member might claim that it's on stage 2 (developer-centered) because design decisions are made without enough user research.

• Different designers can also disagree about their impact and influence on Product and Engineering, and that can vary by team or individual.

This is a great discussion to have both with your team and with the big bosses. However, a design maturity scale often lacks something tangible to be measured against and to indicate if any progress has been made over time. Increasing the maturity of the design team is not something that can be rushed. It can take years.

Measurable attributes of design maturity

To measure the design maturity, we first need to define metrics that can be used by any design team, regardless of the context of work and team composition.

To do so, we can look at the basic elements of any design project. 

Design system

A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem. It consists of a guideline and repository of patterns, components and assets an organization has, but it goes beyond: it means designing, planning and maintaining a consistent experience, unique to the brand and its tone and voice.

Design process

The design process is, simply, the design process used by the team. A library of methodologies and good practices to ensure a high quality standard and consistency in the work done. Not all problems can be solved with the same approach, but having a main framework can facilitate collaboration and makes other tools and methodologies more accessible.

Design vision

Design vision is the direction where the team sees the design heading. It is formed by principles, values, and even their "blue sky" concept for the business, aligned with the company's mission and goals. 

Whether or not we are actively thinking about these three elements during a project, they are the main ingredients of any design team. Every design project has an interface system, follows a process, and has a vision behind it.

Defining the maturity metrics

Within these three elements in mind, we can define points to be used as metrics for each. These points can vary a lot depending on what is important for the team and for the business, from something specific and tactical to a broader satisfaction score with that element. Here are some examples of what could be used as metrics:

Design system

• The presence, stability, use and effectiveness of interface elements and composition, such as color, typography and iconography, fully mobile-responsive and meeting accessibility standards.

• A clear voice and tone guide, keeping the experience consistent and on-brand.

• The designers' satisfaction working with the current pattern library.

Design process

• A consistent high-level process, from discovery and research to QA and launch tasks.

• Clarity for the team of all design steps and knowledge of the tools and methods available.

• Opportunity (space and time) to study and experiment different methods and cross-team collaboration.

Design vision

• Clear business goals and a clear user market. Every designer should understand the company's mission and high-level roadmap.

• Design principles and vision that the team shares and is confident to use in their projects.

• Design initiatives and projects, aligned to its vision, and not necessarily directly linked to a company's project or product.

• Design literacy in the organization, and how deep and wide is the impact and influence of user-centered design.

Setting up a process to measure it

Regardless of the metric points decided for each element, the team will need a rating scale (o to 10? Five stars? Emoji faces?) and specific weights for each point selected.

Defining what and how to measure should be a process owned by the team. Every design team has a different and unique context that needs to be taken in consideration. Any formula has the risk of being too generic. Discussing the metrics and the approach is a great starting point for any evaluation discussion and also makes the team feel like they are owning their self evaluation mechanism.

If the design team concludes that the current state of any of these elements is not satisfactory, they have a clear direction on what to work on and a good argument to ask for more resources for the team if needed.

One can argue that it’s impossible to do well in any of these three areas without doing well the others. It is true, but their level and quality can vary a lot. And that’s exactly why we need to measure it.

Even if the all the scores are initially low, doing this exercise with the team is the best way to check that everyone is on the same page and to measure the progress of the team over time.

On the other hand, if the team seems to have everything under control, there is always new challenges in each of these three elements. Whether because patterns need to be updated, the team has to onboard new members, or a process needs to be reviewed for a new customer channel that is coming up, for example.

The reality is that the design industry is extremely dynamic and the context can switch quickly and it's the same for the design team. Nothing will be perfect — everything can be perfected.

Whether the team is centralized or distributed, with these three elements as talking points in the agenda, it is easier for the designers to assess how they, individually, perceive where they are to each one of them, starting the conversation about what needs to be done and where to invest more.