Ask HN: How should developers talk to designers? | Hacker News Reader

Ask HN: How should developers talk to designers?

9 pointskaramazov8 comments

We've all seen clueless MBA's looking for developers to "just code my idea", and there's a lot of advice out there to help business people talk to technical people. As a technical person looking for a designer, how do I manage the problem?

View on HN

It sounds simple, but telling them you trust them to make a better product than your mockup helps a lot.

Give them creative freedom to solve your idea in their own way. You may understand the technical specifics and big picture of what you're trying to do, but acknowledging that they know their craft better than you do (that's why you're talking to them) and that you want them to design it out in the way they think is best - just saying that will go a long way. Giving them a mockup helps - but let them know you're ok with their interpretation veering from that.

Obviously if the person you're talking to is an awful designer, nothing will fix it; but if you have a good one - the ideas that will flow will make your product awesome (even if they aren't implemented in the end).

I can't agree enough. You're looking for a designer because you don't have the skills so the more you let them make informed design decisions, the better result you'll get. This doesn't mean let them do anything and use it even if you hate it but try to refrain from making design suggestions and instead ask for reasoning behind decisions you're not thrilled with. To find a good designer, try enlisting a designer to help.

You could try mocking out your idea using something like http://www.balsamiq.com/ or http://www.axure.com/ (I'm not trying to push any specific mocking software).

This allows you to describe how you want the system to behave without getting into the nitty gritty on how to make it look good: that is why these mocking systems look as pencil like as possible. Iterate with a designer a few times with these mockups.

I would also recommend showing the mockups to your stakeholders and/or customers and ask them what they think. Do they like the flow, etc.

Another advantage using mockups is that once you have your mockups finalized, you can start implementing the behavior of each mockup while the designer designs.

For this phase, I would recommend using Feature/Behavior Driven Development to drive the development of your code based on the mockups. Use Test Driven Development to fill out the units of your program.

Just a suggestion and I hope this helps.

Try to communicate visually within a framework.

+1 for the idea by @ericHosick. We use balsamiq to wireframe the details. We take inputs from team to review the details of fields & overall menu placements etc.,

And then we let our designer take it up from there with freedom to come up with various options on his own within the framework. It really helps the designer to work with freedom knowing that the overall content is "almost" set and he is free to implement thoughts based on usability and design aspects.

I think the first part of "looking for a designer" is the hardest and most important part. As with any profession, not all designers are created equal. I would look for a designer who emphasizes user experience, not just someone who makes pretty pictures. I would make that the first topic in any discussion with a potential designer. If they have no experience or regards to UX, then keep looking.

Once you meet some designers who do have experience with UI, how do you evaluate them? It's not as hard as evaluating a programmer with no knowledge of coding - design is much less of a black box, and it's at least possible to tell when a design is bad - but how do you tell a good designer from a mediocre one, and a great designer from a good one?

I don't think there are any hard and fast rules, but I think a simple question that will give you an immediate sense on whether a designer knows their sh*t (pardon my French) is to ask them what their design process is. If there's any hesitation, or if there's a pause and you can tell they're trying to make something up as they go along, they don't have one. Move on. But just pay attention to what they're saying and you'll likely be able to tell how experienced they are and how confident they are of their skills.

Edited to add: this is where you'll find out if UX is part of their process. If they begin with things like mood boards, font selections, color palettes, look & feel, no, no and no. It needs to begin with some form of audience/customer, business goals, content strategy, user flows, functionality. Those other things come after, not first.

Assuming you are referring to graphic design and not product design, this is how I work with a graphic designer friend on all my apps. After many iterations, we've found the method that seems to work best between us is that I code up a functional prototype and then we have frequent intense on-the-spot design sessions with a lot of back and forth. This was initially quite unnatural for my friend, who preferred doing elaborate design explorations on his own, but we now agree this new method works best.

The reason I like to work like this is because until I work out how the software use actually flows, it's pointless to make it look shiny. And working out that flow itself is a rapid iterative process, which changes the UI many times over. I hate to make my friend design stuff which I will then throw away the next day, although some of that is inevitable.

Over time as the design gets clearer, we work out a visual grammar of sorts, which I can then just draw from as I build more features.

See http://giniji.com for an example of a work-in-progress.

Reply on news.ycombinator.com