How to work with designers: - when you work with a great designer you will experience a membrane of confusion between you. They don't understand you and you don't understand them. It's kinda like being in a room with a cat - you may have great taste, care about materials, colors, shapes, object relationships, textures. You may even be close friends. It doesn't matter. They observe the world from a different, alien vantage point you can never visit or inhabit - this is a great thing! - collaboration with a designer is a process of discovering a shared language together in order to dissolve the membrane. The final output is a byproduct of this process - it's unlike working with any other function. You always have to build a shared understanding with new people or on new projects, but you rarely have to discover a new language together. This is because discovering a language is what a designer does Don't: - "here is what I want, now make it pretty." Making things pretty is 5% of what a designer does. You can do it this way, but you'd be underutilizing most of their value. If they're good you'll frustrate them and they'll quit. You will also get a much worse product than you otherwise would. - "I don't like this, move this button here." Again you can do it this way but you'd be underusing what they're good at and overusing what you're bad at. They'll quit and you'll have a worse product. - expecting a good product on the first attempt. This is not how discovering a language works; it is a process of mutual feedback and iteration and you're both satisfied with the outcome. Here's what you do: - explain the problem as you see it. What you're trying to achieve, who the users are, what they want, your constraints, etc - if they're good they'll ask you lots of leading questions. At this stage you can just let them drive and answer. If there's something you feel is important they didn't ask about, share it - they'll go back and come up with a draft. Maybe it's a sketch, maybe it's more polished, maybe it's a piece of a sketch. Depends on their process - there will be parts that don't fit your model of how the thing should feel and work. Do not tell them how to change things. Rather, explain what feels off and why. Explain what doesn't work in your mind, let them come up with a solution - again if they're good they'll ask leading questions. They'll then go back and produce another draft. Then repeat - as you go through this process you will slowly bring your vantage points closer and closer together. And the output will be the product - if they're good they'll question your assumptions. Be flexible and willing to reconsider them. You can be rigid, but the final product won't be as good - but don't be too flexible-- you need to maintain your core constraints and be open about what doesn't feel right - stop when you're 98% there. Past that paradoxically the product gets worse Expectations: - you should expect them to ask you leading questions - you should expect them to question your assumptions in ways that surprise you - you should expect fast iterations and good work. You should feel the vantage points converge - there will be backtracking, maybe multiple times. This is more common for totally new projects than for smaller changes to existing projects. Budget that in - ultimately this is more craft than art. You're both there to produce a product for a customer in a bounded amount of time. They need to understand that. If they see themselves as a hifalutin artist they aren't good. (This is true of engineers too)