What’s the point of a UI when the back-end isn’t performant enough to serve correct data in a timely fashion?
Wait, I’m getting ahead of myself. Let me back up.
One time I walked into a big triage meeting for our very late, very broken latest product release. We needed to look over 400+ bugs and determine what really must get fixed so that we could release in four weeks.
I came in with a list of ten UX “showstopper” bugs. These were things that the UX team considered absolutely vital to shipping a quality product from our user-centered view. We probably had 50 under consideration, and it was hard to cut down to just ten. (The release was very broken.)
I walked out hours later with just two of the bugs making the cut. They weren’t the two I was expecting. I was hoping to get eight — maybe all 10! — under the cut line. But, despite a bunch of persuasive arguments, I couldn’t even get my top 5 on the “must fix” list.
The problem was technical debt.
The great technical debt conundrum is usually caused by a team moving so fast they write poor code that requires a lot of work to maintain. In that world, UI/UX fixes get tossed in the “debt” pile with “everything not currently pissing a customer off.” After all, if the customer is complaining they can’t complete a task because of an old bug the team keeps punting off the to-do list, that comes first. The organization has finite time and finite resources to work with.
Technical debt is a terrible thing to incur — but it’s also unavoidable. Every decision you make, whether in the code base or the design or in the feature set, means you are laying aside other potential routes you could have taken. Every piece of work executed means you are not executing something else. Because time and resources are always finite, building any product means features will get left behind and optimization will get deferred.
The decision to defer something now means you’re going to have to do far more later to complete it. At one company I had a developer tell me:
“Six years ago I was asked how long it’d take for me to internationalize our code base. I said two weeks. But we didn’t have time. Now, it would take months of work — with multiple developers.”
An organization who mortgages its future through tech debt will find its work backlogs more and more centered around servicing that debt and less around new features.
Now, technical debt can be lessened if you optimize for the right things. Developers always think about this, and they often argue about it as well. Do accessibility now or later? Do localization now or later? Where should we put the attention on making code robust, and where can we get away with an 80% effort?
And into this mess comes UX, asking for changes. UX wants to make things right for the users. Unfortunately for the designers and strategists of the greater UX community, “the right things” can mean “all the things.” We often fail to articulate a holistic view of user experience, falling into small arguments about pixels, or taxonomy, or content. Meanwhile, the back-end isn’t producing trustworthy results, and it’s not returning results fast enough for users. By comparison, our complaints about pixels and taxonomy look small.
Worse still, despite our intentions to be “more than just UI,” we end up arguing for the UI in these triage meetings because no one else is. And that just sinks us deeper into the morass of UX and UI being interchangable.
We have to think holistically about UX. If we start from the user’s point of view and not from ours, we can start asking what really is important to the customer. Instead of arguing pixels, we argue for what the user needs, what the user desires, what the user demands. We become the authority for our users’ real sense of priority. Yes, performance is important… but how performant? Is the dev team over-thinking performance when the user just wants an accurate result in their time? Maybe the users aren’t telling us how slow the process of using the product is on a daily basis, and it has nothing to do with the performance and everything to do with the workflow.
Looking back, I see I made a crucial mistake when making that list of 10 things that needed to be fixed. I was arguing them from the UX view of the world, not from the user’s view of the world. In fact, on a few of the issues, I’m not sure users gave a damn. Our team cared. Our customers didn’t.
If we want UX to be more than “just UI,” we have to take a user-centric view of everything. That means laying aside our pet issues, getting a clear priority of what our customers need, and arguing for that priority over the priorities of everyone else in the battle for resources.
Instead of talking about design debt versus tech debt, we should talk about user debt — the promises we’ve made to our users, our customers, that we need to fulfill in good time to keep them happy and engaged. Focusing on user debt means we start with what people need to work right, not what the political forces in the triage room want.
At the end of the day, the people who use the things we design do like lovely things, but lovely things can only cover up so many unfulfilled promises before users start assuming they’re all lies.
On fire: Will not leave me alone, something blew up, highest priority. This is what I’m working on unless something else is also on fire, in which case I’m working on two fires.
Active: Regular meetings, regular activity, moving along as scheduled (or a little faster or a little slower). I can usually handle 2-3 of these at a time unless there’s one on fire.
Waiting on somebody: Can’t move forward without something major from (usually) the client or business or (sometimes) the tech/IT group. It’s no longer a day-to-day activity.
Back burner: Somebody moved the project out of the top priority queue. (Generally I don’t have the authority to back-burner, unless it’s a personal project)
Fridge: Somebody moved this far enough off the back burner that we’re not pulling it forward anytime soon. But we’re going to work on it some day. Honest.
Freezer: Someone moved this so far off the back burner that its own mother couldn’t find it with a GPS system. But still, honest, we’re going to get to it. Maybe Day 3.
Sleeping: Descoped, or unbudgeted, or otherwise not happening anytime soon, but the people in charge swear it’ll happen some day. Really.
Dead: Been sleeping so long that by now it has to have starved to death. You don’t ever expect to see it again, except in conversations that start with “Hey, do you remember when we talked about that project where you had the cool alert implementation? Can I steal the alert implementation from your wireframes?”
Zombie project: Hey, you remember that project we asked you about last year? The one you worked hard on and then it was descoped? Well, it’s back, and with a whole new set of sponsors and requirements.