

Ask HN: How should developers talk to designers? - karamazov

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?
======
dmils4
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).

~~~
proexploit
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.

------
ericHosick
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.

------
skrish
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.

------
hkuo
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.

~~~
karamazov
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?

~~~
hkuo
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.

------
revorad
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.

