Want your design team to go faster?
Don’t we all.
But it’s not all about speed. It’s about doing the right work at the right time for the right reasons. What we innately sense on a project is its inertia, but the problems are far more obtuse.
Design teams can do a great deal to help projects move efficiently through the design process. They can also hinder it just as easily. In our experience with dozens of teams (and our own past if we’re being honest) we’ve found some core practices that are counter-effective but seem so right at the time. If you can work your way through these time-sucks, you’ll see your projects thrive in a way they haven’t.
Here’s the biggest wastes of time we’ve found…
1. Pixel-perfect flats all the time
Pixel perfect flats are a waste of time. There. I said it. At worst, they are a fluffy exploration to make a designer and stakeholder feel better. At best, they are a facsimile of something that rarely, if ever, ends up perfectly representing the finished product.
I’m not saying to never work at full fidelity—that should happen. But when building a product, the deep furrowed-brow squinting-at-the-page finesse should be applied to the finished work: code.
Instead, I’ve found myself—and the teams I’ve helped—using these designs as a sort of one-way-contract with engineers. Our version of the Ten Commandments chiseled into stone, they define the existence of the layout without flexibility.
Instead, take that time and turn it into an extra round of QA on the real deal, or better yet, a sit-down with your dev to nit-pick the details. Or even better yet, move on to the next problem knowing that they’re going to implement your work the best they can*, and find you if they can’t**.
2. Working without product specs
There is no right answer unless you take the time to define it.
Nowadays, we require that every project, large or small, has at least a basic spec to work from. What are our goals? The audience’s goals? Who are they? What technical considerations are there?
It shouldn’t be up to the design process to create these answers. That burden causes bloated process, and churn around exploration phases. By defining rails up front, design can flourish in the intended direction, taking a far more strategic and tactical approach to any exploration along the way.
If nothing else, the specs provide a record of rationale as you discuss your work with stakeholders or other designers. They’re the key to unlocking constructive criticism and timely feedback.
3. Not talking to engineers
I’m in a room at a large fin-tech company, talking about a user flow we are building. Product is there. Design is there. The conversation is heated. Multiple times, the engineering cost of the flow is called into question. “This is going to be a hard push.” There is hand wringing. Heated deadline conversations.
I ask, simply, “Has anyone asked the engineers what this will really take?” and point to the dozen engineers on the other side of our conference room’s glass wall. “No.”
“Cool, let’s find out.”
It turns out the solution was simple and engineering could make our dreams come true with a fraction of the effort previously anticipated. Deadlines were hit, and everyone was happy.
But what really stuck with me was how many times over that hour-long meeting the designers and product managers assumed the cost without just asking their teammates. If you want to move fast, just ask. What you learn will keep you from wasting time on phantom problems (or not thinking of the real ones until it’s too late).
4. Working at the wrong fidelity
A couple months ago we started approaching our calls with clients differently. We started asking “What conversation will move the project along best?” and then, “What deliverable, at what fidelity, will help that conversation most?”
The change in how we work has been dramatic—meetings are better and more productive, and work is getting done at a much faster pace. Looking back, I feel guilty for how much time I spent creating things at the wrong fidelity for the wrong conversations. It’s easy to do. Sometimes it’s just more fun to work at full fidelity or explore outside the defined problem-space, all the colors and states and icons beckoning like a siren.
The harder truth is that sometimes it just gets in the way of a productive conversation. Knowing the right fidelity level to make the right decisions can help your projects move along at a much faster pace, without all the needless (but fun) trappings.
5. Designing full pages
But then…what do you design? Answer: whatever you need, and nothing extra.
If pages are made up of individual components, then it should be simple to design on a component level and let the composite page layouts exist where they really live: your code.
This style of designing more closely mimics the way that engineers work, and allows you to create and implement layouts with greater consistency. Eliminating snowflake-cases in your designs will speed up your engineers and help them build better, faster, unified systems. No CSS overrides! Yay!
With everyone designing and building just what’s necessary, all that saved time can be used to work on that next feature, flow, tweaking animations, or—dare we say—vacation time?
*If you don’t have faith in your engineers ability to implement designs that’s a whole other topic for a different time
**For more on that, read Love The One You’re With