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.
- 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.
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:
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:
Tobias van Schneider: Formerly of Spotify, good writer, great designer.
Marcin Treder: CEO of UX Pin.
Fabrico Teixeira: UX Designer.