{"id":12895,"date":"2017-10-13T14:03:55","date_gmt":"2017-10-13T13:03:55","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=12895"},"modified":"2021-01-17T22:42:10","modified_gmt":"2021-01-17T22:42:10","slug":"heres-reverse-7-things-wished-developers-working-designers","status":"publish","type":"post","link":"https:\/\/www.shopjessicabuckley.com\/blog\/heres-reverse-7-things-wished-developers-working-designers\/","title":{"rendered":"Here\u2019s the Reverse: 7 Things I Wished Developers Did More of When Working with Designers"},"content":{"rendered":"

I had previously written \u201c<\/em>7 things I wished designers did more of when working with developers<\/em><\/a>.\u201d It may be tough for both sides to hear the tips but it wouldn\u2019t be fair for me to write a similar article for developers, right?<\/em><\/p>\n

So here it is.<\/em><\/p>\n

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.<\/p>\n

<\/div>
<\/svg><\/div>

\"In order to create great products, collaboration between developers and designers is key.\"<\/p><\/span><\/blockquote>\n

I\u2019ve 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\u2019ve conducted research, come up with ideas and fleshed them out into concrete designs. From a development perspective, I\u2019ve 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.<\/p>\n

1. Proactively give feedback, and be upfront about constraints<\/h2>\n

a. Just like designers can offer valuable feedback, developers can\u00a0too<\/h3>\n

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.<\/p>\n

<\/div>
<\/svg><\/div>

\"Design is about co-creating; developers are as integral to this as anybody else.\"<\/p><\/span><\/blockquote>\n

I interact with designers regularly throughout the design process. If you aren\u2019t 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\u2019s too late.<\/strong> It\u2019s important to manage expectations of designers, clients, product managers and other folks involved.<\/strong><\/p>\n

b. Factor in time to provide\u00a0feedback<\/h3>\n

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\u2019t already do this, I\u2019d 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\u2019re working on a complex product. Whether it\u2019s you or someone who will check back with the team, it\u2019s important that there is representation from the development team when it comes to defining a product.<\/p>\n

c. Why your feedback on a regular basis\u00a0matters<\/h3>\n

Reviewing and providing feedback on designs you will be building out is just as important as building out the actual designs. \u201cWhy?\u201d you may ask.<\/p>\n

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.<\/p>\n

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.<\/strong><\/p>\n

When you first start a project, the number of design alternatives is high and the cost to change your mind is low. There hasn\u2019t 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\u2019t wait for the latter half of this graph to speak up.<\/strong><\/p>\n

\"\"<\/a>

As you get further along in a project, the number of design alterations decreases but the cost to change your mind increases.<\/p><\/div>\n

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\u2019t do. It\u2019s 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 \u201ccan-do\u201d attitude is great but don\u2019t feel pressured to agree on the spot.<\/p>\n

<\/div>
<\/svg><\/div>

\"Speaking up about technical constraints does not make you any less qualified than a developer.\"<\/p><\/span><\/blockquote>\n

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.<\/strong><\/p>\n

Remember that innovation thrives in an environment of constraints. <\/strong>The willingness to embrace constraints and solve problems creatively is what will set you apart.<\/p>\n

2. Review notes, specs and\/or prototypes thoroughly<\/h2>\n

Details matter. Visual designers generally have spec\u2019ed out everything. My teammates groan when they are asked to change padding, color and spacing issues because it seems trivial. Trust me, I\u2019ve 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\u2019t think it\u2019s 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\u2019s a reason it was placed there. Colors are important as well. Most products must follow certain branding guidelines set forth by the company. Don\u2019t assume something is \u201ccosmetic\u201d or is \u201cso minor. \u201d Good design is intentional.<\/strong><\/p>\n

\"\"<\/a>

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\u00a0for.<\/p><\/div><\/center><\/p>\n

It\u2019s 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\u2019re 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.<\/p>\n

3. Ask questions if you\u2019re\u00a0unsure<\/h2>\n

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\u2019ve been overlooked by the team. Don\u2019t wait for the team to catch something. Asking good questions can help reduce some of the last minute design requests.<\/p>\n

<\/div>
<\/svg><\/div>

\u201cThe only thing more expensive than writing software is writing bad software.\u201d<\/p><\/span><\/blockquote>\n

\u2013 Alan Cooper, Founder of\u00a0Cooper<\/em><\/p>\n

Below are some questions that run through my mind designers hand me a screen design that shows a list of search results:<\/p>\n

    \n
  • Are we dynamically loading the same number of the search results below the current list?<\/li>\n
  • Are we using any animations when loading the results?<\/li>\n
  • What happens after we\u2019ve reached the last search result? Can I remove this \u201cLoad more\u201d button?<\/li>\n
  • Are we using a spinner when the results are loading?<\/li>\n<\/ul>\n

    4. Invite designers for informal\u00a0reviews<\/h2>\n

    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\u2019s contributions to a project, building stronger relationships and developing more respect for each other\u2019s work.<\/p>\n

    5. Shed light on your\u00a0workflow<\/h2>\n

    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.<\/p>\n

    <\/div>
    <\/svg><\/div>

    \u201cThe willing and even enthusiastic acceptance of competing constraints is the foundation of design thinking.\u201d<\/p><\/span><\/blockquote>\n

    \u2013 Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation<\/em><\/p>\n

    6. Learn how users interact with what you\u2019ve\u00a0built<\/h2>\n

    I\u2019d 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\u2019m building a product for. There\u2019s 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.<\/p>\n