I talk a fair bit about designing for the “best experience” and supporting fluffy concepts like “flow“, but only a lucky few of us live in a world where we can actually do that. For the rest of us, there are always limitations–both human (e.g. office politics, leadership mandates, etc.) and system (e.g. time or business constraints)–that prevent us from being able to actually create those experiences.
So that means you have to do one of two things:
- Design only what you can realistically build right now
- Design the best experience and then scale that back to something that viable
I am, unapologetically, a proponent of designing the best experience and then scaling back to a more viable solution. The simplest reason for this is that I am a strategic thinker; I want to create that ultimate experience and use that as my map. How do you know where to start if you do not know where you want to end up?nSome might argue that it’s more time consuming or that it doesn’t make sense, since we won’t be able to actually build that experience into the next release. But if you only focus on your limitations, then you will be constantly reacting instead of proactively planning and executing your vision. Designing only what can build is going to box you in and eliminate any ability to innovate and scale in the future. If there’s one thing we cannot afford to be in today’s technology space, it’s myopic.
How many times have you ever looked at a product and been blown away at how poorly some pieces of it fit together? In my experience, a lot of these incongruities that I run into are the result of someone designing for a single feature/interaction without looking at the product holistically or having any notion of what they wanted the best experience to be. They were making decisions ad hoc as a reaction to pressure from other stakeholders, rather than getting buy-in on a product vision and executing on that vision.
When I talk about designing for the “best experience” in my process, there is a necessary step in the Development phase where we sit down as a team and start to make cuts based on the dev estimates. Some of the interactions or ideas that we’ve prototyped might require an unrealistic amount of work to build into the product. When this happens, we still make whatever adjustments we need to in order to agree that this is the shared vision for the product, but then we scale back to create a viable phased-release plan. Then, I’ll go create new versions of that prototype to articulate what is going to make it into Phase I.
Creating UX Debt
We are all familiar with the concept of technical debt. There are code-based items that have to be addressed at some point if you want your product to have any longevity (e.g. a database cleanup). But you can’t fit it all into the current release, so you prioritize your workload and accrue the less important/viable items as technical debt to be addressed later. In Lean UX, Jeff Gotheff and Josh Seiden introduce the notion of UX Debt and it works in much the same way. Every single thing that we had to scale back from the prototypes gets catalogued and put on the list for a future release. We are accruing those as UX Debt. Gotheff and Seiden talked about what a difference it made for their teams when they started to address this concept as UX Debt. Prior to this “re-framing”, the UX items that didn’t make it into the release often got trashed or ignored, then they had to fight to get them put back into the next release. Gaining buy-in from the beginning and treating it as UX Debt dramatically altered how their teams handled these items in the next release.
Another great thing about creating the best experience first is that the majority of the work detailing those interactions/features is already done. We couldn’t fit it into this release, but as soon we start to work on the next release, the UX Debt is one of the first things we look at.
Example
I was working on an algorithmic matching service that sought to pair job seekers with employers. The “best experience” looked at all of the candidate information and compared that to both the company culture and the specific role. However, there were business limitations that prevented us from being able to do that in Phase I. For the initial launch, we focused only on matching job seeker personalities with employer culture (which, in my opinion, is the more important of the two by far). As the interaction designer, I could have only focused on what I knew we would be releasing (job seekers to culture) in the first phase. But I designed how the experience would behave in a theoretical Phase III. This allowed us to gain agreement and buy-in on the ultimate vision for the product before attempting to describe what we wanted to build and release initially.
Once the team was all in agreement, scaling back to a viable Phase I took less than an afternoon. We knew exactly what we wanted, then we applied that to what was possible. But by doing it this way, we were able to ensure that Phase I lined up perfectly with what we knew we wanted to do in later phases. No incongruities in the product, no question about whether or not these decisions supported the longevity and scale that we needed in order to have a viable product on the market.
Had we focused only on Phase I and ignored anything that was not possible to fit in the initial release, then there would have been no need to plan for where we wanted the product to end up. As a result, there’s no way to guarantee that what we are doing now will support this unknown vision and there’s a high likelihood that the lack of clarity around a long-term vision is actually hiding multiple disparate visions within the team. This means that later releases will either be incongruous or will require a large amount of re-work to correct and align. The technology market is not nearly forgiving enough to make that blunder survivable.
Build your ultimate vision.
Gain buy-in.
Scale back to viable.
Use your vision as a roadmap going forward.