Know Your Audience - It's Not Who You Think
If you know me, you know I have a list of TED topics I have not been invited to give but upon which I will pontificate, including but not limited to:
Maine is The Best and You Should Go
Light Rail is Overrated; You Want A Bus
Fourth Wing is Better Than ACOTAR
Audiobooks Are Reading
The User is Not the Audience for UX Deliverables
Wait, what was that last one? You read that right. UX design does not make deliverables for users. We don't deliver directly to users. We deliver directly to engineers. That hit me like a ton of bricks one day and completely shifted how I thought about design in the Agile product lifecycle, how I saw design deliverables, and why I struck the word "handoff" from my vocabulary.
UX can be Agile
I once had an Agile coach tell me that UX didn't have a place in the Agile framework and I immediately made it my mission to prove him wrong. If we're all part of the same team solving the same problem and building the same solution, how can we all be working in different ways? UX can split their work into sprints, but my experience has been that it's a little easier for UX to keep their work in a separate board to avoid impacting burn down rate, and connect to stories or epics. UX should be working one sprint to one quarter ahead, based on the size of the work (and yes, UX can and should be sizing their work).
I made a timeline to share with product and engineering to get buy-in on the cycle of work and where UX plays a role, but also to show why it's so important that product, engineering, and design work together and not in a silo, and why we need engineers in design reviews.
Invite Dev to design
"We're just looking at designs." Said no one ever, I hope. Your team is building a solution together, and each of you carries a piece of expertise. If you don't have that expertise in the room, you could get pretty far down the road without knowing you're missing something, and it costs more time and money to fix the further you get. So let's say you have a design solution and product loves it, and you refine it more, and leadership loves it, and you pull engineering in, and they immediately see a flaw that they can't work around, and you can't design around, and it's back to the drawing board. If they had representation in the first design review, they would have seen that right away and you could have figured out a solution together at the start. Don't wait to get feedback and input from your dev team. When they pull the designs into a sprint, don't let them be a surprise.
Never "hand off"
Waterfall is when work cascades from one area to the next, in a handoff situation. Design does their work and then passes it to dev, never to see it again unless dev comes back and has something that needs fixing. But at that point, design has moved on to something else, so it's frustrating to have to go back and forth on something that was already handed off. Design may not be responsive, and developers may need to make game time design decisions to move the work forward in a timely way. Conceptually it sounds like empowerment, but in reality it creates miscommunication and siloes. It's a lot easier to communicate together from the start, for engineering to be in design reviews from the jump, for a team to have a shared definition of "done" or "ready for dev" so the team knows when to start coding, and for UX and engineering to have a strong relationship so the deliverables are created in a way that's easily consumed by the team that needs them.
Empathy is your superpower
Consider your user: if the engineering team is your audience, what are their pain points? How can you use curiosity and empathy to solve those? What do they need and how might you provide that? Do you both use Figma Dev Mode? Is there a way to share notations in Figma that makes sense to move the work along faster? I worked with a developer who liked to review the designs in a conversation and ask questions as we went - a 30 minute video call saved hours of Jira back and forth. How might you and the devs you work with share information to move design to code efficiently and accurately? (this is absolutely where a design system is critical!) Treat your dev partners like your users, because they are.
UX designers can get caught up in the pixel perfection of what end users need, and lose sight of ensuring that our development partners understand what the design should look and feel like, what happens when there's an error state, or how it presents in mobile. In UX we play a crucial role as the liaison and translator between our customers, product, and engineering, and our design is the story that brings everyone along for the ride. If developers can't follow, we haven't done our jobs.