I’m A Developer Who Spent 3 Months Designing UX. This is What I Learned.

For the Next Three Months, You’re a Designer

That was the challenge. The project was to re-design the UX for a mature business in dire need of a face-lift. Their competition was killing them. They needed make their web app easier to use so they’d stop hemorrhaging users.

My team needed to learn as much as we could about the product: Who uses it? What do they love? What do they hate? Then, we needed to design a better version.

The Plan

Interview the client

How do they make money? What value do they provide? What are their pain points? Interview users

What do they want? What do they dislike? More interviews… Like, maybe a couple more interviews just to be sure Identify problems

What are common problems? Rate them. Identify solutions

How can we solve those important problems? Wireframe & Prototype

Visualize what those solutions are. Get your ideas into a testable format to show to users. Test, Refine, Repeat

See how people respond to your solutions, iterate changes based on their feedback.

The team included myself, two designers, a project manager, and a product owner. I was just sort of thrown in there as the cherry on top, just there to stir the pot (yay, we mixed a metaphor!). We hoped that including a unique perspective in the process would create some magic.

Let’s Make Magic

Hot damn, magic is hard to make! Through week one, I was a fish out-of-water. In retrospect, I was too focused on my “unique perspective.” What did I bring to the table? What’s my differentiator? Instead, I should have been solving actual problems.

I’m the developer on this design project, so what can I offer that the rest of the team can’t? What plot-holes are there in our user stories? What pragmatic, real-world, implementation-based problems are we creating in our design? Also, what happens when that headline wraps?

These types of questions are my natural default setting. I build stuff, so I always focus on how things get built. It feels good to identify small problems before they become big ones. The problem with that mindset was I wasn’t building anything, not yet anyways. Marginalize the “how” in the initial stages of design.

If you’re taking direction from technology, you’re doing it wrong. Forget about that new framework that all the kids are using, or how fast Node is. What are your users’ goals? What’s the easiest path for them to get what they want? What’s the competition doing? Who cares how you’re going to do it. Know what you’re aiming for before you start devising technical solutions.

Ignore What You Know

Design starts with the user. That was a huge paradigm shift for me. When I’m coding, I’m focused on API limits, breaking layouts, and feature branches.

As part of the design team, my focus had to shift completely to the user. What’s best for them? What is the optimal experience for a typical person using this product? Shelve API limits for later.

Minding the Gap

As a group, developers don’t have a great reputation for social skills. The cliche is a neck-bearded 20-something, who multi-tasks by writing Reddit comments in l33t-speak and pile-driving Doritos in a basement. Moderators be-damned!

I don’t know that developer. I’m like most of my team here at Spire Digital. I’m regularly-bearded, mild-mannered, and maybe a little on the quiet side. That description fits most of our designers (minus a few beards).

There’s not a big cultural gap between designer and developers, but there is a big knowledge gap.

James Archer describes how helpful including that knowledge gap as a part of the process can be:

…you have to accept a couple of hard facts:

— They may know something you don’t.

— They may not know something you do. You have to get really comfortable with those facts in order for this to work, because they’re going to come up on a daily basis. “Deep Design” by James Archer, Crowd Favorite

That Gap is Good

It separates two related-but-different disciplines.

The gap is not an obstacle to overcome; it’s a tool to drive your collaboration. Keeping it in mind enables you to have your voice heard, and be open to other ideas, which is totally awesome.

What I Learned

Ok, I promised you things I learned. Here are some of the most important things I learned as a developer working as a designer:

Developers Should Learn UX

We don’t have to be awesome at it, but we should give it a shot. There are countless articles suggesting that designers should learn to code. The benefits go both ways. A basic understanding of UX and some experience doing it goes a long way to better decisions throughout development.

You’ll be able to recognize patterns in the designs and write more modular, object-oriented CSS. — Stephen Caver, Happy Cog

Learning UX Makes You a Better Collaborator

An understanding of UX means you have more in common with the design team. You can speak the same language, and foster more effective collaboration.

Empathy is Important

UX is all about the user. To think like the user, you have to understand as much as you can about them. As a user, you want “x” and have “y”. Once you put yourself in your users’ shoes, you can start sorting out what’s important.

Keeping that in mind will help guide every decision you make during development.

Context is King

UX is wholistic. A better understanding of the whole picture helps you make better decisions. You’re able to put them in context (and pick which battles to fight).

Combining the greater context with empathy is the recipe for an awesome product. These are the tools to pull yourself out of the weeds during requirements meetings. These are your weapons against irksome business requirements. Let them inform how you build.