You are a designer. You drew a layout and want to bring it to life.

The instruction will help you get a good result.

1. Realize your helplessness. You yourself will not implement the layout. Even if you know how to program, any serious product is ten times more complex than you might imagine. Nobody will let you touch the production code with your design hands, so working with a developer is your only way to realize your plan. Accept this.

2. Prepare a quality problem. The developer’s job is to implement what you come up with, not come up with a solution for you. Think, draw and describe everything well: main scenario, boundary conditions, exceptional situations. Think over the data structure, algorithms, triggers.

When preparing a task, you cannot do without the help of a developer. Discuss the problem with him in advance, ask about the pitfalls, implementation options, the most difficult points in the invented design.

Do not be afraid to overdo it with the detail of the task. Even if you fully program the prototype of your layout, there is still a lot of work left for the developer to implement it into the real product.

3. Help say no. If, under your pressure, a developer takes on a low-quality problem, and then cannot solve it, you will suffer first of all. It is better to learn about the problem onshore than on the high seas. Help the developer abandon a bad task:

What’s missing in the layout?
What problems can there be?
What have I left out?

4. Make sure there is a deadline and nails in. A problem without a deadline cannot be solved by definition. One deadline is not enough, you need intermediate checkpoints – “nails”.

If a developer doesn’t know the “make” principle, gently nudge him with questions:

When will you do it?
What will happen by this date?
When will we see the interim results?
How long does it take to test? When does it need to start to meet the deadline?

If the developer understands the “make” principle, ask to set a deadline and hammer in the nails directly: “Please call the deadline and hammer the nails.”

5. Turn the pedals. Don’t act like a bad customer who just turns up his nose and pours in the edits. Proactively help the developer solve the problem – draw additional scenarios, invent behavior, suggest solutions, invent simplifications. Your job is to help the developer do it.

6. Do not meddle in your own business. Do not doubt the professionalism of the developer. Don’t mess with the code. If the developer fails to implement, ask leading questions so that the developer can save face:

How did you try to solve the problem?
Why doesn’t this work?
But I’ve heard about this method …

7. Accept the result. Take some time to check your work. Don’t expect the developer to do it well. He sees only part of the system and cannot be the ultimate controller.

Total

Don’t be an asshole. Work. Help the developer make. Grow developers to make communication easier and better results.

Source: fff.works