Designing Systems for the Designer — Developer Relationship
I first started working with developers in the school of Interaction Design where students are given briefs and are tasked to ideate and build a product within a stipulated timeframe. Groups are formed, friendship gets tested and eventually roles are assigned. Two roles largely determines the project outcomes:
Designers and Developers
Alas! The struggles of designers and developers relationships were introduced in my unqualified days of being a product designer. Barely understanding design or development methods (eg. Sprints, Scrums) and unequipped with the right tools for communication, we made do with what made most sense at the point of time. Which predominately means MSN messengers and what is easiest to develop and could get in time for submission.
With the shutdown of MSN messenger, I knew I had to start looking for a more robust communication method.
Fast forward 6 years, with my current start up and team, we set out to design a robust system and process to aid and relieve the friction caused by poor designer — developer exchanges. Here are some of the steps we’ve used so far and I hope it can prove useful to your team.
1. Execute Due Diligence
By due diligence I mean taking time to understanding your team’s strengths and weaknesses. Get everyone on your team to speak about what they’re best at doing and divide primary roles base on your findings. Don’t make a UX researcher’s primary role strategise motion UI or make a front end developer develop backend logic.
That being said, in every small team everyone wears multiple hats but make sure the largest hat you’re wearing is what you’re best at.
2. Freeze your idea.
Unless you’re working alone, you will have differentiating opinions on the same product with multiple stakeholders. Validate what problem your product solves and how you’re going to do it, then freeze on the ‘how’. Invest time to write a functional specification document that clearly outlines every feature, requirements and business logic involved.
Knowing how to freeze your idea at the beginning will help designers and developers get started on their craft quickly. While working on the product, people WILL come and give ideas, ideas out of your functional specification. These ideas should go through a feature request process that lets the designers, developers and invested stakeholders validate its importance in the current phase and whether its importance is large enough to warrant the inclusion of that feature.
3. Team timelines
After everyone gets a clear idea of what they’re going to build and with the roles and responsibilities put in place, its time to set timelines. Team timelines for designers and developers should be set in parallel.
Parallel timelines lets both the designers and developers have a grasp of what they should be working on at that time and understand the dependencies for a particular group task to be completed. For example, in order for the login pages UI to be developed, the UI must first be designed by the designer, and in order to get that design, the parameters of a login must be indicated in the functional specification. By setting parallel team timelines, teams that are working remotely can also have something to fall back on.
5. Speak the same language.
Everyone in the team should understand what terminologies and verbiage each others are using.
If everyone decides that a pop up window on top of an 50% black opacity overlay should be called a modal, everyone should start calling it a modal. Not dialog windows or light boxes.
Development environments should be discussed before real development work begins and design teams should work towards creating on a coherent design language and component library accessible by everyone on the team.
To elaborate, if the space between each single item list is 60px in height, the component library should indicate that so the developers can have a clear reference of the design guidelines. Because of the shared nature of design components, whenever there’s a major UI overhaul, everyone will be kept in the know.
Conclusion
Understanding the lubricants to ease design-developer communication helps team streamline the product and work leaner and faster.
This process has yet to be stress tested against diverse designer-developer groups and we’re sure theres much to iterate and tweak. We’re looking forward for our product launch and sharing with you our results. Hopefully our process will help yours too.
-Yang
