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!