Image for post
Image for post

I’ve put together some thoughts on how to run discovery meetings for a product team. If you’re short on time, check out the short and simple version below. For a more detailed look at discovery meetings, read on!

The Short and Simple Version

  1. Ask questions until you completely understand the problem, process, or idea.

End by aligning the group to a common goal.

“So the challenge now is how do we [achieve this common goal]”

Easy right?

The Detailed Version

The items in this list are roughly in the order I would do them in. However, don’t structure the meeting like a checklist. It’s better for the conversation to flow naturally from one topic to another. …

Hello design-jerks! Or reformed design-jerks. Or I suppose you could just be normal designers. On this, the third and final installment of how to be nice to your developer, I’m going to talk about something much bigger and less concrete than before, and it starts with listening.

Specifically, listen to what your developer has to say. Your next project is the perfect opportunity to begin building a working relationship with your developer. You can learn a lot by bringing them into UX discussions early and often, especially when features are on the table.

Image for post
Image for post

If you can’t get developers into those discussions, pay attention during your dev handoff meetings. If they seem apprehensive about a feature you designed, ask them to explain why it worries them. Note their answer and remember it for the next time you run into a similar challenge. You may find that a simple change to how the feature works will vastly decrease the development effort without negatively affecting the user experience. Designer or developer, we can all agree this is much better than having the feature shipped half implemented or cut out completely because it was too complex to be finished in time. When both you and your developer feel comfortable asking questions and giving feedback, your team will make better products, guaranteed. …

Let’s face it, documentation is not fun, but it’s something that every designer should be taught in school. As a lead designer, I have to be able to communicate with others to execute my team’s designs.

Moby tends to work on larger, more complex websites and mobile applications. On these projects, a lot of decisions about the functionality happens during the UX and design process which the developer may or may not be a part of. To add to the confusion, the assumptions of how the product should work are not always obvious. As the project progresses I become the single core repository of these assumptions. …

At its heart, working as a designer is a social job. I work with clients, users, UX specialists, developers and a collection of other designers. As a lead designer, I like to keep an eye out for how to make our processes more efficient. Sometimes it can be difficult to realize how a particular design workflow affects development. However, once I identify the problem I get excited to solve it.

I came up with this change when I was searching through an icon pack that had each icon saved out as a separate file. I got so annoyed paging through each individual icon that I created a master file for reference. …


Kaitlin Powell

Director of Design at Snap! Raise, a fundraising platform for high school groups and teams.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store