I had previously written “7 things I wished designers did more of when working with developers.” It may be tough for both sides to hear the tips but it wouldn’t be fair for me to write a similar article for developers, right?
So here it is.
In order to create great products, collaboration between developers and designers is key. Although developers and designers may focus on different aspects of a product, developers may have more in common with designers than most think. Both designers and developers are analytical and creatively solve problems. The organizational structures for developers and designers may vary from company to company, and even within development teams, there may be sub-teams as well. For a project to be successful, developers and designers need to work closely together regardless of the organization structure.
"In order to create great products, collaboration between developers and designers is key."
I’ve been on both sides, and wanted to take some time to put together a few ideas that hopefully some of you may find helpful. From a design perspective, I’ve conducted research, come up with ideas and fleshed them out into concrete designs. From a development perspective, I’ve built out designs as closely as possible to what the design team has worked on. And there were times when I have both come up with the concepts and implemented them. I hope this background helps you understand that I am not to offend one side or another (why would I take so much time to do that!?). I see the value in what everyone brings to the table when they work together, and love seeing both sides collaborate efficiently and effectively.
1. Proactively give feedback, and be upfront about constraints
a. Just like designers can offer valuable feedback, developers can too
Many developers I have worked with have a lot of experience and insights, especially when they have been working in the industry or on a specific product for a while. Many developers are involved in wireframing, prototyping, and visual design nowadays so have a lot to offer in terms of feedback to designers. Design is about co-creating; developers are as integral to this as anybody else.
"Design is about co-creating; developers are as integral to this as anybody else."
I interact with designers regularly throughout the design process. If you aren’t already, get involved in meetings. Although you may not need to be involved in every conversation, check with your team or project manager to make sure you are involved in important conversations that define how the product functions. This gives you the chance to speak up before it’s too late. It’s important to manage expectations of designers, clients, product managers and other folks involved.
b. Factor in time to provide feedback
Working on the current sprint while also providing feedback for designs in the next sprint is not easy. Because of urgent deliverables, you may end up prioritizing the first sprint instead. This often leads to problems later on. If your team doesn’t already do this, I’d recommend you (and/or your project manager) factor in time to provide feedback on designs when planning. I wish I had done more of this in some of my projects because providing feedback can turn into a part-time job when you’re working on a complex product. Whether it’s you or someone who will check back with the team, it’s important that there is representation from the development team when it comes to defining a product.
c. Why your feedback on a regular basis matters
Reviewing and providing feedback on designs you will be building out is just as important as building out the actual designs. “Why?” you may ask.
Think about it from the perspective of a designer who had spent a lot of time deciding how something should look or function, a client who had signed off on a design months ago, a project or product manager who has to manage expectations from different parties, or a senior manager who has communicated information about the deliverables.
Below is a graph I use when I lead workshops about UX and why the design process matters. As you get further along in a project, the number of design alterations decreases but the cost to change your mind increases.
When you first start a project, the number of design alternatives is high and the cost to change your mind is low. There hasn’t been that much invested into the project. As time goes on in the project and teams have made more investment in a project, the number of design alternations decreases more and more. In the meantime, the cost to change your mind gets higher and higher. Don’t wait for the latter half of this graph to speak up.
As you get further along in a project, the number of design alterations decreases but the cost to change your mind increases.
If you have concerns about the feasibility of a design proposal, be honest. It may be difficult to appear vulnerable, admitting there there may be some ideas you can’t do. It’s okay to ask for time to provide feedback. I appreciate it when my teammates take time to conduct research and assess thoroughly, and I hope they appreciate it when I do. A “can-do” attitude is great but don’t feel pressured to agree on the spot.
"Speaking up about technical constraints does not make you any less qualified than a developer."
Speaking up about technical constraints does not make you any less qualified than a developer; in fact, it earns you more respect when you articulate the constraints clearly and help the team find an alternative.
Remember that innovation thrives in an environment of constraints. The willingness to embrace constraints and solve problems creatively is what will set you apart.
2. Review notes, specs and/or prototypes thoroughly
Details matter. Visual designers generally have spec’ed out everything. My teammates groan when they are asked to change padding, color and spacing issues because it seems trivial. Trust me, I’ve been asked by designers to move text up another 2px. After spending 120 hours debugging one feature, it sometimes can be discouraging to hear this type of feedback. However, I understand that this all matters in a user interface. Even if you don’t think it’s a big deal that a label is an extra 5px further away from a field, it may impact the user experience. A user confuses two fields because one label was closer to the wrong field. Proximity, for example, is an important aspect of design so there’s a reason it was placed there. Colors are important as well. Most products must follow certain branding guidelines set forth by the company. Don’t assume something is “cosmetic” or is “so minor. ” Good design is intentional.
We may think that the left alignment of the labels is not a huge deal. However, the designer had specified that the labels be right aligned so that they are closer to the input fields they are meant for.
It’s great to bring in fresh ideas. Your feedback is valuable so try to do this early on (see #1). If you would like to deviate from the approved designs either in styling or functionality, communicate this early and check with the team before you spend time doing this. If you’re suggesting changes at a later point, check with your teammates first and come prepared to explain the reasoning behind the deviations. Depending on your team and what phase of the process you are in, surprises may be welcomed only with a valid reason.
3. Ask questions if you’re unsure
This seems obvious but unnecessary miscommunication happens a lot in the workplace in general. If anything is unclear or you have questions about any of the design decisions, ask the designer. This is a great opportunity for developers to come and fill in any missing pieces that might’ve been overlooked by the team. Don’t wait for the team to catch something. Asking good questions can help reduce some of the last minute design requests.
“The only thing more expensive than writing software is writing bad software.”
– Alan Cooper, Founder of Cooper
Below are some questions that run through my mind designers hand me a screen design that shows a list of search results:
- Are we dynamically loading the same number of the search results below the current list?
- Are we using any animations when loading the results?
- What happens after we’ve reached the last search result? Can I remove this “Load more” button?
- Are we using a spinner when the results are loading?
4. Invite designers for informal reviews
Even if there will be QA reviews, be proactive about doing reviews early and regularly so you can make adjustments accordingly. Seek out opportunities for pairing sessions with a designer, if this does not already exist at your organization. This also helps both developers and designers understand each other’s contributions to a project, building stronger relationships and developing more respect for each other’s work.
5. Shed light on your workflow
Some designers may not be aware of the entire phases of development like testing, bug-fixing and documentation. Similar to what I discussed in the previous point, sharing your workflow helps you manage expectations and set boundaries of how changes are handled. When I inform designers about my workflow, they understand that changes take time and I may not be able to implement them overnight.
“The willing and even enthusiastic acceptance of competing constraints is the foundation of design thinking.”
– Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation
6. Learn how users interact with what you’ve built
I’d recommend that everyone on a product team be involved in the research process to some extent. You can listen in on a few calls, watch a recording, or review a slide with key findings. While it may feel like time taken away from our main focus, being engaged in at least some of the research process helps me build empathy for our users. Even as a developer, it is important for me to empathize with users I’m building a product for. There’s nothing like building empathy when a developer watches her users get frustrated at a screen taking minutes to load because of an overlooked performance issue.
It’s one thing to know abstractly that it’s frustrating for users but it’s another thing to watch a user get frustrated interacting with a product that you worked on.
Insights gained from user research also gives me a thorough understanding of what needs to be done first and why, creating a stronger sense of joint ownership and creation.
7. Understand where design changes are coming from
Designers are on the same team as you. Try to be empathetic about design changes. It’s understandable to be frustrated about last minute design changes. It is not fun. However, a change is not personal. Give people the benefit of the doubt that the change is to get the best final product, or to accommodate business goals. There are times the development team pushes back and there are times when the change is critical to the delivery.
If you need to spend time on a design change, this usually means that a designer has or will spend some amount of time too on it — although I’ll admit that the amount of time is not always equal. Maybe a design change requires minimal effort of a designer but requires a lot more effort from a developer. However, let’s think about the reverse scenario when there’s a change that requires a lot more effort from a designer. Maybe he or she had to conduct multiple usability testing sessions, revise their designs, conduct more usability testing, get buy-in from different stakeholders, revise again until a design is finally approved. Ask questions to understand the reasoning and have faith that changes are generally an effort to make a better final product.
"Everyone is on the same team and has the same goal of creating a great product."
Conclusion
To achieve your team’s vision, empathy, communication, and organization are all key. Because design is about co-creation, developers play an important role in the process. Everyone is on the same team and has the same goal of creating a great product. I see the value in everyone’s contributions, and love seeing both sides work together as best as possible to create something they are proud of at the end.
Further reading:
- User Testing Without Users
- Marvel User Roles: Team Members & Contributors
- Managing Design Handover
- Making the Case for Design Sprints
If you haven’t already, check out: 7 things I wished designers did more of when working with developers.
