UX handoff deliverables

I was watching an Engineer friend post about a designer who had told their developer to make the font larger. No actual specifications, just larger. If you're a designer, you know the story about the client who wants the logo larger. Make the logo larger has its own song, and a brilliant satire site called make your logo bigger creme. I asked him privately if they used anything like Zeplin or had given the engineers an actual spec doc. The answer was there was a style guide and some "wireframes" but none of that is able to keep up with the actual development.

I've been in UX a long time. Started off as a graphic designer then web designer and Certified Instructor, to doing user interviews and usability testing before we knew what UX was called. Most of my career has been with really amazing developers and some fantastic designers. I even created a conference that ran for 4 years around the concept of how important communication is between designers and developers called D2W, a designer/developer workflow conference. Even as a manager, then Director, working hand-in-hand with engineering has always been a must. It is a new world right now for young designers, let me explain why this is so important to me and why it should be to all designers.

Just as user research and understanding your user is super important to a UX designer, the same goes for the people you work with. Who are your stakeholders and what are their needs and pain points? You might be used to working a bit closer with Product, and if you are a new designer, your Director/Manager might be the one who works closely with engineering leads, but you should get acquainted with the users that work the closest with your actual designs. What needs to be done and what is handed off?

Deliverables for developers

Terminology docs

Let me start with terminology. When I start a new project with a team I'm not used to working with, the first thing I do is create a terminology document. Get input from both sides to create this deliverable that can stop any confusion as to what things mean to both sides like wireframe, prototype, API, defining breakpoints, what a CTA is, and even what design means to each.

Prototypes

Prototypes are an essential deliverable for many reasons. They come in a variety of fidelities and can be a simple paper prototype that allows the designers to work through whether an interaction makes sense or not (to the user) to a full-blown HTML prototype used for high fidelity usability testing.

I already mentioned how important paper prototypes are, so I'll move to how this helps Product and Engineering. This is also where you start bringing in Product and Engineering. This can be as early as the first drawing on paper. Engineering being part of the exercise allows them to note things you might not have thought of like API calls. Too many per page, the slower the page will be for the user. Will there be too many divs to make a design practical and so forth.

They are also is an essential deliverable for Engineering to be able to see how an interaction behaves. Much more impactful for them to see what you are wanting instead of just telling them. How long does something take? Does it move and in which direction? What are the expectations for the users?

Which brings us to usability testing. You can't validate something static unless you want to see if they like a visual design. Usability testing a prototype means it should behave like the pages you intend the users to interact with. The level of interaction could be "do they get it" to testing whether they can accomplish a task. The prototype could then be mostly smoke and mirrors or a hardcore HTML prototype.

I won't go too deeply on tools here, but Figma, Adobe XD, Sketch, InVisionApp all are what I call superficial tools for prototyping. What I mean by that is they don't allow a user to actually do more than click an area, and don't allow for the user to input anything like a sign in or a form. For me, that is a deal-breaker. Fewer applications allow for this like Axure, but with a steep learning curve. Having someone on the team that is a Front End Developer to be able to do HTML prototypes is always handy when possible.

Spec docs and annotated wireframes

Once upon a time, we had to have deliverables like annotated wires, hand off images and a style guide, and perhaps design system elements. Then came along InVision App Inspect, Zeplin, and the like which allows the developer to see the colors used, HTML/CSS, and measurements between items. All of a sudden an annotated wireframe was no longer needed, or are they?

I disagree only because annotated wires also tell the intention of something like a prototype might, but with more information. What happens when a button is clicked? Where does it go? What state should a sort be in by default? What are the expectations of the design?

Spec docs are the same because pixels are really meaningless when something is meant to be fluid or responsive. While a Zeplin file is great, it doesn't tell the story of what the intention for the user is to the developer/Engineer. Just like my story above, the engineer added a comment to the code of :

className {

font-size: larger

}

While really funny, it is not exactly useful and happened only because the designer wasn't specific about what they really wanted. A Zeplin file, an annotated wire, either would have been more helpful.

Other deliverables, but not always to Engineering

Use cases. Always helpful and something more designers should have in their arsenal. It is a written description of how users will perform a task. (I will say task flows, use cases, and user flows sound similar, but they aren't the same)

Storyboards. These are something we old Flash designers used that helped us that isn't done enough. How do you imagine the user using your app? Storyboard it out.

There is a whole list of deliverables before we ever put pen to paper, and I'll save that for another day.

What isn't a deliverable? Wires

For me, wireframes themselves should never be a true deliverable. Of course, both Product and Engineering will consume wireframes, but way too often, if you just hand off a wireframe, they are taken as gospel and someone starts coding to them. Wireframes as part of a spec doc about interactions, or part of a prototype are more appropriate. So why not a deliverable? Because a wireframe is just an assumption until validated by actual users.

There are plenty of times once we test the wires we end up having to pivot the design. Being able to make that pivot is essential. Of course, there have been too many times where Product insists they remain as is, but it is UX's job to validate and thus save money to business by not having to redo a design later by usability testing it early and often.

Always up for a conversation on the subject. Lots of deliverables and of course always depends on the teams and type of products and projects.