Shipping products for our clients is at the core of what we do as a Product Design team. Our expertise and experience is why our clients trust us enough to come back and work with us for multiple engagements. But shipping a good product goes beyond a well thought-out user experience, beautiful UI, and flawless interaction model. A good product starts with excellent communication between all team members so that every player is engaged and working together to solve the same problem.
Setting yourself up for...failure
At the core of many product problems are disconnects between the design team and the development cycle. At the worst of times, these two are often working in siloed teams. This means that design is forced to make a lot of assumptions about how to design the complete product experience, rarely receiving feedback about potential implementation constraints.
Likewise, many times developers have questions about layout that are not covered in the documentation and, again, making assumptions can lead to a inconsistent product. Having a close relationship between the design and development teams will afford you the ability to collaborate and communicate much more efficiently.
(P.S. We also wrote a pretty great piece about why you need to stop depressing the value of design by compartmentalizing it.
The problem with documentation
Design has inherited the concept of “good” communication as the formal documentation that guides our designs — static representations that are painfully annotated over many hours, calling out pixel dimensions, type sizes and color palettes. As designers, we tend to think that our documentations are bulletproof, or that they are the labor intensive finale bringing together all the weeks and months of design thinking. But really, they are a superficial representation of how to build the thing we are then “throwing over the wall” for someone else to build.
Redlines are well-intentioned. They do provide essential pieces to the overall puzzle when dissecting a static picture of a dashboard, navigation, or long form narrative. But as a document they only support the visual designs. In theory, redlines are fine, but in practice they fail for a number of reasons.
Software is at times a moving target and as the product is built, the teams inevitably encounter countless moments where questions have not been asked and the answers have not been answered. These Q’s and A’s don’t lend themselves to something a redline can solve. This is where the communication breaks down and collaboration ends.
Conversation, FTW!
To navigate this problem, the MojoTech Design team has taken to education through conversation. We sit down with the entire team and problem solve alongside engineers, whether there's a hole in the design, an edge case wasn't thought out, or someone has an idea for a better solution. Allowing engineers to have a stake in the process and provide input beyond reading a static picture (and getting them into a design file to dissect it) is essential.
The concept of fostering dialogue outside of a meeting is worth noting as well. Getting up and walking over to one of your colleagues and engaging in a conversation is invaluable as a lot of problem-solving happens organically outside the four walls of a conference room.
Couple conversation with a well organized design file and this should do a heck of a lot more for the process than a static redline.
A few good practices we employ to stimulate better conversation include:
1) Getting the whole team working together, or slightly staggering when designers and developers start so there is always overlap.
This starts building the conversation early and allows for the entire team to be included in the process of building the software. The overlap allows design to begin on new features while the engineers can wire up aspects of the product that have been designed, getting them into stakeholders hands faster for testing and feedback.
2) Literally breaking down the wall and working in close proximity to each other.
At MojoTech, project teams move desks to sit in the same “pod” as each other. This facilitates critical conversations that need to take place outside of Slack and email. Team members can easily share their screens, and code can be tweaked side-by-side.
3) Using browser tools to tweak padding, color, type sizes with an engineer.
This will bypass any need for redlining a static image.
4) Giving engineers a quick tutorial of any design tools they should be familiar with on the project.
After opening a .sketch or a .psd file to explain what elements to look for, designers can even go a step further and create a template for organizing a file. While an engineer isn’t necessarily concerned with making new designs, they can inspect elements within an art file to get exact dimensions they might need for typography, image sizes, navigation elements, and grid systems.
“Should designers code” is a hot topic these days, but advocating that developers should at the least understand how to open a Sketch file and inspect an H1 can increase the quality of communication and narrow the skills gap between the two roles.
Conclusion
Your team’s goal should be to make the best product possible, with every player engaged and working together to solve the same problems.
Try challenging your team to limit the number of design artifacts and embrace conversation over documentation. You'll save time. You'll save your budget. And best of all, your team can start building products faster, stronger, and more easily.