Downloaded 13 times
Uploaded byCaroline Sober-James
How to Write UX Specs That Make Developers Swoon
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.
How to Write UX Specs That Make Developers Swoon
- 1. How to WriteUX Specs That Make Developers Swoon Caroline Sober-James @wildwend
- 2. A little aboutme. Passionate about UX for over 12 years Server-side software developer for eight years Currently Lead UX Designer at Acumium
- 3. “The Tale ofthe Warring Contractors”
- 4. We should berocking this. Interdependent, critical roles Both working toward the same end product Both passionate about the work
- 5. So…why are wenot? Collaboration is spotty…or not happening Relationships get antagonistic CYA and finger-pointing Oh hai, underside of the bus…
- 6. How to WriteUX Specs That Make Developers Swoon Caroline Sober-James @wildwend Be a UX Designer Who Makes
- 7. The Official Spectrumof 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.
- 8. Let’s clarify theproblem.
- 9. “They just don’tget it.”
- 10. From the mouthsof 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 wedon’t fix it? Crabby people Increased costs At-risk schedules Reduced quality Extra development cycles Project inefficiencies
- 12. How do youstart? Put your ego on the shelf Swallow your pride Focus on the big picture (the end product, the customers)
- 13.
- 14. Understanding. Communication…and plenty ofit Ask questions Plan and retro Proximity helps
- 15. Ask them forhelp Compromise Stay available Consult with and inform them Trust.
- 16. It follows understanding Findout what you don’t know Know a little about code Empathy.
- 17. Relieve the baggage Ensurethey have what they need Respect.
- 18. Recap: What’s inyour toolkit?
- 19. Questions to ask Whatdo 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 Designthe 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 Providerobust 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
- 22. Design advocate Proactive ally Dedicatedand persistent problem-solver New friend, maybe? Your efforts, rewarded.
- 23. Thank you. Caroline Sober-James LeadUser Experience Designer, Acumium www.acumium.com | blog.acumium.com
Editor's Notes
- #3 Unique position to speak both languages. One foot in both worlds. Have been able to observe some interesting (or troubling) dynamics over the years
- #4 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.”
- #5 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.
- #6 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.
- #7 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.
- #9 Heck if I know. It manifests in different ways. Seems to generally distill down to…
- #10 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.
- #12 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.
- #13 “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
- #15 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
- #16 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)
- #17 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:
- #18 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
- #23 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.