UX Power Tools – Medium | Jon Moore

Methodology

Who is going to help you get your product or idea built?

This is part two of a series of three articles detailing the internal groups we have to design for in order to get great products built and sold. Part two focuses on the groups that collaborate to get your design produced.

Here’s Part One (not required, but recommended):

Who are we designing for? Designing for Buy-In (Part 1 of 3)

Okay so we’ve gotten buy-in from the higher-ups and now the real panic…uh…excitement sets in. We are ready to bring in the teams who will help us get this thing built:

• Internal Design Team
• Product Management
• Development

Some of you may be designing solo and/or not have product managers, but someone will be playing these roles whether it’s you, your startup’s CEO, or your cat. So this one’s for you, too.

1. Internal Design Team

Tools: Sketch, duh.

If you’re ever working with other designers, it is so important that you keep your file clean and organized. You should be doing this anyway for your own sanity, but especially if you’re working with other designers. No one likes sifting through “Group 65” and finding your misspelled text or detached symbols. Do yourself and everyone else a favor and keep a clean kitchen. You’ll love yourself, and your team will, too. Everyone wins.

Don’t be this guy. On that note, Ale Muñoz just released an awesome plugin to help you clean nested groups like these. Thanks, Ale!

A couple things I always keep in mind while I’m designing:

1. Design Cleanliness: Pretend your design file is your home. How much cleaning would you have to do to prep your place for an Airbnb guest? 15 minutes? Or 5 hours? Is your design clean enough to hand off to another designer with little-to-no explanation? Stay organized.
2. Design Scalability: “This is just a quick-and-dirty mockup. I’ll come back later and clean it up,” said every designer, ever. Design for scalability out of the gate and you won’t have to come back and design it twice. Set up your text styles. Actually use them. Make symbols whenever you want to repeat yourself. Assume that your 3-artboard design file will someday have 180 artboards. It will. Will you be in control of them? Because of the design framework I use, I was recently able to update the brand colors, fonts, and logos across 79 screens for a client in the blink of an eye. This would have taken days had I not set up a scalable process.
3. Design Consistency: Consistency is an earned advantage when you design in a scalable way. If you’re using styles and symbols, your potential for error is so much smaller than if you were creating elements from scratch every time. You won’t get any more questions from dev as to why the padding is 16px here and 15px there.

Design Cleanliness + Design Scalability + Design Consistency = Design Team Efficiency

Einstein has E=MC² and Pythagoras has a²+b²=c², so maybe I’ll get this etched into an Egyptian pyramid or something when I’m dead and gone.

Not as much of a ring to it, though. Working on that.

I swear, I dream in Trello cards. I have a board that helps me get dressed in the morning. And one for planning breakfast. And a board for managing Tinder dates (jk, but that’d be a hilarious app).

2. Product Managers

Tools: Backlogs, Annotated Wireframes or Mockups

As much as they can really drive us crazy, product managers are the ones who make us designers look good. I can’t tell you how many times I’ve been in a review with my PM before a client presentation, only to realize that I’ve forgotten an important use case.

With product managers, you’re not designing for them so much as you’re designing with them. PMs are a direct line to your users, so keep them close. They’re the keepers of all product requirements, each of which is deeply rooted in user research.

My product managers are my best friends. Here’s how we work together:

• Backlog Building: What are we designing next month? She needs my input to help size stories, and I need her help to keep my head on straight so I’m focusing on the right things.
• Solution Design: Yep, product managers usually have a great eye for design. They’ve seen it all…just like you. Brainstorm with them! Let them hold the whiteboard markers! Solve problems with them. They’re great at what they do, and they will help you. They want to help you.
• Client Interfacing: When you’re not unveiling a grand new design, it’s usually the PM who communicates back and forth with the client. Be thorough in your designs and make sure you satisfy all requirements. Don’t make your PM look bad; it’s your fault if you miss something, not theirs. But the client doesn’t know better. Make them look good, and they’ll return the favor!

3. Development

A design without a developer is like a Christopher Nolan film without a theater:

“Look at this movie I made!” cried Nolan, hoisting a film canister high above his head amongst a crowd of people. ‘The Dark Knights of Columbus’ was written lazily in Sharpie on a dirty piece of masking tape across the round metal can.

“But can we see it?” the people asked, turning toward each other.

“Well…no…but look at the film! Isn’t it beautiful?” As he shook the can, the miles of coiled film inside thudded softly against velvet interior.

“But can’t we see the movie? With sound and movement! We want to experience it!” A small girl wept in her mother’s arms. The crowds had begun to disperse.

Noticing the commotion, a boy on a fixie rode up to the man and whispered, “Love the type, bro.” He kicked off the pavement and pedaled down the street.

“I spent years on this!” Nolan bellowed. His words echoed off the buildings in the empty city square. “Don’t you people understand art?!”

The people had left. He gently leaned the film canister against the curb, and sitting down, let his face fall into his hands.

“Nice one.” Nolan noticed a homeless man next to the fountain. He formed a heart with his curled fingers. “Welcome to Dribbble,” the man whispered.

What good is your design if no one ever uses it? Designing for practice is all well and good, but at some point, you’re gonna want to get the thing built. That’s what pays the bills, right?

Here are some things to keep in mind while you design:

• Turnaround: Be respectful to developers. If their deadline is Friday, don’t wait until Wednesday to get them the design. You’d be surprised how little a dev needs to get started on database or architecture work, so the sooner you can get them a blockframe or wireframe, the better.
• Technology Limits: You don’t have to know how to code it yourself, but it’s beneficial to have a basic understanding of the technology stack your team is using to build the product. If user data is dispersed across several tables in the database, instantaneous-app-wide-global-search probably isn’t in the cards. Design thoughtfully, and be willing to compromise with development. Given infinite time, just about every developer would love to do it exactly to spec. Unfortunately, time isn’t infinite.
• Design Consistency: Developers are great at following the design spec…even to a fault! If your spec shows 14px margins and they’re supposed to be 16px, guess how much spacing the developer will put in the code? And guess whose fault it is when it’s wrong? I’ll give you a hint: Yours. To combat these small inconsistencies, I’ll have a meeting with the dev team before implementation begins to have a high-level discussion around design philosophy. No cosmic discussions, just basic rules and standards that we, the design team, try our best to follow. With these rules, I’m teaching developers to fish, not just handing them a mackerel:

Spacing:
Everything is designed on an 8px spacing grid. Paddings and margins should always be multiples of eight: 8, 16, 24, 32, 40, 48, …

Typography:
Everything is designed using a text style from my Sketch stylesheet. These make for great CSS classes. Grey text is never hex grey — it’s always the base black with a transparency applied so it’s tinted toward the color it’s over.

Icons:
Every icon comes from the same set. “Here’s an icon font. Use this instead of pulling individual SVGs from Zeplin or InVision.” 🙌🏽

This kind of guidance will set your developers up for success, and I promise you that they’ll do a kickass job. Tools like Zeplin have helped us translate design specs to developers faster than ever, and teaching your developers to fish will ensure that extra layer of polish.

Be a selfless and charitable designer. Your influence goes up, down, far, and wide. Make others look good, and you’ll all look good together.

In my final article in this series, I’ll cover groups who manage quality control. In the meantime, subscribe below to get this in your inbox, and see what we’re up to over at UX Power Tools.

Who are we designing for? The production team (Part 2 of 3) was originally published in UX Power Tools on Medium, where people are continuing the conversation by highlighting and responding to this story.