My design process
Yesterday I shared some ideas about my process.
I was recently asked what I do as a designer. This on the heels of a friend saying that, despite knowing me for years, they don't really know what I do.
When I meet someone new, and we exchange pleasantries and try to figure out what the other does for work (a very American thing perhaps), I used to say that I was a UX designer, or product designer. The glazed over eyes caused me to pivot a bit and say software designer. But even that wasn’t enough. Now I usually just say that I’m an app designer.
For someone working in tech none of those are strictly correct. But app designer is the closest thing I’ve found to explaining to a non-tech person what I do as a product designer.
Designing software has shifted a lot in the time since I started. My process has grown out of my journey and alongside the shifts in the industry. Because I’ve worked at startups of all types I’ll share the most typical type of day I might have across the places I’ve worked.
Checking in
I start my morning checking up on things that I may have missed from the day before, seeing if there’s any updates from engineers or product managers that are critical before diving into work.
Because I design ahead of the engineers, I’m usually more interested in updates to designs that have shipped, or quick design changes we need to tweak based on bugs we’ve found or feedback from customers and stakeholders. Most of this is done on Slack through the various channels in the team.
Daily standup
This leads into the daily standup. It’s usually a meeting over Zoom, but is sometimes asynchronous. The idea of a daily standup originates from Scrum, where you’d stand around a room in a circle and share quick status updates, focused on blockers, what you’re doing, and what you did. It’s intended to be short. In practice most teams morph this into a working session to discuss issues that they’re wrestling through.
That used to bother me, a lot. Nowadays I don’t mind. If there’s a critical issue or two that we need to discuss, it’s a good time to dive in.
Granted, this works well in a team of 4-5 people. Once you get bigger than that a standup should be little more than a quick update.
For my part I’ll share the work I did the previous day. Sometimes I’ve already updated the team at the end of the work day via a Loom video. But sometimes I’ll wait till the morning to get feedback live. It all depends on how critical it is to ship, and whether async or live feedback will be more useful.
This part usually turns into a live discussion. I screenshare and walk through features I worked on, get feedback, redline things, and sometimes design live with the team’s input. My goal is to get enough info to keep pushing on an idea or start a new idea.
Deep work
Leaving standup I then dive into the one or two most important things on my task list. If I have a product manager I’m working with (and I usually do) we’ll have agreed on what these are. This list is kept in my Apple Notes doc, and is re-written as often as needed based on tasks that we agree on as a team. I used to try and keep it in a project management tool, but it never worked for my brain.
I’ll share this doc with the product manager (always re-writing it myself) and work with them to re-prioritize as often as needed.
I’m a huge fan of Deep Work, and for the most part try to stick to it.
Morning is reserved for focusing on problems that require a fully working brain. This is a time I’m usually filing on all cylindars, and I try to keep it distraction free from calls or meetings.
Let’s take a typical feature.
Most features are based around a metric we’re trying to move. We either want to get users in the door (acquisition), convert them to becoming a paid member in some form (monetization or conversion), or look at where we’re losing people the most and fix those leaks (retention).
We'll work on a feature targeted to one of those numbers we’re trying to move. Sometimes we get lucky and move two numbers at once. More often, especially at a consumer focused startup, one number may move up while another moves down. Many times all numbers go down, and we have to tweak and investigate to see why.
At this stage of a feature I don’t generally start working in a design tool like Figma. Instead I’m actively thinking and sketching. Generally I will put the problem we’re trying to solve up on my laptop screen. It’s usually a statement that me or the product manager have written. Then I’ll find other apps that have solved similar problems in different verticals. I used to scour the internet and app stores for hours, but now I mostly pull inspiration from Mobbin.
While looking at the dozen or so screenshots and the problem statement, I’ll open my iPad mini and start sketching flows in Freeform. Sometimes I’ll just breadboard. Other times I’ll sketch out the whole user flow of a feature. If I mostly have the flow figured out I’ll sketch individual elements to play with how they all fit together.
Once I’m satisfied that I’ve gotten my brain out on paper, I generally take a break and pause on the task. I then share (either the next morning in standup or in a Loom video on Slack) where I’ve landed. I always caveat with the team that I’m keeping it as a sketch so that they can help poke holes in my logic. It’s not intended to be perfect.
Afternoon
After I grab lunch I will check-in on things with the team. Depending on where things land I may attend another meeting, or I’ll dive into followup on something I worked on previously. This is also often the time where I work in Figma, building out the pieces of something in higher detail.
----
That’s generally what a day looks like, with obvious massive caveats that no day is truly typical.
Once I get feedback from the team on the sketch I’ll either work with an engineer to take it straight into code as a feature, or take it to higher fidelity so we can really see how the feature works. Some things are best figured out in code quickly, while others need to be seen visually first.
I’ve also left out the parts where we interview users, talk to other stakeholders, and run split tests on ideas. Also, I generally revise ideas multiple times before shipping.
The biggest thing to learn is when to ship. Too much time iterating early can lead to problems. But shipping too quick can lead to iterating for weeks on end later.
Once a feature feels watertight I’ll take it to high fidelity in Figma (assuming we didn’t ship the sketch or wireframe straight to code). If the feature is complex enough I’ll build out a clickable prototype. For mobile apps the best way to test a feature is to move it to your phone via Figma and tap through the prototype (second of course to tapping through live code in a test app).
When the feature is at this stage we’ll either test it with users or test it ourselves, then I’ll work with the developer to get the idea coded.
At this stage I’m not writing code (although I used to). Instead the developer takes the idea and shares back early iterations. At this stage I worry less about the exact pixel details and more if the idea is working in code. We often change parts of the design here, based on discussions I’ll have with the team, and the idea will continue to morph as it gets to code completion.
We’ll then take the coded feature, try it ourselves some more, then show it to users, or run it as a split test.
Over the next week or two we’ll track the split test to see how the feature is doing against the baseline comparison. If it does well we celebrate. Most often the results are mixed and we have to tweak things till we either shut down the experiment or pass it as a success.
---
The biggest thing I’ve learned through all this is to be flexible. The process has to adjust, the ideas have to shift. We also have to keep looking back to the core metrics we’re trying to move. Features shouldn’t be precious. They exist to solve a problem and should be discarded or improved quickly.
I love this work. It’s always a challenge, I’m always surprised by what I design, and while my gut hunches on things are getting better, users always challenge me to improve.