For as long as I remember, there’s always been a lot of discussion about the design process in the design community: Should we do wireframes? Are detailed UI designs a waste of time? Is building a UI kit up front a good idea? Should designers code? After following the discussions for a while and battle-testing it with many different teams and settings I worked with, I can only tell one thing — my process is from now on going to be as little process as possible.

What my usual project is in 2019

In my current setup, my projects are mostly a very broad user experience projects that might also include a bunch of branding or visual identity work. Over the last couple of years my usual client was either a startup or a mid-sized company that is looking to put some structure on their design and product processes until everything gets out of hand. Obviously, the process I use is very malleable and adapted to the needs of the team I work with and it will vary for you as well, this post is just supposed to maybe give you a bunch of ideas for how you can put some structure around your work. I would wholeheartedly recommend not copying what works for me straight up because every person works differently and what works for me might not work for you.

The rough project structure

For the deliverables, assets and so on, I still roughly stick to the setup I outlined back in the 2015. The tools have changed — I rely heavily on Notion and Sync replaced Dropbox these days — but the general structure is the same. I still tend to start new projects with a discovery and research sprint that helps me figure out what is available, what is required and what are the most obvious steps forward. After the initial sprint I tend to deliver work on a weekly cadence because that way I can schedule things on Sunday evening and have a clear way into the week ahead of me. Things I consider a good baseline for every project are:

Basic style guide: I prefer having all the basics in place before designing anything, so the first step when I work is always getting at least base colors, typography choices and basic elements in place. This file is usually a Sketch or Figma library and becomes a base for everything that I do later
Versioning: When working in Sketch, I always opt for Abstract. The value it provides in discussion, developer handoff and managing deliverables is simply without compare these days. When I use Figma, I just use Figma to keep everything going.
File, Page & Artboard structure: I generally like to keep my pages and artboards well structured. In Sketch I generally do a page-per-functional-section approach, which means if you receive my Sketch file you will most likely see pages like 01 — Login, 02 — Onboarding, 03 — Main UI, 04 — Account settings, and so on. I also usually don’t remove artboards but move them to a separate page in case I want to bring it back from the dead (e.g. ZZ — Rejected). In Figma, I tend to keep Master Components on a separate page as well (e.g. XX — Components).
Handoff deliverables: I usually deploy design assets using Figma (or Zeplin/Avocode, I’m not that loyal to my tools) and supplement them with design tokens using tokens encoded with JSON or YAML in a Amazon’s Style Dictionary or Salesforce UX’s Theo format. That way, when working with developers I can refer to things using token names (e.g. card has a border-radius-s border radius and a spacing-m padding) rather than pixels. Documenting your design makes the development handoff way smoother and resulting code way more consistent.
Check-ins and 1-on-1s: After every batch of delivered work, I usually prepare a click-through prototype in Figma or Marvel and jump on a call with the team to present and discuss the decisions. These usually happen early in the week since I tend to deliver work in weekly cadence unless something goes very wrong somewhere.
Do I need to touch code? This is an important question because while I know how to do things like HTML, Sass or PostCSS pretty well, when it comes to bigger pieces of code (React, Vue, backend stuff) or newer ways of coding up UI, like styled-components or JSS, I am not as fluent in those and that means I will be slower, which I definitely try to flag during the initial meeting. I'm totally okay with learning something new on the job if the clients don't mind that they might get better quality from someone who specializes in the technology they need.

All four of the things above are usually the first things I try to establish because they mean I can deliver more better work, faster. As you probably noticed, I am pretty much impartial to tools I have to use. Sure, in personal projects I almost exclusively use Figma, Style Dictionary and Vue.js-based coding toolchain, but I don’t mind switching as long as I feel comfortable that I can deliver quality work using the client’s toolkit of choice.

What I generally do

Here are some things that are a good rule of thumb for me in 2019:

Hypothesis-driven design: Rather than having user flows coming out of nowhere, I like to work like a scientist: define a hypothesis, design an experiment to test it and take it from there. I have been heavily influenced by the scientific method in my life in general and I love to use it for work.
Goals: I am way past the “let’s design Uber for Cats!” phase and I’m very picky about the projects I take on. I generally prefer figuring out a business goal to reach and then figuring out how design can help the client reach that goal. If a client just wants design for the sake of design, we might not be a good fit.
Sketches and mockups rather than wireframes: I found wireframes made in something like Balsamiq to be confusing in user testing (having to explain the user what a wireframe is) and I generally find them a waste of time in a world where we have tools like Figma and Sketch. It’s either a paper drawn sketch (which people intuitively understand in user testing) or a full blown, high fidelity prototype.
Flow-based deliverables: The minimum deliverable for products for me is usually a Marvel or Figma prototype you can click through.
Component libraries and mini design systems: Constraining yourself to reusable components leaves you a lot of wiggle room to stretch your creativity where it matters. At some point, you might be able to get away with sketches on a napkin and short explanation which components those are — exactly what Airbnb is trying to do using AI.
Design tokens: Just like with component libraries, it’s just quicker if you define your spacings, paddings and other scales up front and reuse them everywhere. Bonus points when they’re coded up into something like Style Dictionary so developers can easily generate a stylesheet out of them.

Takeaways

Also known as: things I learned the hard way so you don’t have to.

Err on the side of overcommunicating, especially when working with remote teams.
Document your design: it not only makes everything go way faster, it also makes handoff easier.
Know what you’re great at (in my case: 10,000-ft overview down to visual design of the interface elements) and try to outsource everything else (in my case: illustrations and motion design)
Learn to fail forward — everything is a lesson, so when you fail, try to deconstruct why something failed and learn from it. You’ll be stronger the next time.
Flag things early and be honest — if you don’t feel comfortable doing something, either make sure the clients get that you’re learning as you go (which is perfectly fine in some cases) or that they need to find someone else
Don’t worry to push back — this one took me the longest to learn, but you’re supposed to be proud of the work you’ve done, so if you see something in ethics gray zone or straight up bad, make sure you say you’re not okay with it. In the end, your portfolio is a big part of who you attract, so if your portfolio is full of ethically questionable projects, for example, you’ll have a hard time attracting people who care about ethics.

That’s all, folks!

So here you are — this is how my process and learnings look in 2019. If this sounds like something you’d like to try, give it a go and let me know how it went on Twitter. If this sounds like a process of a designer you’d love to work with, don’t hesitate to hit me up as well, maybe we can figure something out.

Peace!