How to ship good design
Why are we showing off our work in dead mockups and not as finished products?
The only thing that really matters about a designer’s work is what ends up being shipped. Not her awesome idea that got the boot halfway through development, or her pixel-perfect mockup that the engineer botched. So why are some designers only able to show off their work in a gallery of dead pixels, and not as shipped products? The blame is on a waterfall process that puts harmful barriers between design and engineering, and prevents designers from holding themselves accountable for the end result.
Throwing designs over the fence harms your work
Waterfall model is a product building practice where design and engineering are considered disparate phases. The teams only talk to each other when work is being delivered. In this world, designers make static mockups based on the direction they get from product people and craft the “perfect” design solution without regard to engineering realities. Their job is done when they hand off a big deliverable.
The waterfall model was deemed obsolete a long time ago in the software engineering community, but it is still the norm when it comes to how product, interaction and visual design interfaces with engineering.
There are a couple reasons teams work this way. First off, it’s faster. Communicating and revisions all take extra time. When engineers take the mockup and run with it, you reach the “code complete” state more quickly (even though you probably won’t feel great shipping the end result). Second, it feels safer, for managers who get to approve “final” work, and for engineers who don’t like rewrite code when designs change. Third, not all designers are comfortable communicating with engineers, because most career paths don’t help them gain experience doing so. Lastly, there are simple logistic reasons, such as engineers and designers being in separate teams, sometimes physically apart from each other. When communicating during only scheduled meetings, it’s hard to collaborate closely.
Obviously the work doesn’t end after designers hand mockups to engineers. Engineers then need to investigate how to build them out. Unless in a perfect world with infinite resources, they will make tradeoffs so the product can ship in the allocated time. If you, the designer, are not in the room anymore, you have no say over what corners are cut. Whenever there is an ambiguity in your mockups, engineers take their best shot, sometimes in ways you don’t like. Weeks later when engineers come back with what they have built, you get frustrated because what you’re seeing is so different than what you gave them.
In the worst scenario, you can’t adjust the course of the ship, and what ends up getting shipped doesn’t carry your design vision at all. It’s hard to make good design happen in the waterfall model.
This is why you hear designers say “my mockups were great but engineers botched them during implementation”.
Following up: the least you can do
There are ways to get out of this, though. The more you are involved after the handoff, the better you can communicate your vision and intentions to engineers, which helps them make better decisions . The handoff is still pretty rough though, because you made a lot of design decisions without engineering input, so they still have to mold your mockups into something they can work with.
Following up with engineers takes away from time you could use to embark on new projects, but I think improving the final result is way more important than churning more mockups.
Eliminating the big handoff: the best way out
To avoid painful surprises from your process entirely, you need to eliminate the big handoff. You do this by breaking down the big handoff into a bunch of smaller ones. Constantly talk to engineers, show them what you have, get their feedback, figure out tradeoffs, and course-correct. This way you ensure what you will be giving them is something realistic that can be built within schedule. Even better, get help from engineers to make prototypes, which are way better than static mockups when it comes to becoming confident about your design solutions.
If parts of your design seem too ambitious, cut corners in a way that stays faithful to your vision.There are no surprises when it’s time for engineers to start building, because they have been in the loop throughout the entire process. As engineering ramps up, you frequently check their progress and make sure the work is on track.
The more frequently design and engineering talk,the less stressful each checkpoint becomes. Designers and engineers start to feel like they are working with, rather than against each other. Instead of putting the blame on the other part when undesirable things happen,they take the lead and drive the project forward.
Being able to say here’s what we built together is way more fulfilling than posting a mockup that never saw the light of day to Dribbble.
If you want to take your design work to the next level, talk to engineers often, take charge, make sure you can get behind the product that’s shipped. You’ll be proud, and won’t look back.
What’s your own experience about different ways to work with engineering teams? Leave a note here or reach out on Twitter, let’s talk!
About me and Branch
I started designing for the web 15 years ago with a science fair project. Currently I’m leading the design team at Branch, where we pay as much attention to our design and engineering practices as to our product itself.
As our team grew, we ended up doing heavy upfront design work for Branch, which closed off the engineering team from our design conversations. As engineers couldn’t inform our design decisions, we couldn’t iterate as quickly as we could.
Building Potluck in a more nimble manner not only helps us get features to our users faster, but also improves team morale, where our engineers and designers feel part of the same team.
If you are a designer and working this way sounds exciting to you, get in touch.
