Integrate Your UX Strategy with the Project Strategy
Over the last few years, 99% of what I have read on the concept of UX strategy blatantly misses the point—at least to my mind and in my experience. Creating a UX strategy is valuable only if you align it with the strategy for the product development project of which you are a part.
In the attempts of UX professionals to stand up UX strategy as a standalone concept, I see misguided desperation that is similar to efforts to make usability an engineering practice. A successful UX strategy complements and pushes product strategy. We don’t need a standalone UX strategy for a product development project. We need to look at the product strategy and recognize where having a proper UX strategy would ensure that our product’s user experience will have a meaningful impact.
Everyone on a project has a role to play in UX strategy. We don’t need to leave it to a UX strategist or some other strategy group. The great thing about UX professionals is that we are usually very good at identifying patterns; looking at an information architecture or design and seeing beyond the face value of the thing. Great UX people are able to look at a design or a user interface or even a project schedule and say, “Hey, we really need to do X to make this work.”
A really good UX strategy is not just about planning UX activities. It’s about identifying what the customer needs to get out of an experience, then circling back to look at what we are doing on a project—beyond the next sprint or the next phase. For example, saying, “We need data to better understand this now, if we are to be successful at delivering this type of experience,” really ties a strategic UX activity—user research—into the success criteria for a product strategy. This leads me to my next point…
Don’t Forget User Research
One of the issues with transformative software implementation is that, by nature, it moves very, very quickly. So fast that, sometimes, the traditional deliverables and activities of strategic user experience can get left by the wayside. This is very evident on projects that an enterprise aims at an internal audience.
User research often gets short shrift on internal software development projects because of the mistaken belief that we already have enough data on our users. They are our employees after all, so we already know a ton of information about our users. Plus, we assume that these people’s managers can tell us even more about them—so why do user research?
We all know that skipping user research is a mistake. But I have found that a lot of us have trouble articulating why this is a mistake, so are unable to convince project stakeholders to spend the time on research activities. However, existing employee data usually neglects to tell us two very important things: the why and the how. Existing user data may do a very good job of telling us what someone does, but it does not tell us
- why users do things in a certain way
- whether there is another way that might work just as well or better, but has not been explored
- how to design a new user experience that would better meet users’ needs
User research, when done well, tells us all of these things. It gives design insights that user data usually cannot. So plan to do user research, fight to include it on your project, and when you get the opportunity to do it, don’t mess it up.
