Dear designer. Love, your next developer.

Smart questions to earn the love of your dev.

Picture this, dear designer. You’re six weeks into designing the next industry-leading product. (Insert compelling elevator pitch here). You’ve spent countless hours interviewing potential users, creating a working prototype of human-centered awesomeness, honing the visual design system, and exporting all of the assets at 1x, 2x & 3x. The project’s developer has yet to be defined, and you don’t want to burden the engineering lead with an impromptu show-and-tell meeting.

Two weeks later, the project’s developer comes on board. In my experience, the development phases of projects often kick off with a wave of enthusiastic GIF sharing, half-assed asset handoff, and a bulk export of design files into Zeplin (a tool that has changed design-to-dev workflow in a major way).

There are knucks, high*est* of fives, and gooooooo team!’s emitted at project standups. Sometimes, we even talk about getting team t-shirts (true story).

The designer throws this digital folder of their last 2 months’ worth of work over the fence to the developer, and swiftly (developer pun) moves on to another project. They’ll check in sporadically to nitpick about letter spacing and line height over the course of the next few weeks. 😅

Then, one day, the designer gets a Slack message.

Developer: Hey! 👋🏾 Where is all of this data coming from? (+ screen shot)

Designer: Hi! Um, I think the (client) company has an API somewhere.

Developer: Ok sweet, I’ll get in touch with their engineering team to see if they can give me access to it.

(1 hour passes. Or 4 days, if it’s an enterprise client. har har.)

Developer: Ok, so apparently there’s no API. We would need to make an API from scratch to serve this data. Yeah so, needless to say, this changes everything in your design.

The 4-course serving of thoughtful human-centered design you ordered is rudely downsized to a bland reduction, because the only eyes on your solution from the onset were your own. 💩

This can be avoided by asking some simple questions at the start of a project (along with showing your work to a diverse range of folks early & often!).

Define the project’s technical requirements.

To avoid the clusterf*ck described above, here are some questions you can ask from the onset. We like to ask these in client kickoff meetings, or shortly thereafter with the client’s technical teams.

What browsers and/or operating systems are we supporting?

Developers need to know this so they can determine whether they can use Flexbox (among other things) and/or define any technical restraints that come with supporting land before time browsers like IE8. Although, IE8 isn’t a supported thing anymore, thanks to the Internet gods.

Who are your product or service’s primary customers?

What key user groups use this product? Are they working mothers? Retired teachers? Bounty hunters? This question is very, very important. At a high level, the answer will impact everything from core product decisions to text sizes. More on this later.

What are the browsing habits of your core user base?

Are they choosing to use the mobile app over the desktop version of the product to complete core tasks? Are they filling their shopping cart on the go, but choosing to complete transactions on their desktop computer? This will help determine what screen sizes (tablet, desktop, mobile, or another one of the 2496326129 breakpoints in between) to focus your design and development time on. It’ll also help rally you & the developer around a shared understanding of the client’s needs & objectives.

Does the client have existing analytics?

Can I haz access to your Google Analytics, dear client? Having access to metrics will allow you and the developer to make product decisions based on real data. This eliminates subjectivity from your design decisions, and gives you shared understanding of the product.

What are the accessibility requirements?

A? AA? AAA? AODA? WCAG wha!? Accessibility isn’t just alphabet soup. It’s the law in Canada, eh. Beginning January 1 2021, all public websites and web content posted after January 1, 2012 must meet WCAG 2.0 Level AA requirements. If clients aren’t aware of this legislation, it’s your responsibility to inform them, as well as to make informed recommendations about which level they’ll need to support.

Will we be using a CMS? If yes, which one? If no, how will the client edit their content?

This helps you design with dynamic content in mind. Knowing that a client likely won’t stick to the quippy 5-word heading you designed around, how can you make the content containers flexible? What happens if the marketing team shovels a bunch of wordy content into that text input field? Does the layout break? Does the text truncate? Does the whole thing explode?

What languages are we supporting?

We’re in cold ‘ole Canada, the land of the French and English. But for global products, considerations must be made for a multitude of languages; even some that are read right to left, and that support special characters. Does your chosen font even support the characters that are required to convey your words in multiple languages?

Talk about assets (the HR-friendly kind).

Based on the nature of the project and the technical requirements outlined by the client, your project may have various asset export needs. Determine these upfront for smooth sailing down the road.

So much room for (time-consuming) activities!

For example, if your native iOS app is only offering support for iOS 9 & up, for a user base using primarily retina screens, you may not even need to export assets at 1x.

The same premise applies to responsive websites. If you want your designs to look super fly on all screens, you may only need to export assets at 2x. But if your client’s demographic reaches to the far ends of the earth, where there is limited access to high-speed Interwebz connections, you’ll likely need the ability to serve 1x assets instead, for faster load times. Use SVG’s for increased sexiness and decreased load times. This discussion will also give your developer an early head’s up that this is a core consideration while building the site or app. Your Quality Assurance (QA) friends will thank you, too, when the time comes for testing & project handoff.

✨ superstar ✨

Get cozy with your data & developer from day one.

Here are some deeper technical questions to ask in that first client or project kickoff meeting. (to avoid the scenario described at the beginning of this article!)

Do you have an API available?

If yes, ask for access to this documentation. If you’re lucky, it’ll look like this. If they don’t, keep this in your back pocket for the next meeting. You may be able to generate client interest in another scope of work.

What endpoints are available to us?

Asking this helps us determine what information we can serve to the visible UI layer (where your design magic is made). These could be things like user bio’s in a product, sizing variants on an e-commerce site, or tasting notes in a wine directory.

Do you manage this API, or is it managed by a third party?

This question determines how accessible the data will be, and how familiar the client is with the information available.

Are you open to having us build out new sections of your API, to suit the project’s needs?

Hey now, you’re an all-star. You can do bu$ine$$, too. 🤑

Notez-bien:

Have a developer in this meeting, even if it’s not the developer that will be assigned to the project. After the warm client handshakes, review the documentation together and discuss what’s available for you to work with. Start your project with the right cognitive model, so that you know what puzzle pieces are available for you to play with from the very beginning.

What grid system are we using?

This should be the first thing you define in your design file. It’s also one of the first things you should talk through with your developer, because it creates the scaffolding for every piece of content that will be lovingly placed on your website or app going forward.

Responsive web projects typically opt for 12 or 24 column grids. This is due to the prevalence of Bootstrap (which uses a 12 column grid), and the fact that 12 is one of the most divisible numbers (12, 6, 4, 3, 2, 1). Using a standard grid will make your design decisions easier, & your developer’s heart happy.

On the topic of Bootstrap, it’s also a great idea to talk through whether you want to use a pre-defined framework with global values for margin, padding, gutter and column width. Frameworks can help your project get off the ground faster, but can prove to be very inflexible once your product requires more customization down the road. Talk through the pros and cons together, as a team. I recommend high five-ing afterwards.

A few final thoughts:

First of all, thank you for reading all the way to the end. You clearly give a sh*t, and I admire that quality in you. Your developer will admire that too. You go Glen Coco!

Also, I made something for you. A parting gift, if you will. & a participant medal for giving a sh*t. Here’s your very own guide to asking smart questions in meetings.

With endless love for you, the Internet, & the things you’ll create…

-@andreacrofts