The document provides guidance on how UX designers can improve collaboration with developers by understanding their perspectives, communicating effectively, and ensuring specifications provide the necessary details. It emphasizes understanding developers' technical constraints, trusting their expertise, showing empathy for their challenges, and respecting their accountability for the overall system. The document suggests UX designers ask questions to deepen understanding, compromise on solutions, and consult developers to help produce the best outcome for users.
4. We should be rocking this.
Interdependent, critical roles
Both working toward the same end product
Both passionate about the work
5. So…why are we not?
Collaboration is spotty…or not happening
Relationships get antagonistic
CYA and finger-pointing
Oh hai, underside of the bus…
6. How to Write UX Specs
That Make Developers
Swoon
Caroline Sober-James
@wildwend
Be a UX Designer Who Makes
7. The Official Spectrum of
Designer/Developer Synergistic
Nirvana.
Can’t stand the
sight of their
stupid dumb face
Fist bumps over
pizza and beer!
This is good.
We want this.
Let’s move further this way.
10. From the mouths of developers…
“Designers don’t understand the complexities that developers run into.” - Nate
“I find…designers fail to take into account interactions with different UI elements.” -
James
“For me, it’s keywords I see in requirements. Things like ‘better,’ ‘faster,’ ‘more
efficient,’ and ‘easier to use’ are red flags it’s not baked enough.” - Justin
“…Think about all the possible cases and either design them or describe the minor
changes to accommodate them.” - Dan
“Exceptions need to be considered. Error states are a common example.” – Aaron
“…Just understanding that there are multiple ways to do things and being open to
discussing those options is always helpful. ‘Just do it’ may work for Nike but not for
devs.” – Scott
11. What if we don’t fix it?
Crabby people
Increased costs
At-risk schedules
Reduced quality
Extra development cycles
Project inefficiencies
12. How do you start?
Put your ego on the shelf
Swallow your pride
Focus on the big picture
(the end product, the customers)
19. Questions to ask
What do you wish I knew about what you do?
What do you need from me to be successful?
What could I do tomorrow to help us work better together?
What worked well with what I provided you? What didn’t?
What are pain points you have you think I could help with?
What was the most effective thing I did to help you be
successful on that project?
What do you want me to keep doing?
20. Things to remember
Design the user experience you want the devs to have working with you
Developers care just as much about their code as you do about your design
Their “love language” is tons of detail
Neither of your jobs are harder; they’re just hard in different ways
They’re trying to produce the best possible outcome, too
They are responsible and accountable for the entire
system, of which the application of your design is just one part
Being brought in late to projects on an ongoing basis
would irritate the crap out of you, too
21. Things to do
Provide robust detail in your specs
Stay available, either in communication or proximity (or both)
Talk to your developer before the project about what they need
Talk to them after the project about how well you provided what they
needed, and what you could do better next time
Ask them to do a sanity check on your work, ideally before the client even
sees it
Be prepared to compromise, and defer to their technical judgment
Ask them for help. Even if you don’t implement their suggested solution, the
ask is impactful
Unique position to speak both languages. One foot in both worlds.
Have been able to observe some interesting (or troubling) dynamics over the years
Approaching from wildly different points of view
Priorities not aligned
Not talking to each other
Relationship has developed adversarial tone
#1 just routed a pipe through the middle of your home theater room. #2 hadn’t allowed for it, hadn’t said where it should go, and wouldn’t respond to calls or emails.
Nervous about your house?
Imagine house is web dev project – contractors are devs and designers.
Shared story with coworker, he said, “I need to send this to a bunch of people at my old job.”
Without designers, end product at risk of poor usability and flow, misalignment to brand, being off-message, being fugly
Without devs, end product just doesn’t get built. It stagnates as a collection of really promising and pretty, but static and basically worthless, ideas.
Realized I’d named this preso incorrectly.
Submitted the pitch when we were working through some challenges at Acumium relating to specs coming down to developers
We have made some changes in how we do specs, but the more significant changes have been based on relationships.
So, I fixed this.
Disclaimer: there are some really great designer/developer relationships; I’ve been part of some, myself.
This talk isn’t primarily for you – this is for the people who are struggling.
Heck if I know.
It manifests in different ways.
Seems to generally distill down to…
Devs are:
Petulant and difficult to work with
Uncooperative
Make (wrong) assumptions
Don’t care
Lazy
Don’t respect my design
Designers are:
Top three above
Rigid and unrealistic
Have no idea what it takes to actually accomplish any of what they’re asking
Throw half-baked stuff over the wall and expect that I’ll be able to implement it
Congratulations! Everyone’s a jerk! Let’s unplug the Internet and go home.
If you’re in an agency situation, these things can lead to loss of business.
If people are unhappy enough, they leave, and take any institutional knowledge they have with them.
“Why do I have to do all the work?” Maybe you don’t – you just have to start it.
I could give this same talk to a theater full of developers, with just a slightly different angle. Someone just has to start the conversation.
“Faith is taking the first step even when you don’t see the whole staircase.” – MLK, Jr.
Olive branch – “Peace begins with a smile.” – Mother Teresa
Acumium core value: Seek first to understand and then be understood
Challenge: think of your developers as one of your target audiences.
What if your devs were your target audience, and the user experience you were designing was the experience they were going to have working with you through a project?
What’s something UX people are really good at? Questions.
Story about Nick when I first joined Acumium
Plan: At the beginning of a project, ask what they need to be successful.
Retro (like Agile): After a project, ask them whether what you did was effective. If not, how could it be more so next time?
Stay in proximity and close communication – I sit embedded with the devs at Acumium
Consult: have a dev do a “sanity check” on your work before the client sees it, or at least make the offer: “Do you want to review these personas?”
Availability: In standups, “Let me know if you need anything from me”
Compromise:
Always more than one way to solve a UX problem
Say, “If you’re telling me this can’t be done, I trust you.”
Ask what options are
Don’t be surprised if, shortly thereafter, they find a solution.
Implement an alternative
Acknowledge you don’t know everything.
Great ideas come from everywhere
Ask them to help you brainstorm a UX problem (I’ve gotten great ideas from devs)
Empathy is “the ability to understand and share the feelings of another.”
Comes on the heels of understanding
Ask them,
“What do you wish I knew about what you do?
“What could I do tomorrow that would make working with me easier?”
Understand some fundamentals about code; know the basic vocabulary:
Ensure they have what they need – use your conversations with them to draw this out:
User stories with acceptance criteria
Annotated wireframes
Address the exceptions (clients never ask for concepts that include a form in full-on failed validation)
Style/pattern guides (e.g. where do validators go? What color are they?)
Matrices of field types, labels, default text, help text, error messages, etc.
Inherent throwaway quality of UX deliverables – communication and proximity can take place of this detail
Acknowledge and relieve the “developer baggage”
Think about where development occurs in the web development process
Devs brought into process late
No opportunity to add value
Stuff “thrown over the wall”
Raise concerns, and you’re told the project’s too far along
Add insult to injury, you’re told just to make it work, which introduces technical debt
No greater advocate for seeing your design come to life than a dev who is 100% on your side. Will put in WORK to see it happen
No more proactive ally for you than a dev who feels respected
A lot of devs eat, sleep and breathe code. If they think you’re in their pack, they’ll think about how to accommodate your design when they’re driving home, eating dinner, falling asleep, getting ready in the morning.
Story about coding in my sleep and getting pissed when I couldn’t check it in.
There is way more commonality between design and development than we often acknowledge. Both are intensely creative pursuits, with (we hope) intensely passionate practitioners.
Design is thoughtful, uses patterns and looks for reuse and building off what you know works, elegance and efficiency, simplicity and beauty. You could say the same thing about development
Development is creative and lyrical, geared toward the solving of problems, finding ways to innovate and introduce delight where you can. You could say the same thing about development.
We aren’t different.