adversarial to harmonious: building the developer/ux connection

46
#UXPA2016 www.uxpa2016.or Adversarial to Harmonious Building the Developer / UX Connection Nick Tucker @ncktckr Laura Faulkner, PhD @ laurafaulkner

Upload: uxpa-international

Post on 20-Feb-2017

115 views

Category:

Technology


1 download

TRANSCRIPT

PowerPoint Presentation

Adversarial to HarmoniousBuilding the Developer / UX ConnectionNick Tucker@ncktckrLaura Faulkner, PhD@ laurafaulkner

#UXPA2016www.uxpa2016.org

1

Ever worked on a project where Design and Development blended like oil and water?

[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.

2

Being stuck in a storming phase isnt good for you, your product, and ultimately your users.

[NICK] If you can relate to Lauras examples, you wereor arestuck 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.3

Differing goals, work styles, personalities, and pressures

lead to messy results, slow deliveries, and frustration

[NICK] Being stuck here can be demotivating for all involved. It means you collectively wont 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.4

Bringing harmony to your team is important to your success and your sanity.

[LAURA] You have come to the right place!

Today were going to talk about what you can do to bring your team together, reducing your stress and giving you back some sanity.5

Bridging the gap from adversarial to harmonious is possible...+Teamwork techniques

Personalconnection

[NICK] Well be talking about two key aspects of bridging the gapmaking a personal connection and techniques to work better as a team.

But before we do that, lets all get fresh examples in our mindsand we *all* have some examples in mind.

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?

[LAURA] Jot down a few examples.

1 to 2 attendees share their experiences.7

Specialized skillsets and cross-team cultures can put up walls between designers and developers.

[LAURA]

Teams in the wildUnicorn. One person team that does it alland pretty well.

Horse. Jack-of-all-trades, master of none or onethe results show it.

Over-the-wall. Design + Dev working as an assembly line.

Integrators. Design + Dev collaborate, but its back-and-forth and everyone stays in their corner.

Partnership. Design + Dev are in it together, from the beginning.

[NICK] Team Models in the wildUnicorn the one person that can do it all, and for the most part they do a pretty good jobHorse the person that thinks theyre a unicorn, but theyre more a jack-of-all-trades, master of none or one and the results show itDesign + Dev, Over-the-Wall separate contributors for design and development, but limited collaboration, more of an assembly line or over-the-wall relationshipDesign + Dev, Integrators separate contributors for design and development, some collaboration but primarily back-and-forth, everyone works in their cornerDesign + Dev, Partnership separate contributors for design and development, collaboration from the beginning, iterating in tight loops together

Designer personasVisual 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.

[NICK] Types of DesignersVisual 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 builtTech Savvy understands how their designs will translate to code, can foresee some constraintsPrototyper builds out their design in an interactive prototype, and speak code to developers

Developer personasBackend. 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.011010000110000101111000

[NICK] Types of DevelopersBackend works on the foundations needed for a product to function behind the scenes, no or very limited frontend experienceFrontend Frameworker can build out a user interface, but relies on pre-made building blocks and frameworks with limited ability to create new controls, components, etcFrontend Master strong understanding of design, reuses frameworks where it makes sense but will also build custom experiences from the ground upFull Stack a hybrid of backend and frontend skills, great at making the true end-to-end experience shine

Deconstruct adversarial relationships from experiences.

[LAURA]

What causes friction?

[LAURA]

13

Differing priorities for Design and Dev teams.Timelines and budget constraints.Miscommunications and terminology.Opposing philosophies.Divergent goals.

[NICK] Async,

In moments of stress, we all become 5-year-olds.

[LAURA]

What does everyone want?

[NICK]16

Make customers happy so they love our product.

Build something cool, interesting, innovativesomething we can be proud of.

[NICK]

How can we begin?

[NICK]18

Build relationships, handle differences of opinion, and learn to speak geek to be heard!

[LAURA]19

Keep a running list of terms.Terms buy you respect.Fun references buy you rapport.

[LAURA] Remember, "Speak the users' language"? It holds internally, as well.

Foreign language example.

Ask, What is a at least everyother day.Support your geeks to share their "beautiful information and "beautiful code."

[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.

Diffuse ourselves.Try this:Picture your inner 5-year-old

[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.

Take the time to understand constraints.

[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.

Defend development needs and goals.

[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.

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?

[NICK] Partners talk about what designers and developers bring to the table.

No sharing after.25

What do we need todo as teams?

[LAURA]26

Learn how to convince, collaborate, and co-create.

[NICK]

Get connected. Talk early and often.

[NICK] Get connected. Talk early and often, before code gets written and wireframes get drawn.

Listen. Understand everyones goals.

[NICK] Listen. Understand everyones goals and share yours.

Play the accordion. Define your expand / contract phases.

[NICK] Play the accordion. With the end of the project in mind, roughly map out the expand/contract phases youll go thru to help set boundaries on when to dream big and when to get tactical.

Explore together. Pair up and prototype.

[NICK] Explore together. Pair up and prototype, give ideas a quick try to see how they feel and foster the design/dev relationship early.

Bring developers in at the beginning.

[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 developers 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.

Seek constant feedback to get later buy-in.

[LAURA] If your designs are already technically feasible, and not a surprise, its surprisingly easy come development time to see them come out the way that you planned.

Innovation team example.

Be prepared to describe impact.

[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.

Use data and metrics.

[LAURA] Find something, anything, to count! When all else fails, numbers can win the day.

Practice a graceful acceptance of give and take.

[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 cant be done reaction, take the time to console yourself and truly let go.

Tools and techniques to stay efficient and deliver the best possible experience for real people.

[NICK]

Timebox prototypingDont get paralyzed looking for perfection.Set your boundaries ahead of time.

[NICK] Timebox prototyping dont get paralyzed looking for perfection, agree how long youll spend on an exploration / prototype / iteration and stick to it

Tie-break in the wildUse A/B testing to choose the best experience.Works when engineering is cheap and UR is the long-pole.

[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

Test UX with real codePartner w/ dev to stress test designs.Helps cover more variations, keeping everyone aligned.Easy to repeat tests as design evolves.

[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

Co-present to peers and leadershipWin together.Quickly cuts to whats important.Everyone wants to look good.

[NICK] Co-present to peers and leadership the common goal of sharing your ideas and work with others helps unite for mutual benefit

Frontend code reviewSide-by-side look at whats been built.Praise and polish together.

[NICK] Frontend code review after the code is written, sit together to walk through the experience, praise and polish together

E2E walkthru sessionsFinishing touches before customers see it.

[NICK] Working sessions to put the finishing touches on the visual and interaction aspects of the experience before it goes to users

What will you do comeMonday morning?

[LAURA]

Pick a few techniques we talked about today that you want to try.

Describe the project or people youll try them with.

What actions will you take and when?

Make your plan of action

[LAURA]

nick tucker@ncktckrlaura faulkner phd@laurafaulkner

Enjoy the session? Wed love your feedback!

#UXPA2016www.uxpa2016.orgSession Survey: www.uxpa2016.org/sessionsurvey?sessionid=344Conference Survey: www.uxpa2016.org/survey