One of the common conversations we have with the project teams we work with here at Fruto is whether a tactical or strategic approach is best. The response is a simple one: though there are times when you need to be tactical, a more strategic approach will generally be the better bet.
The best approach for one project may not be best for another; it depends what specific business problem(s) you’re trying to solve.
Often when clients approach us with a UX challenge what they have in mind is the outcome, and depending on who we’re speaking to, they might even have an actual solution in mind.
However, as our old friend the Double Diamond illustrates, going straight into working on this proposed solution would mean skipping the all-important planning, in-depth understanding of the problem and exploration of creative solutions.
This may work for some short-term fixes, but isn’t something we’d recommend for longer-term solutions for a whole host of reasons.
(And while you know your customers best, having an external agency bring fresh eyes and ask objective questions in a way that a product owner can’t, can also really help to bring a different perspective to things.)
In this post, I’m going to break down the key differences between tactical and strategic solutions, why a strategic approach is generally the best option, and some of the major pitfalls of being too tactical. For balance, I’ll also highlight some of the occasions when a more tactical approach might be more appropriate.
Deciding between tactical and strategic design approaches
When approaching any UX design project, one of the most important things to understand from the outset is whether it is strategic or tactical in nature.
We often find that a lot of project constraints are artificial and aren’t actually driven by a real business need - so it’s important that you question the constraints that you are faced with when deciding on your approach.
Some questions that you may want to ask to help you better understand whether it is an “artificial” request, or one that is based on a real, business-related reason include:
What are the business objectives (relating to this change/improvement)?
Have you got any existing research into the (potential) problems?
What problems are based on assumption and what problems are based on evidence?
What is driving the deadline?
What is the root cause of the request?
(How many times) have you tried to resolve this issue before?
Is there a scope for running some research activities to help understand the problem in more detail?
The key differences between strategic & tactical design approaches
Strategic UX design improvements almost always start with a discovery or UX review phase (that may include user research, competitor analysis, stakeholder engagement and other workshops) to identify the key UX problems and priorities to tackle first (e.g. which provides the greatest business value).
Often our clients already know what is happening (e.g. “users are dropping out” at a certain stage of the journey, “users are frustrated”, or their investors are saying that they need to improve the UX), or are getting data about the user experience in many different ways (e.g. analytics, user feedback forms, through support, anecdotal feedback, etc.) and simply don’t know where to start. In these instances, a strategic approach would be best.
In contrast, when doing tactical improvements, you’ll often be applying existing knowledge and research done in the past (we’re not going to suggest you spend money repeating work that’s already been done!).
As a quick rule of thumb, tactical enhancements are more likely to be:
Visual UI refresh (with no changes to elements, pages or navigational structure)
Creating an interim page or a new feature to fulfil a (short-term) need
The table below provides a quick reference overview between the two:
A strategic design approach will almost always be best
As I said earlier, at Fruto we’ll almost always recommend going with a strategic approach - even if the client has come to us with a solution in mind.
Sometimes this means we need to help stakeholders to step back, look at the problem with fresh eyes, and understand whether the solution they have in mind really is “necessary”.
We’ll also often help them get buy-in as to why/how/where there is greater value to be gained from a more strategic solution. This is an important discussion because it gives us and our clients the opportunity to see from multiple perspectives rather than jumping into a solution (and maybe the wrong solution).
Understanding the value of the strategic piece
There are numerous benefits to including this strategic discussion at the start of your project:
You solve the right problem by identifying/addressing the root cause of the problem
You future-proof, allowing you to avoid making the same mistake(s) again in the future
You create a good foundation or system that allows for future iterations to be more efficient
It’s (generally) cheaper in the long term because you can avoid the same/similar issues in the future and having to reinvent the wheel each time
Whereas tactical solutions are often “add-ons” (rather than code refactoring), creating new “points of delight” that help you differentiate are more beneficial, so thinking strategically about the root cause of the problem helps you think about what competitors may not have seen. Monzo and other digital banking companies disrupted the banking sector by removing the friction associated with opening a new bank account, for example.
Achieving the right balance between tactical and strategic enhancements
If you find yourself losing track of the overall outcomes, it’s generally a sign that you’re not being as effective as you might be, and that you’re choosing tactical work over strategic.
Another common sign that there is a need to take a more strategic approach is if you find yourself trying to fix the same problem over and over, or are looking to add “new” features that already exist in your product - which can be a common cause of feature creep.
The make-up of internal teams can also lead you to be more tactical than you should be. (This can often be the case when in-house UX design teams have little influence on strategic plans.) So although sometimes a tactical solution is the right solution to a problem, longer term you risk losing the big picture by doing lots of little fixes.
As such, regardless of whether the immediate solution is tactical or strategic, one thing we don’t recommend is to just go from one tactical project to another, with no real strategy aligning things.
Even where there is a genuine need for tactical improvements, we’ll often recommend a longer-term, strategic project to come up with a “better” longer-term solution. This could either take place one project after the other, or in parallel depending on the bigger picture timescale, budget, etc.
The pitfalls of being too tactical
So exactly why don’t we recommend being too tactical..?
Well, there’s a number of issues that we’ve seen arise time and again when too many tactical enhancements are made compared to being more strategic, with the most frequent being loss of market share, and user frustration.
Loss of market share
If urgency, deadlines or other constraints are what’s leading your product roadmap, it’s a dangerous place to be. As we’ll come to shortly, sometimes a tactical approach is the right solution, but longer-term you risk losing the big picture by doing lots of little fixes.
In a worst-case scenario, if you’re just doing tactical updates, you could lose market share if other solutions in the market have better user experience. This is particularly risky with legacy software that has been in the market for ten/twenty years, and has evolved organically and tactically over the years.
The best thing to do here is go back to the Double Diamond and understand how to fix the root cause. Step back into the user's mind (using ethnographic research and/or user interviews, and map out the users’ mental models.
UX improvements need to be inline with the product roadmap. And the only way to achieve this is to have good communication between product and design teams, and for UX to be highly prioritised.
User frustration
Another common issue that often arises with tactical approaches (as a result of skipping straight to the design stage) is that users end up getting frustrated with the experience.
Design teams are usually working ahead of Development teams - often by a sprint or two - depending on the size of the challenge. Developers and designers working on the same problem in the same sprint generally results in tactical solutions as there is no time for research.
This results in needing to run another project - one that starts with understanding your user - which almost always ends up being costlier in the long run.
To counter this, you can use a lean process whereby some minimal research, testing and prototypes are used to help you understand users and their problems to provide you with a blueprint of their high-level experience expectations.
When tactical trumps a more strategic solution
There are times when you’ll have a genuine need to take a more tactical approach, so here’s a quick overview of when that might be the case...
Timescales/urgency
Although we’ve said that timescales are often arbitrary or “artificial”, there are times when there is a genuine urgency driver.
For example, if the Sales team has a meeting or commercial needs to present a demo to prospective customer(s) or funders by a specific date, they might just need something simple that helps them communicate their vision of the product through a prototype or mock ups. Sometimes they already have functional software but need to refresh the UI so they look commercially ready.
Read about how we supported Albus Health communicate their product vision to potential health investors during the early stages of their product development startup.
Another common driver for a quick-fix tactical solution would be a real problem with an existing journey or page that needs simplifying to help improve conversion rates quickly/within a short timescale.
At the end of the day, both of these scenarios boil down to “We have a problem now and we need to fix it now!” - and in these cases, it’s almost always better to implement a quick-fix solution (or “band aid”) in a short space of time, than do nothing at all.
Other business constraints
As with timescales, budget constraints can also be real rather than artificially imposed. In these instances - where a fix is needed and there isn’t (currently) budget available for a more in-depth research phase - a tactical solution is a viable option.
Although a lot of the time commercial decision-making is driving (tactical) change requests, they could also be the result of technical restrictions or the development process that needs working with.
For example, we recently worked on a tactical design enhancement for the British Film Institute that had both (non-arbitrary) time and technical constraints.
There may also be other genuine business reasons why a tactical enhancement is needed - a response to a sudden, unpredictable change, such as the recent Coronavirus pandemic, for example.
However, as we’ve said before, when you look at the root cause of the request (by asking the questions outlined earlier in this post), more often than not you’ll find that the initial scope can be adjusted by removing any arbitrary or artificial constraints.
Deciding on the right approach for your next product design enhancement/update
At this point, you may still be asking yourself “Can’t I just get on with it?”. Well, yes, of course you can!
Although the vast majority of the time a strategic approach is going to be the best option, as we’ve said, there are a few occasions where a tactical solution might actually be the better bet. And even when it’s not, you can almost always replace or rectify a quick-fix with a longer-term solution when the time is right.
All things considered, you are almost always going to be better off going with a strategic approach unless you really do need a solution to a problem right now and you really don’t have the budget for a research phase. (And even then we’d recommend you revisit things once the time or budget does become available.)
Hopefully you’ll now have a clearer idea of how to decide on what approach to take for your next project. If you’re still not sure, or you’d like to discuss the best approach for your project, we’d be happy to help - be that providing you with some additional information, advice or templates, or in a more hands-on capacity.
Alternatively, if you’re looking for some inspiration, head on over to our case study pages.
