{"id":10065,"date":"2020-09-28T09:26:16","date_gmt":"2020-09-28T07:26:16","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=10065"},"modified":"2022-01-05T20:06:19","modified_gmt":"2022-01-05T19:06:19","slug":"ux-designers-developers-together","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/frontend\/design-ux\/ux-designers-developers-together\/","title":{"rendered":"How to Bring UX Designers and Developers Together"},"content":{"rendered":"\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\tTable Of Contents\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
  1. Common challenges\u00a0between UX designers and devs<\/a>
  2. Key principles for developers<\/a>
  3. Strategies for UX designers\u00a0<\/a>
  4. Work practices that help\u00a0<\/a>
  5. Tools and processes to the rescue\u00a0<\/a>
  6. Want to launch a developer event despite the challenges of COVID-19?<\/a><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\n\n\n

    For most people, working with others is hard<\/strong>. You might struggle to work with those within your own team<\/span> but the challenge is even greater working with others from other teams<\/span> that might possess a completely different world view, training<\/span> background, working language, and suite of skills<\/span>. <\/p>\n\n\n\n

    An example is the relationship between devs and UX designers<\/a>. Both occupations are preoccupied with complex roles with fundamental differences. However, collaboration<\/span> provides a valuable opportunity<\/strong> to increase their comparative skills<\/span> and the benefit they provide to their organization<\/span>. <\/p>\n\n\n\n

    I spoke to numerous developers<\/span> and UX<\/span> designers<\/span><\/strong> to understand<\/span> common problems and tools<\/span>, strategies<\/span> and workplaces that help. <\/p>\n\n\n\n

    Common challenges between UX designers and devs<\/h2>\n\n\n\n

    Knowledge gaps between disciplines <\/h3>\n\n\n\n

    Josh Soldiers, senior experience<\/span> strategist, at O3 World believes that <\/p>\n\n\n\n

    “Not all UX<\/span> designers<\/span> have the same level of technical knowledge<\/span>, just as all developers<\/span> do not have the same knowledge<\/span> of UX and UI standards and best practices<\/span>. These knowledge<\/span> gaps<\/strong> between disciplines can often translate into misunderstandings or create barriers to communicate ideas<\/span>, iterate on solutions, or provide effective and actionable feedback on each other’s work.”<\/p>\n\n\n\n

    Chris Mills, Co-founder at Strongweek<\/a> gave some concrete examples of the challenges: <\/p>\n\n\n\n

    “A lot of UX<\/span> designers<\/span> don’t understand<\/span> how coding works<\/strong>. Your developer<\/span> is going to have to make structural decisions early on that might be hard to change later. When UX<\/span> designers<\/span> don’t understand the internal logic of the software they’re designing, they often make demands that can’t be implemented<\/span> easily. Imagine asking a car mechanic to add a few extra rows of seats in your Chevy Cobalt. When a UX<\/span> designer<\/span> doesn’t understand how a product is built, their demands can be just as unfeasible.”<\/p>\n\n\n\n

    He contends that comparatively. <\/p>\n\n\n\n

    “Developers<\/span> are often very literal<\/strong>. Several times while working with developers<\/span>, I’ve sent them screenshots and quick mockups that to illustrate general concepts and ideas. Even though the screenshots were not to-spec and were meant to be illustrative rather than literal, developers<\/span> went ahead and implemented<\/span> them.”<\/p>\n\n\n\n

    \"\"<\/figure><\/div>\n\n\n\n

    An unbalanced developer-to-designer ratio<\/h3>\n\n\n\n

    Victor Lavrentyev, CIO<\/span> at Orangesoft notes an unbalanced developer<\/span>-to-designer<\/span> ratio can also cause problems<\/strong>:<\/p>\n\n\n\n

    “There are some cases where a cross-functional team<\/span> can have one designer<\/span> and about 60 developers<\/span><\/strong>. While that might seem odd, it’s still quite common. The differences in training<\/span>, language, and approach make the designer<\/span> stick out like a sore thumb with their understanding<\/span> and ideology. And the dev colleagues won’t seem approachable at all.”<\/p>\n\n\n\n

    Key principles for developers<\/h2>\n\n\n\n

    Kevin Silver, Experience Design Director at Mad*Pow stressed the value<\/span> of developers<\/span> understanding<\/span> basic design principles<\/strong>: <\/p>\n\n\n\n

    “They should be aware of the personas<\/span><\/strong>. They should be part of the process of building what is best, not just the tools<\/span> who put together all the things that the product team and UX<\/span> put together. But this has to start with informing the developers<\/span> of design thinking.”<\/p>\n\n\n\n

    He also contends that “Developers<\/span> (or at least the lead\/architect) must be brought in early on in discussions<\/span> about new products and features. They should be part of the conversation<\/span><\/strong> so they can bring things up that are incompatible with the framework or technology – as well as bring insights from their experience<\/span> and knowledge<\/span> of technology<\/span>. This also ensures they understand the Whys that lie behind design decisions.”<\/p>\n\n\n\n

    Strategies for UX designers <\/h2>\n\n\n\n

    When designers<\/span> are working in a developer<\/span>-led culture, they often need to adapt<\/span> and approach things more collaboratively<\/span><\/strong>. David Hendee, VP of Design<\/span> at Carbon Five suggests<\/p>\n\n\n\n

    Collaborative brainstorming<\/h3>\n\n\n\n
    \"\"<\/figure><\/div>\n\n\n\n

    Ideate with developers<\/span>: when you’re brainstorming<\/strong> potential solutions, include developers<\/span> to help come up with ideas<\/span>. This adds new ideas<\/span> to the mix and helps set the stage for better collaboration<\/span> during the build phase. Kevin agrees, suggesting that UX<\/span> practitioners invite developers<\/span> to Design<\/span> Studio or Jam sessions.<\/p>\n\n\n\n

    Create a “living styleguide”<\/h3>\n\n\n\n

    David suggests using a component<\/span> library or a mental framework like Atomic Design<\/span> can help communication<\/span> between designers<\/span> and developers<\/span><\/strong>. It also lets the team work on some features without the designer<\/span> having to create high fidelity artefacts. <\/p>\n\n\n\n

    Drew Falkman, Director, Strategy<\/span> at Modus Create, also suggests that design systems – or at least design standards – can go a long way to alleviating the problem of nitpicking:<\/p>\n\n\n\n

    “It eases reuse and ensures consistencies<\/span> from the beginning at a high level without having the designers<\/span> have to perseverate on comps or prototypes<\/span>.”<\/p>\n\n\n\n

    Pair with developers and UX<\/h3>\n\n\n\n

    When developers<\/span> are building features you’ve designed, especially when a developer<\/span> is working on a feature without a design artefact attached, offer to pair with them before they deliver their work. This thirty-minute pairing session<\/strong> can help tighten up the design<\/span> without unduly impacting the development effort.<\/p>\n\n\n\n

    Create a design punch list<\/h3>\n\n\n\n

    Like developers<\/span>, sometimes we accrue design debt. Periodically creating a checklist of design tweaks and other nice-to-haves is a great way to pay down that debt without slowing down the team<\/span>.”<\/p>\n\n\n\n

    Learn to let go<\/h3>\n\n\n\n

    Drew also contends that UX<\/span> designers<\/span> need to let go a little: <\/p>\n\n\n\n

    “Where developers<\/span> have to learn<\/span> design thinking, UX<\/span> designers<\/span> need to learn<\/span> to let go all of the pixel-perfect decisions so that the development team has some ownership. This isn’t to say there shouldn’t be design requirements<\/span> and standards that have to be followed, just that they need to be open to input from developers<\/span><\/strong> that advance the product.<\/p>\n\n\n\n

     The least successful teams<\/span> I’ve seen often have considerable back and forth between design and development about moving an item, making buttons more rounded, changing fonts from Bold to Black, etc. Constant nitpicking disempowers developers, and they will eventually stop taking ownership of the product, stop giving input, and there will be more bugs<\/span> and more friction between UX<\/span> and engineering.”<\/p>\n\n\n\n

    Work practices that help <\/h2>\n\n\n\n

    Kevin offered suggestions for fostering good work practices<\/a> between devs and UX<\/span> team<\/span> members:<\/p>\n\n\n\n