Ever worked on a project where Design and Development blended like oil and water? Whether you're on a UX team of one, or designing with the help of a whole department, the success of your work ends up in the hands of a developer.
Teams with specialized skillsets and certain cross-team cultures can put up walls between designers and developers. We will deconstruct these adversarial relationships from real-world examples, then learn how to convince, collaborate, and co-create.
Being stuck in a storming phase isn’t good for you, your product, and ultimately your users. Bringing harmony to your team is important to your success and your sanity. Hone your best expertise to build relationships, handle differences of opinion, and learn to speak geek to be heard!
Walk out with tools and techniques to stay efficient and deliver the best possible experience for the real human beings who will use it.
6. Bridging the gap from adversarial to
harmonious is possible...
+ Teamwork
techniques
Personal
connection
7. Think about your best or most
positive experience working with
one or more developers.
What made it positive?
What made it productive or
enjoyable, or both?
Why do you think it
worked well?
9. Teams in the wild
Unicorn. One person team that does it all—and pretty well.
Horse. Jack-of-all-trades, master of none or one—the results show it.
Over-the-wall. Design + Dev working as an assembly line.
Integrators. Design + Dev collaborate, but it’s back-and-forth and
everyone stays in their corner.
Partnership. Design + Dev are in it together, from the beginning.
10. Designer personas
Visual only. Master of Illustrator, meticulous aesthetic detail, no or
limited exposure to implementation.
Tech savvy. Understands how designs will “translate” to code, foresees
constraints, .
Prototyper. Knows their way around markup, builds prototypes, speaks
“code” to developers.
11. Developer personas
Backend. Works on underlying functionality of product, no or limited UI
exposure.
Frontend frameworker. Great at Legos, builds UI with frameworks,
limited ability to make custom controls and experiences.
Frontend master. Solid grasp on UX, can bring a new and unique UI
to life from the ground up.
Full stack. Hybrid backend and frontend skills, in the unique position to
make end-to-end UX shine.
14. Differing priorities for Design and Dev teams.
Timelines and budget constraints.
Miscommunications and terminology.
Opposing philosophies.
Divergent goals.
25. What do designers and
developers bring to the table?
What do UXers see that
devs may not?
What do devs see that
UXers may not?
What do you bring to the table?
39. Tie-break in the wild
Use A/B testing to choose the best experience.
Works when engineering is cheap and UR is the long-pole.
40. Test UX with real code
Partner w/ dev to “stress test” designs.
Helps cover more variations, keeping everyone aligned.
Easy to repeat tests as design evolves.
41. Co-present to peers and leadership
Win together.
Quickly cuts to “what’s important”.
Everyone wants to look good.
45. 1. Pick a few techniques we talked about
today that you want to try.
2. Describe the project or people you’ll try
them with.
3. What actions will you take and when?
Make your plan of action
[LAURA] Maybe you presented your designs and they were shot down by developers who said they were too much work, or there was no need to implement what you created or make a critical UX fix that you know will have serious consequences.
Maybe you had to triple your original time investment because you spent your days persuading, advocating, wheedling, and wheeling and dealing to get at least part of your work into implementation.
Maybe your wonderfully designed experience was barely recognizable by the time that engineering sent it to build.
Maybe it all came out exactly like you planned, but both you and the developers came out of the experience exhausted and hoping you never had to work together again.
Maybe you simply were not able to get your ideas and the user needs across.
[NICK] If you can relate to Laura’s examples, you were—or are—stuck in a Storming phase with your team.
You may have heard of the Stages of Group Development – Forming, Storming, Norming, Performing. These stages describe the journey groups go thru and revisit.
[NICK] Being stuck here can be demotivating for all involved. It means you collectively won’t be doing your best work, impacting the quality of your product and ultimately delivering a worse experience for users. In other words: We fail to deliver greatness; and nobody is happy!
There has to be a better way to work together.
[LAURA] You have come to the right place!
Today we’re going to talk about what you can do to bring your team together, reducing your stress and giving you back some sanity.
[NICK] We’ll be talking about two key aspects of bridging the gap—making a personal connection and techniques to work better as a team.
But before we do that, let’s all get fresh examples in our minds—and we *all* have some examples in mind.
[LAURA] Jot down a few examples.
1 to 2 attendees share their experiences.
[LAURA]
[NICK] Team Models “in the wild”
•Unicorn – the one person that can do it all, and for the most part they do a pretty good job
•Horse – the person that thinks they’re a unicorn, but they’re more a jack-of-all-trades, master of none or one and the results show it
•Design + Dev, Over-the-Wall – separate contributors for design and development, but limited collaboration, more of an assembly line or over-the-wall relationship
•Design + Dev, Integrators – separate contributors for design and development, some collaboration but primarily back-and-forth, everyone works in their corner
•Design + Dev, Partnership – separate contributors for design and development, collaboration from the beginning, iterating in tight loops together
[NICK] Types of Designers
•Visual Only – a master of Illustrator with an eye for aesthetics and incredible attention to detail, but little understanding of how what they draw will get built
•Tech Savvy – understands how their designs will “translate” to code, can foresee some constraints
•Prototyper – builds out their design in an interactive prototype, and speak “code” to developers
[NICK] Types of Developers
•Backend – works on the foundations needed for a product to function behind the scenes, no or very limited frontend experience
•Frontend Frameworker – can build out a user interface, but relies on pre-made building blocks and frameworks with limited ability to create new controls, components, etc
•Frontend Master – strong understanding of design, reuses frameworks where it makes sense but will also build custom experiences from the ground up
•Full Stack – a hybrid of backend and frontend skills, great at making the true end-to-end experience shine
[LAURA]
[LAURA]
[NICK] Async,
[LAURA]
[NICK]
[NICK]
[NICK]
[LAURA]
[LAURA] Remember, "Speak the users' language"? It holds internally, as well.
Foreign language example.
[LAURA] Know that geeks love to share their “beautiful code” and “beautiful information”! Give them a chance. Whether you immediately ‘get it’ or not, the time you have taken to listen acknowledges value that will buy you new courtesies as you speak and convince in the future.
Just talk to them like people.
[LAURA] A single moment of clarity can happen in the midst of argument when we picture ourselves and the other as two five-year-olds, with scowls on our faces, and our feet not touching the floor. There is lovely absurdity and truth in the picture that trigger a laugh within us, and introduce a sudden compassion and lightness into how we respond to the one in other chair. A spark of communication can truly happen then.
[LAURA] Connecting with what comes naturally to developers can mean a foray into what doesn't come naturally to the user experience and design states of mind. This and the next one take partnering in a different direction than we normally go as UXers.
Make “What would it take to make this?” a core approach to connecting, as well as learning and growing in technical knowledge, yourself.
[LAURA] Once you learn what development needs in order to make things happen, defend their approaches and constraints. If you have asked and learned the "what will it take" question on a regular basis, you will know how to help them communicate it to others making requests or demands. You become and clear and gentle voice of reason and demonstrate a united front. Why would we do this? Because 'doable' means our designs get done! Suddenly an engineering limitation becomes your best friend in seeing our work become real and be placed in the hands of the users we love.
[NICK] Partners talk about what designers and developers bring to the table.
No sharing after.
[LAURA]
[NICK]
[NICK] Get connected. Talk early and often, before code gets written and wireframes get drawn.
[NICK] Listen. Understand everyone’s goals and share yours.
[NICK] Play the accordion. With the end of the project in mind, roughly map out the expand/contract phases you’ll go thru to help set boundaries on when to dream big and when to get tactical.
[NICK] Explore together. Pair up and prototype, give ideas a quick try to see how they feel and foster the design/dev relationship early.
[LAURA] Starting with engineers at discovery and concepting delivers benefits to your work and theirs, improving schedule, feasibility, and quality. From the beginning, you will know if ideas could work. At the beginning you prime the developer’s mind to think beyond what has been done before. All together, along with product owners and content domain experts, lies the potential for magic that can both be delivered and make the users happy as well.
[LAURA] If your designs are already technically feasible, and not a surprise, it’s surprisingly easy come development time to see them come out the way that you planned.
Innovation team example.
[LAURA] Describe the ‘great good’ or ‘intensely bad’ that can happen when UX is abandoned for convenience or other rationale. Click-thru, data loss, and future reuse versus rework are powerful convincers that need only vague numbers to support.
[LAURA] Find something, anything, to count! When all else fails, numbers can win the day.
[LAURA] We are all called on at times to ‘give up’ what we know is right, best, or just more intriguing for the user. When that is the final solution to a “can’t be done” reaction, take the time to console yourself and truly let go.
[NICK]
[NICK] Timebox prototyping – don’t get paralyzed looking for perfection, agree how long you’ll spend on an exploration / prototype / iteration and stick to it
[NICK] Split the difference using A/B testing – it can be quicker/cheaper to build a variant of an experience instead of having dev wait for a design to get on the UR schedule, see if dev agrees to build the variants and test with real users
[NICK] Test flows early with simulated user states – early in-product “stress testing” of designs, these can cover many variations and provide a repeatable testbed to check future design tweaks
[NICK] Co-present to peers and leadership – the common goal of sharing your ideas and work with others helps unite for mutual benefit
[NICK] Frontend code review – after the code is written, sit together to walk through the experience, praise and polish together
[NICK] Working sessions to put the finishing touches on the visual and interaction aspects of the experience before it goes to users