About: Dylan Wilbanks

Dylan Wilbanks is a web roustabout, raconteur, and curmudgeon currently practicing as a user experience designer in Seattle. He’s spent over 15 years designing, building, and perfecting online experiences, and every once in a while does a good job. Occasionally, he speaks at conferences like SXSW and Webvisions. He created one of the first Twitter accounts used in higher education, but that was an accident, and he's really sorry about it. With Kyle Weems, he co-hosts Squirrel And Moose, a podcast about designing and building the web, when they remember to talk about it. He likes nectarines. You can read his tweets at @dylanw and learn more at dylanwilbanks.com.

Posts by Dylan Wilbanks:

Stepping Out Of The Hole, or How I Learned To Save Myself


Standing in a hole looking up at the sky

You know the old adage about the person who walks into the hole over and over, before spotting it and walking around it and then avoiding it altogether? That’s been my entire work career. I’ve been trying desperately not to step into the hole.

I’ve been burned out twice now. In both cases, I realized I was burnt out not before or during the burnout, but after it was too late to pull back. And this bothered me. If I was so susceptible to burnout, how could I spot the early warning signs so I could steer clear? Why was burnout always a trailing indicator, the last thing you’d notice?

As I’ve been looking for that answer, I’ve learned to watch organizational culture. What do they reward? What do they punish? What do they insist their values are on paper… and what do they practice in their darkest hours?

This time it started innocently. I starting upping my hours at work. And then… well, I felt like I needed to save people.

I have a terrible savior mentality. I want to be the one who saves people and organizations from themselves. It’s a little narcissistic, but it’s also a certain level of martyrdom. I want to be the hero.

I’d been pushing through for nearly six weeks on the current project, and I was tired. So was everyone else. And I knew what this looked like. This was about grooming addicts. And then putting the needle in front of them and telling them the only thing meaningful was the stick, and the rush. Only this wasn’t heroin, this was work.

“Pull your weight” was management’s refrain. And we did. 10 hours a day. For five days a week. But that wasn’t enough. 50 turned to 60, turned to 70. Chasing the rush.

There’s that drug metaphor again. You’re not work-high all the time, you’re not living.

Meanwhile, I’d been watching my team’s hours.  I made the work known, tracked, and available. There was a backlog. I could work out ETAs, definitions of done. (When you’re in UX, you have to know some project management in order to survive in a corporate world.) They weren’t working weekends. I was proud of that.

(I suspect that my willingness to be measured and smart with the team made someone mad.)

And then, one day, every red flag went into the air. I was watching a presentation on organizational values. And… well, it read like a recipe for workaholism. Do things, fast. Act fast. Don’t think. Don’t close the feedback loop. Ask what the customer wants… about learning how to figure it out. All values that only need to thrash and frustration.

And I knew those values. If you’d asked me, in the heart of my two previous burnouts, what values I upheld, I’d have said similar things.

And that’s when I saw it. I saw the hole.

And I saw I had a foot halfway in it.

I pulled back.

I quit the next day.

It was one of the toughest things I’d ever had to do, quit without any job waiting for me. And it was also the easiest. At long last, I could finally save myself.

Since then I’ve been working to get my UX consultancy off the ground. I cannot say it’s been easy — there’s a lot of stress in building up a practice and a list of clients, even in a design-friendly economy like this one. And yet, I’m OK with it. I don’t have to save anyone. Instead, I’m just focused on helping people understand and solve their design problems, and then I move on to the next client.

I no longer fear stepping into the same hole again and again. I still fear. But the fear is new, different, and exciting. I’m financially poorer, but I’m also… dare I say happy? Well, at the least, not unhappy.

I would not recommend my path to everyone, much less anyone. But ask yourself if you’re acting like the savior, the martyr to your organization. Because that’s not healthy. Martyrs can only die once.

On UX in the Triage Room

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.

Telling your story

When I talk to junior designers starting out in their careers, I find they struggle with “story.” They can’t walk from problem to solution and explain how they got there. They’ll get caught up in the little details but miss the big picture. They’ll focus on their individual work while not talking about the team (or vice versa).

Why is that? My theory is that it’s the UX/UI conundrum. UIs are supposed to tell our stories. But they’re also both finality and affordance. They are the final “rendering of intent,” but we’re leaving the story to be completed by the user. So we’re used to “our design,” but we’re not used to the mutual-ness of the story conversation.

And that’s the important part: the conversation, between design and user, between product owner and designer, between organization and customer. Every design is a conversation. But how do those conversations work? As a company, are you in dialogue, or are you lecturing? As a designer, are you engaging in the conversation, or are you frustrated the user can’t finish your sentences?

If design is communication, then it’s natural that the idea of story should be central to all our design work. Story is what binds the scenario to the vision. It’s what binds the design to the code. Without a story, we can overemphasize the tiny details and underemphasize the role those details have in the product.

Here’s a story: I was trying to design a 13-period calendar picker in a product driven by quarters and months. When you get into 13-period calendars, you need to throw away everything you know about divisions of time. (You’d be surprised how ingrained 12 months and 4 quarters are in analytics design.) We needed to give our customers a way to configure a plethora of financial calendar systems that didn’t conform to the standard 4 quarter, January to December systems.

After banging at a lot of different and messy ideas and using the whole team, I was out running out of useful ideas. And then I thought of Mad Libs, and I remembered the Huffduffer signup form.

Huffduffer is an application that let you manage podcasts. Its sign up form is… well, different.

“I would like to use Huffduffer. I want my username to be ___ and I want my password to be ___.”

The signup isn’t a bunch of input boxes. It’s a conversation, constructed like Mad Libs, a childhood game where you fill in the blanks of a story (“I need a noun! A verb! A city!”) and make strange, dadaist tales. And that led me to rethink the setup form as the answer to a question rather than a series of input fields.

I imagined myself in a room with our customers, and I asked them all a question: “How would you describe your organization’s financial calendar?”

“Well, we have a 13-period calendar. Our first day is always the first Monday in January.”

“We’re different. We have a traditional 12-month calendar. But our first month is November.”

“Interesting. We don’t do quarters. We do half-years. But we track our performance weekly.”

With that, I created a mockup that looked like Huffduffer, like Mad Libs:
“Our calendar is (12-month/13-period/4-4-5/4-5-4), and we use (months/quarters/half years) to measure our ongoing performance. The first day of our fiscal year is (July 1/First Tuesday in January/our founder’s birthday).”

Ultimately, after a few iterations with the developers and product managers we fell back towards a form that wasn’t about “completing a sentence” but about “filling in the blanks.” However, the spirit remained. The form phrasing and order followed the original Mad Lib idea, and it’s still a core part of the product setup.

And that’s a story, to me. We had a problem, we worked on a solution, we got results. We had happy customers and we dealt with a very messy piece of configuration in an elegant way. Most of all, we never shyed away from the problem — “I want a system that I can configure to use our financial calendar” — and also never lost sight of the values we had in design — simple, human, understandable.

I tell that story in job interviews. It’s a perfect nugget for explaining how I design — focus on the problem, look broad for inspiration, iterate to a solution, never lose sight of your values.

As a designer, can you tell a similar story, one with a beginning, a middle, and an end? One whether you can explain the problem, lay out the objectives, explain what you did (and what the team you were part of did), and illustrate the results (good and bad)?

Every design is a story, a story you’re telling in partnership with your organization and with the user. How are you enabling every person involved to tell their story? How are you hindering them? And most of all, how are you allowing the user to tell their own stories with the tools of the story you give them?

Design is story. Communication is story. Rendering intent, in the end, is nothing more than another expression of the oral-aural tradition our ancestors first used to communicate their ideas.

Tell your story. And help your users tell theirs.