Big picture provider for a design team— an intro to UX strategy

Surprisingly how often UX strategy is left underestimated and ignored among other Product design frameworks. Mostly that happens because of a lack of in-depth understanding of abstractions and patterns that approach implicates. Or perhaps that requires a systematical and meticulous work with collections of artifacts and stakeholders. That’s why very few want to deal with it. However, the links between UX strategy and business make it rather a cross-discipline framework than just UX focused. That raises a quality benchmark for artifacts quite high since we are going to consider that as a foundation for all Product design work. Making an entry threshold to UX strategy even higher. So buckle up and enjoy Introduction to UX strategy.

UX strategy in a nutshell

First of all, what is UX strategy exactly? Well, if you google UX strategy, you probably will find pictures like this.

The diagram reflects the heart of UX strategy, but the devil is in the details. And we’re going to explore where he’s hiding. I see UX strategy as a framework of artifacts and tools that gives clear answers or drives the team toward finding answers on questions like:

• Where are we now?
• Where are we going?
• How will we get there?
• How will we make sure that we’re on track?

Let’s look more in-depth on each of these questions.

Where are we now?

This is the baseline of the UX strategy, a starting point of a long journey. Collection of artifacts that provides a clear and detailed overview of the current state of UX. It contains user profiles, value proposition mappings, usability reports, user research results, user journeys, task analysis, user interviews records, information architecture, task flows, etc. No surprises here, basically standard list of UX artifacts.

Where are we going?

Much smaller, but still, a collection of artifacts that provides an outline of desired UX we want to have in the future. That is the declaration of our dream — UX vision, strategic objectives, future user journey, etc. Dream big, but remain realistic for targets with specific target dates — otherwise, you are at risk of being disappointed when you face undesirable results.

How will we get there?

What exactly should we do to achieve the desired state of UX? That will be the roadmap of all design projects aligned with business objectives and milestones. An important note is to outline links between different projects and business goals.

Are we on track?

How to ensure that we’re moving in the right direction or we’re moving at all? That’s all about metrics and ways how the team could obtain data and validate results.

Pretty obvious, right? However, the exact list of artifacts that could serve as answers for the questions above depends on how the team handles UX work. The crucial thing is that all that information should have a clear connection to business strategy and company vision. Perhaps, the way artifacts linked make it all worth to invest precious time to organize and maintain it. Once the value of having a UX strategy is clarified — burden comes to be an investment.

Big picture provider

The roadmap itself gives the design team critical insights on how projects related to each other. Yet correctly linked artifacts to business objectives and milestones offer the ability to evaluate effort and achievements from another perspective. Right, from a business. That is essential knowledge. Simply because of design solves business problems on a first-place. However, there are some exclusions, but in general, it is kind of a rule. One of the ways to evaluate the output of the design team is to track metrics linked to business objectives. It is hard to believe how much misconception is about that. But that is a different story.

How to keep the UX strategy relevant?

Below you can see how UX artifact collections are linked with business objectives using the proxy layer.

What is UX strategy proxy? It is a collection of statements created with the primary intent to glue UX strategy with the business. At this point, it doesn’t matter what form will be that artifacts. Documents on Ofice 365 or Google docs, pages on Confluence or Sharepoint. More importantly, the collection should reflect the exact structure of efforts within the organization. Those statements contain links to related projects or products, references to any relevant information form UX strategy collections, timeline, criteria of success, business constraints, prioritized list of users, and features from business and UX perspectives. Yes, occasionally, business and UX assess users and features differently. Mostly that isn’t a problem at all, but clarification and alignment never hurt. The proxy statement gives one more chance to uncover that difference and talk that through on earlier stages of the project. Perhaps it should contain any other information that the design team considers relevant and should be aware of.

Regardless of how the design team manages work, make sure that the proxy reflects the actual structure of projects arranged in your company. Diagram formulated with the assumption that the product serves as a high-level abstraction, as an umbrella for all efforts that the teams are working on, whether it is a project, feature, component, module, etc. Though, in your situation, it could be different. Accurate links and dependencies are a necessity. The core of a proxy layer is a collection of statements that have prioritization of personas, features. There could even be information on how the project stands within the product, links to the parent or related projects, references to any important artifacts that the team should take into account, etc. In this case, the team will always know the importance of the pieces they work on at the time. All that knowledge will help to make better design decisions if organized in a convenient way to comprehend. And will save precious time in the long run.

Let’s see what kind of input from a business we can get that can help us move from just collecting UX artifacts to having or starting an actual UX strategy.

Priorities

Design teams that work on enterprise complexity projects face various challenges. As well as those who work on small products that grown to sizes when not enough fingers on both hands to count different personas or user profiles. However, one thing they have in common. Very soon, it becomes clear that they need to have something that will help them narrow focus down to items that produce the most significant value. That is especially handy in situations of constant lack of resources or lack of time to fix all problems. Most of the time, both. And here we go — the choices… What to drop from a scope, what to move to the next iteration, if any. Is it possible to cut corners without causing harm to the product? A list of choices and questions could go on.

Prioritization of some UX artifacts or collection of artifacts from a business perspective is a solution. The idea itself takes roots from the 20/80 rule, where the team should focus on a small amount of work that produces a significant outcome. The same situation with personas — knowing priorities, we could make sure that users on top of rank could breathe through the workflow without substantial issues. What about the rest? For the rest of the users, the team ensures that they could complete workflow, maybe with less convenience, but absolutely harmless for the overall success of the product. We need to understand that it is impossible to do everything ideally with tight deadlines and constraints, so we should draw the line between exceptional and acceptable. Could we do everything exceptional, of course, but that depends on the resources and time we have.

So how does that work? From a list of users, we need to define one or two who utilize functionality we work on the most. Let’s call this category a power user. Maybe they spent most of their workday with the product, or their entire work depends on the outcome of the design team. So the efficiency and success of this category of users are highly anticipated by a business. For enterprise or B2B products, there is one more significant category of users — a person who pays the bills. Unlike the power user, this category of users will not spend most of the time with the product. Perhaps they could not use the product at all, but they evaluate the product’s results and decide whether to continue the contract or look for a replacement. So the design team needs to think about how to provide value to this user as well. That will be a business user. Once prominent users determined, the life of the design team become a little bit easier. Conflicts get resolved in favor of those two user groups. Design decisions often address their need first and only after cover the rest of the users. Conversation with stakeholders become more constructive and efficient since the order is established.

Objectives

Perhaps the importance of knowledge of business objectives and milestones that drive the project for designers is underestimated. Especially how different projects related to each other. Whether business targets retention of a specific category of customers, engagement of new one, expansion of market share, or decides to go after new market after all. The design should always serve business and be in the avant-garde of that effort. In case if the company doesn’t realize that… Imaging sometimes that happens too. At least from how directions and context are given, you never would guess that business and design are related to each other. It is incredible to see how things change when all dots are connected. If not, the design team could always get initiative in their hands and help to extract information that would help to restore the right order.

Timeline

This one is the simplest and yet hardest thing. The sequence of projects and relationships between them. Perhaps how one project could potentially merge with another one in the future. Knowledge of the chain of projects and their dependencies could give the design team a chance to make better and sustainable decisions in the long run. For example, if a project is part of phase and will have evolution or following iterations, the design team will have a chance to make decisions considering future use cases instead of spending time on refactoring effort in the future.

Success criteria

One of the critical insights is how success is actually measured. What specific metrics tracked by product owners, and what is that thing that could differentiate the project success from failure. It is not about finding a thin line between and practicing equilibrium for good. However, an attempt to see progress and results through the eyes of the business. Believe me, that information could surprise. Mostly because of how design sometimes stays apart. The adverse finding would be to realize there is no clear link between success and design team’s output. In this case, the design team will have to find a way to get the business’s attention and be proactive over establishing that links.

How that applied in real life

Instead of going on and on about the value of prioritization, I would like to provide a semi-practical example of how it would be great to have a UX strategy with established links to business in place. Let’s imaging that your team starts a project. The beginning. A very exciting and frankly a bit scary part. That is because of an overwhelming amount of unknown at that point. Anyhow, imagine that somebody from your team met with the main stakeholders ahead of kick-off and got information to feel up that statement for UX proxy. Of course, there will be missing parts and details early in the process. Yet some clarity already visible on the horizon. You have no idea how convenient it is to begin the discovery phase with fewer unknowns.

As you can see below, standard project diagram with few additions like UX product strategy and Design sprint blocks. Design sprint for enterprise and B2B products is a different story.

Let’s take a closer look at what exactly is happening around UX strategy. Wait a minute, where is a UX research? Usually, that associated with design activities and expected to be in the Design block. But, not in this case. I do believe that UX research is an indispensable part of every project, and it brings tremendous value. Therefore I see that as a continuous effort that starts when there is the only idea and goes through the whole design stage up to delivery. Perhaps after that as well. Simply because the design team should never stop learning about users.

See on chart below.

As you can see, the UX proxy statement becomes an essential piece during the conceptualization of the idea. But it doesn’t lose value right after kick-off. Instead, it gets better through time as the team updates it with new findings and input from product owners. UX proxy is a great reference to align with strategical objectives and to solve conflicts if any. At this point, that isn’t about making the right decision. Regardless of how bad everybody wants that. Perhaps that is why some decisions are delayed in the hope of getting it right, wasting time until it becomes too late. Timing is important — the idea is to make decisions quickly, validate, and improve if needed. That is pure gold. Wait, but what if prioritization wasn’t done quite right? No problem at all! If, by any chance, conflicting findings appear during the discovery or validation phase with the users. That becomes a topic for alignment with stakeholders. Don’t forget to validate artifacts with real customers and end-users during each step of the process. Improve prioritization statement with findings and conclusions, discuss with stakeholders again to align. That is basically it.

How to afford to work on strategy when you don’t have enough time even for a project

Of course, the title of this block is sheer over-exaggeration. If we don’t have time for a project, we simply don’t do it. On the other hand, strict constraints and restrictions boost creativity and push toward extreme prioritization. So how exactly could we work on UX strategy while struggling to allocate time for other UX activities? There is no universal answer. Perhaps, start from existing artifacts from completed projects and compose UX proxy documentation with already known information. Reach out to stakeholders to fill the gaps if needed. Greate exercise on how to structure documents and what kind of infrastructure for UX artifacts you need — where to store, how to link, what works for your team, etc. Organize UX strategy collections, so everybody could easily find the required document. The design team will gain confidence and control over maintaining collections and documentation through the constant repetition and improvement of every aspect of UX strategy and make it very own.

There is no magic in this approach. The intent of the article is to show the importance of keeping the UX strategy relevant. Arguably the best way to do so is to align with the business. UX proxy is intended to fill that gap between. And of course, that idea of the organization of UX work would not be suitable for every environment. Perhaps persistence, flexibility, and an eternal search for things that could make a designer’s life easier will make it perfect for your team. UX strategy is a live organism that changes and evolves to fit and reflect the business needs. It is vital to refer to prioritization statements during work and keep it up to date. Primarily through a feedback loop with stakeholders to remain on track, focus on the right things, and provide a reference on how decisions where made. Furthermore, a systematic review of prioritization statement documents necessary to the relevancy of information.