Some time ago, as I solidified my role as a UX designer, and focused most of my efforts on all the user-centered design deliverables that entailed, I still found myself with a healthy helping of UI design tasks. So I continued producing visual design and interaction on a small-scale, reactive basis, according to the needs of the development team. It turns out, this wasn’t a bad thing, as the crafting of the user experience doesn’t end with flow charts and wireframes, and inevitably unplanned feature requests will happen. I began to refer to these activities as “tactical UX design,” as a thing not apart from, but part of the overall UXD workflow.
Tactical UXD
What It Is
Tactical UXD is the day-to-day UI design that is necessary before and during product development. It presents in the form of small feature requests and unplanned enhancements, such as bug fixes or critical missed requirements. “Tactical UXD” is largely analogous to “UI design,” except for the “UX” component of the term, which implies a greater role in a larger strategic picture; it’s a discipline that doesn’t get enough love in terms of overall importance in relationship to other user experience design components. (The fact that UI design is often mistaken for UX design doesn’t address that gap; rather that’s a misunderstanding with tomes of analysis and frustration already dedicated to the topic.)
Because my job responsibilities as a UX designer at a small organization still included UI design, when I wore my “UI designer” hat, the user-centric gears still turned. When I collaborated with developers on active tickets, I was mindful to do so in a way that ensured that those new feature designs took into account the context of the user we were building them for. Even for these small features, I still wanted to understand “for whom am I designing?” and “what problem does it solve?”
Strictly speaking, someone in a UI design role may sometimes have the luxury (or misfortune, depending on the individual) of focusing only on the necessary design and interaction that is requested of her, through requirement documentation or development tickets. However, even with these smaller enhancements, context is a big benefit to designer and end-user alike, and should not be ignored.
If more upstream user research and data isn’t readily available, it’s still helpful to question the requirements in order to understand their value to the end-user. Hopefully, these requests can be understood in the broader context of a product for which more user information is available. If a full UXD process is in place, the UI designer can refer to the personas for that product and apply them to one-off requests.
Since a UI designer plays an important role in the tactical execution of a UXD strategy and should strive to integrate into it as much as possible, where should she draw the line with involvement? On the ubiquitous “UX Iceberg” visualization (which is, in turn, is just a friendlier visual metaphor for the Jesse James Garrett diagram) UI design is often equated with the “Surface” component. However, in my experience, I have met few UI designers whose responsibilities, in practice, were limited to “visual design” (VizD). There’s usually more than a little interaction design (IxD), sometimes information architecture (IA), and if she knows what’s good for her (and she can get away with it) a little user research — if she is not also the front-end developer, that is! The line is already blurred, so let’s call it something else: tactical UXD.
What It Isn’t
If tactical UX is not simply visual design done in a vacuum, it is not at all a substitute for a full user experience design process, even if for many years (and still in many companies) “UX” is still equated with “UI.” In these environments, deliberate user experience design is neglected until so late in the process that it often falls to the UI designer — or the front-end developer, as often no distinction is even made between those two roles. It’s no surprise that development teams and recruiters began to combine these responsibilities into one-and-the-same position, a contributing factor as to why so many “converted” UX designers actually cut their teeth in programming. Many picked up on the fact that being handed a directive to design from already completed requirements, with no customer context, on top of the already immense responsibility of coding, resulted in a lot of missed-marks, shelf-ware, and just generally bad UIs. (I’ve dedicated a separate article to the topic).
Strategic UXD
UX Will Happen Anyway
Strategic UXD is the user experience design process when executed in a deliberate and user-centric manner, from ideation to launch. Just as tactical UXD is somewhat analogous to UI design, “strategic user experience design” seems synonymous with “user experience design” itself — nearly a circular definition in fact — until one pauses to consider that user experience “designs” occur naturally as a by-product of any product design process, regardless of whether anyone is guiding that process. Users are sure to have some sort of experience, and chances are very high that a thoughtless or ill-fashioned experience will be a bad one. Thus, there is “user experience design,” and there is “Strategic User Experience Design.”
Tactics as Strategic Component
Strategic UXD is equivalent to deliberate UXD, and it also incorporates tactical UXD. This is because a successful strategy relies upon a successful execution. Think of it like a river flowing down a mountain: the whole body of water is named “UXD Strategy.” (I know, weird name for a river, but bear with me.) Some tributaries lie upstream, while others feed in downstream, though all of them are contributing to this river. Similarly, there may be a division of contributing roles upstream (product vision, user research) vs. downstream (interaction and visual design), but each player is conscientiously contributing to the overall UX strategy.
Product Management: Strategic UXD’s Older Supportive Brother
Another consideration is the role that product management plays in the success of a UXD strategy. This topic is gaining considerable momentum as professionals in both domains recognize the interconnectedness. Many of the upstream UXD activities are either dependent on product management processes, or are one-and-the-same. For example, product managers are well positioned to develop personas. Then of course, there is the simple fact that a positive user experience ultimately depends on whether the business goals are aligned with user needs, something only product managers and business owners can ensure at a product’s early stages (though the UX designer can and should offer input and research data).
Potential Points of Failure
1. Obviously, if there IS no UXD strategy in place, the user experience will evolve in a happenstance fashion, either by non-UX individuals upstream, or an ill-equipped UI designer/front-end developer at the end of the process.
2. There are designated individuals responsible for each phase of the UXD, but for whatever reason, they are not communicating (different departments, bureaucracy, etc.). For example, the personas and scenarios developed by a product manager never flow downstream into the UI designer’s hands.
Conclusion: Strategic UXD = Good UXD
Strategic UXD is simply conscientious, deliberate UX design, which includes curious, competent UI designers, their UX counterparts, and anyone else who is contributing to the Strategic UX stream. Failure to recognize this results in unpredictable experience design results, usually at the cost of the end-user.
Source : uxplanet.org
