Create a happy ending with 😇 & 😈 developers as a designer
Hands-on experiences on how to build and strengthen our bond with developers as designers to create better products together.
I’ve been working directly with more than 40+ developers and have had delightful and painful experiences. After years of frontline battle, I sincerely feel that developers are designers’ most essential comrades instead of the enemy. And my most precious knowledge, insights, and growth are from the help of developers.
We don’t talk much about product realization in school. All the blue-sky projects we designed in school are great practices, but the real world is different. It’s meaningless if a product design will never be shipped. It takes me a while to understand that designers and developers work with different methodologies, focus, and goals. We can still make good-looking interfaces, prototypes, illustrations, or animation without developers, but not a great product, never.
Development resources are previous. As a designer, my first working principle is not to block the development progress. Second, to ensure the great outcome of our product design, it deserves my best effort to design the workflow and relationship with the developers. That’s way more important than the design deliverables alone.
I want to share some experiences and tips to help designers to build and strengthen relations with developers, plus examples dealing with edge case scenarios with 😈devs at the end of the related sections.
Initiate the relationship
- Speak with their language — learn more about their terminologies, search online, or ask questions if they said something we don’t understand (highly recommend to learn terminologies on Sideway dictionary)
- Have some common sense of development. Ridiculous assumptions will hurt the trust (I suggest installing this Chrome plugin Wappalyzer to learn what technologies the site we are browsing in daily life)
- Build a channel (can be a Slack channel/chat group) to actively share exciting news and stories related to design & development to help everyone understand the importance of design (the Hawaii Missile Alert is a great example)
- When I cared and stayed curious, I learned tremendously. Similar to a simple “Oh, nice dress!” notice and share the excitement with developers when they get new monitors/ergonomic keyboard, mouse, t-shirt, stickers; ask and know more about what makes them happy and exciting; think about them like hidden treasures. I even created a 2min section in stand-up called “question of the day” to ask terminologies, flows, tools that they talked about during stand-up that I don’t understand.
Get developers involved in the early-stage
- Let them know they are significant for the success of the product
- Invite them to design studios, user interviews, and design/research discussion and presentations (they can be optional, but make sure they got the research insights and outcome)
- Provide visual guidance to help discuss with devs; iterate to make it simple, straightforward, and convincing (use the universal visual vocabulary
for describing information architecture and interaction design)
“A picture is worth a thousand words.”
- If devs don’t pay attention during early-stage meetings and discussions, ask them questions or their concerns
- Consult them for information architecture, potential risk, tech-limits, and performance-related questions
Example in the early stage when exploring solutions together:
(😇 & 😈 devs; 😉 designer tips)
😇 Get involved as early as possible and try his/her best to understand the flow/Interaction and UI to avoid potential problems
😈 Not attend meetings or stare at a cell phone/laptop during the entire meeting, never pay attention or say a word before the final coding stage
😉 Give them the reason why they will be very helpful if they join. If they stare at the phone, ask “Do you have an emergency? We can reschedule the meeting if you can’t join us this time.” Make sure to ask them questions once in a while to push them to focus and appreciate their effort when they give an answer.
Set the workflow and regulations together
- Be professional and trustworthy
- Always ask follow-up questions when they say “no” to understand their reasons behind it, make notes, and remember those learnings
- Keep open-minded for the solution, hear their thoughts, and on standby to answer their questions and feedback
For example, I designed a new step 5 screen in a 7-steps flow that contains a setting with two radio buttons. The developer came to me and asked why radio buttons instead of a dropdown. I explained that usually when there are less than 3 options, the radio buttons has better discoverability and fewer clicks than a dropdown. But he gave me his perspective and I realized that 1. we have dropdowns in step 3 & 4 that stay consistency should be considered (less confusing and easier to develope); 2. most users will use the default settings, which means for the majority of scenarios dropdown is as good as radio buttons. Thus, the dropdown is delivered and functioning well.
“It doesn’t matter whose idea it is, as long as it’s inspiring.”
- Different devs have different preferences on how much flexibility their outcome should have — some prefer to be precise and match with the spec, others prefer to have some room for improvements; observe, discuss and find the sweet spot for the team
- Take part in all scrum ceremonies and propose a visualized workflow as a reference; try to keep iterating the flow and help the team stick to it; advocate for collaboration and speak up during retrospectives
Example in the design exploration and iteration stage:
(😇 & 😈 devs; 😉 designer tips)
When proposed a redesign that make users’ life easier but get push back:
😇 “This is much better than the previous solution, but I’m not sure we can implement it. The problems are xxx. The cost might be xxxx.”
😈“This is their job! It’s 30 clicks, so what? They have to figure it out!”
😉 “What is your concern about the redesign?” They might unveil their concern about performance, data security, and other things that they have not realized that we don’t know before. Based on valid concerns, work on a better solution to achieve the user goals and cancel developers’ worries.
Design solutions with Engineers in mind and get them through
- Have a sense of the development cost, reduce the senseless waste in our solution, and avoid over-design
- Always have a solid rationale for our design solutions. Get prepared to answer the question “why do you design that way?” and never just say “because it looks good!”
- For any design solution, think it over before the present. Building trust is like playing a game like this: if we are right and hit the point, we got +1 point, and if we are wrong, we lose 10 points. “Wrong” could be the team already started building or releasing a solution while the designer wants to make significant changes; go back and forth that waste devs’ time; make decisions on invalid assumptions
- For advanced designers: think about scalability; step ahead for the future and design a solution that is long-lasting so the developers don’t need to abandon existing build and reinvent the wheel
Examples in the design solution stage:
(😇 & 😈 devs; 😉 designer tips)
1. When presenting innovative solutions that might not be easily implemented:
😇 “I’m not sure, give me an hour to do some research to figure it out.”
😈 “No, that’s impossible to build.”
😉“Could you enlighten me why it is impossible?” Listen carefully to make sure if it’s still possible, then do some research or work on alternative solutions.
More importantly, during the design phase, if we have any doubts about the feasibility of the solution, ask them ahead or do some research (find existing examples) to avoid this scenario.
2. When presenting a solution that might have some potential risk:
😇“The solution is great, but the potential risk might be xxx; we can solve it from our side by solution 1,2,3; the cost for each solution might be xxx;”
😈“This is too risky. We can’t do that!”
😉“Do you mind to share with me why and are there any potential solutions you suggest?”
😈“OK, let’s do it.” (Just never mention the potential risk even he/she knows)
😉 Record all disasters and problems we experienced or heard about. When designing a similar solution, ask devs proactively about if there’s any risk.
Make their life easier in the handoff and QA stage.
- The handoff covers everything devs need to implement the product, including but not limited to Interaction specs (flow/hot spot/dynamic fields), Visual specs for all scenarios (grid/responsive rules/different screen sizes/devices/all status of widgets), Animations
- Try to find the best tools on the market to save everybody’s time (no more redlines, we have Zeplin and InVision Inspect and more tools to select)
- Build a good naming system for everything and organize our files in the best way for collaboration, especially slices for devs to implement
- Be specific and precise when communicating with devs. For web apps, learn some basic HTML&CSS and inspect to tell devs what exactly needs to change in the QA process.
In the example below, we need to change the title smaller. Instead of telling the developer, “make the title a little smaller,” it’s way better to send a screenshot with the mark on the CSS and say, “could you change the font size for studiocardv2 from 24px to 20 px?”
- Pay attention to the tone when pointing out something wrong — be blameless and positive. Ask HOW instead of WHY. We are building amazing things together!
- Don’t disturb engineers with minor QA issues because their work requires large blocks of uninterrupted time. If we have emergencies or questions, talk to PM or QA in the team instead of developers directly. Batch all the minor issues together and mention them in daily stand-up or scheduled meetings.
Examples In the handoff and QA stage:
(😇 & 😈 devs; 😉 designer tips)
1. During the handoff stage, the developer has some opinions or ideas:
😇 Gather the thoughts and discuss with the designer clearly about potential changes for the design and make the decision together. Never add or remove anything without notice
😈Add something extra (for example ⚠️️️️⚠️warning⚠️️️️⚠️ ) or surprise on UI without asking (“I thought that is an Easter Egg!”)
😉 “Is this expected?” or “Could you tell me why this is different from the design specs?”. Listen to their thoughts and explain why we can or can’t do that accordingly. For example “This is not aligned with our design library.” “The inconsistency will confuse users.” “That’s a great idea, let me think about it thoroughly and present the design later.” etc.
2. When pointing out the differences between the original design and the implemented UI during design QA:
😇 “Sure, no problem. Just fixed!”
😈“I can’t tell the difference.” 🤷♂️ “Normal people won’t notice that.”
“Ok, ok, I’ll fix it at the end of the sprint if we have extra time.”
😉 “Do you plan to change X to Y later?” “Ye, it is very subtle. Can you change that margin from 2px to 4px? (add screenshot)”
Put all UI QA and proposed updates together on a ticket that’s visible to the team and keep mention it during stand-ups to make sure it gets in.
Last but not least
Our design is the best weapon we have — designing something the developers will be proud to implement the best way to build the relationship.
Oh, about the cover image on top of the post, it’s a reminder: don’t be mean to developers; you guys have different standards!
Thanks for reading! Any comments, questions, suggestions, and feedback are appreciated.
