3 Months a Designer

Spire Digital
Spire Digital
Apr 11, 2016

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

  1. Interview the client
    How do they make money? What value do they provide? What are their pain points?
  2. Interview users
    What do they want? What do they dislike?
  3. More interviews…
  4. Like, maybe a couple more interviews just to be sure
  5. Identify problems
    What are common problems? Rate them.
  6. Identify solutions
    How can we solve those important problems?
  7. Wireframe & Prototype
    Visualize what those solutions are. Get your ideas into a testable format to show to users.
  8. 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.

What Can You Do?

But Glen,” you say, “what CAN I DO as an individual to start learning UX as a developer?” Man, I’m glad you asked, reader. If you’re part of a larger company, your journey into UX doesn’t have to start with fighting a bureaucracy to win the opportunity to do so.

You have the opportunity right now. Here are some things you can do today to start expanding your horizons:


There’s a ton of great newsletters out there they give you a primer on UX and expose you to the latest trends. Subscribing to a couple newsletters or RSS feeds is a great way to start learning the language of UX as a developer.

UX articles cover familiar subjects in a new context. You’re focused on the user, and not the implementation.

I’m subscribed to these newsletters:

Friday Dev / Design Roundup: Weekly newsletter of hand-picked articles form HackerNews and DesignerNews.

Austin Leon: Thoughts, art and links from Austin-based writer/artist Austin Kleon.

Sidebar.io: The five best design links, every day.

Draft: Nick Disabato is a force to be reckoned with. His weekly essays are inspiring and though-provoking.

Paul Jarvis: Freelancer of 20 years that “builds things for people who build things.” Great writer.

Follow Smart UX Folks on Medium

I get a lot of my UX learning and inspiration from Medium. Here’s a few smart people that I follow:

Robin Raszka: Designer in NYV, editor of Design Pttrns.

Tobias van Schneider: Formerly of Spotify, good writer, great designer.

Marcin Treder: CEO of UX Pin.

Fabrico Teixeira: UX Designer.

We use cookies to personalize content and ads, to provide social media features and to analyze our traffic. We also share information about your use of our site with our social media, advertising and analytics partners. Read our cookie policy here

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.