UX (Not) Lost In Translation

Aleksandra Pyta at UXDX Community: Dublin. Video: https://youtu.be/HiyyRG5VeR0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why the design handover matters

[00:00:00] Aleksandra: I'm a project manager. I've been managing projects for four years now, and the last year at Netguru. I've managed multiple design projects, and recently I'm supporting one of our clients in product management. So I write a lot of user stories, acceptance criteria, requirements. I spend a lot of time talking with developers about how to implement certain features. So I can see firsthand how you can lose things when you try to explain to someone your idea behind a feature.

[00:00:51] So why should we even talk about it? First things first, you have a designer who spends a lot of time preparing the best user experience, fighting with the usability issues. And then it would be not wise to lose this whole work when you implement it as a working application, and this whole user experience is not there because of some misunderstandings. And of course, at the end of the development process, you can have two or three weeks for design review and improvements, etc. But this is additional money, additional time. And good luck explaining to the client why it wasn't done correctly the first time.

[00:01:39] So what exactly will we talk about? Because this is a broad topic and I'd like to narrow it down a bit. We have a recommended design handover process: a handover process of the design to the client and to the development team. And there's a disclaimer here: there's no perfect process which works in every organization. You have to pick the elements from what I'm showing here and try to apply them to your organization. Because, as I said, it might work for us, and it's a recommended process, and still we adapt it to every project, every situation, every client that we have.

[00:02:22] I'll also be focusing on one specific type of design assignment. We have two main types. One is when you have the design and then the development and delivery. So you have the design, you finish it, hand it over to the developers, and they deliver it. But there's also the second type, where you have continuous design. The designer is there for the developers all the time, to support them and to check if the design was implemented in the right way. This is a bit different, and I won't cover that. We'll be focusing only on the process where you have the design, it's done, the designers hand over the design to developers, and they carry on from there.

Empathy for developers and clients

[00:03:07] Okay, so what is the key to a successful handover? I think that it is empathy, and I know that this word gets used a lot, especially when it comes to design. But in this case we have to remember to treat the developers and the client as users. We put so much effort into understanding users, what they need or what their problems are. Why don't we put at least part of this effort into understanding what the developer's problem is? What is the client's problem? What do they need to understand when you hand over your design? And as I wrote here: design for users, but document for the client and for developers.

[00:03:51] I said that we have a recommended process. You can divide it into three parts. The first one is preparation, then deliverables, and the moment where you hand over all the chief cooper [?].

Preparation

[00:04:09] So let's dig deeper into preparation. Here are five tips on how to include the handover preparation in your design process already. First, you have to have time for that, so include it in your estimation. When we start a project at Netguru and it's estimated, we always schedule at least one day to have the time for doing the exports, for scheduling the calls with the developers, with the client. Of course, again, it depends on the project. If you have a one-week project, one day for handover is probably a bit too much. But if it's a three-month design project with three designers, you might think about additional time beyond this one day.

[00:04:52] Second thing: including the developers in the design process. This is what you've covered, right? The sooner we include them, the sooner we know if some things are hard to implement, or even impossible to implement, within the time and the budget.

[00:05:07] The next thing is my favorite, I think: check if you've designed everything. We all know those screens that always come up at the end of the development process, and you create them in panic mode, or try to figure out how to show the error page, what the flash messages should look like, or what we should do with the empty state, already mentioned today.

[00:05:31] And the fourth thing: scheduling a UX review and a UI review. This is something that we do at Netguru. We ask one of the designers to come from outside of the project, take a look at the design and give feedback. And the last thing is: who said that you have to do a bug bash only for the features? You could do that for the design. So that's what we do. We invite a couple of QAs, a couple of designers, and try to break the interactive prototype, usually in InVision.

[00:06:09] That's about preparation. That's what you can do to lower the risk of losing this information, of having a design that's not consistent, and of causing miscommunication between the designers and the developers.

Deliverables: structure

[00:06:24] Then, when you have all that cleared up, you need to prepare the deliverables. Here we'll be talking about three things: the structure, the tools and the checklist. And here I'll dig deeper into the details of how we do it at Netguru.

[00:06:43] Starting with structure. I really hope I don't have to mention the first one: the organization of files and the naming. This is the most important thing. So you have a set structure in your company for how those folders should look and what the naming convention is. You cannot have four screens called "landing page" with different version numbers. The developers have to get the one final version, with a name that explains what is on this screen. And especially in an organization like ours, when you do a lot of projects with different clients, with different teams, it's important to have this structure already decided on and implemented in all the projects. On the right-hand side you can see an example of our structure.

[00:07:33] Then the functional description. Here I mean the document that describes in more detail what this product is about. What are the edge cases? What are the main features? Ideally with some images. So six weeks after the handover, the developer can go back to this document and for sure find answers to at least part of their questions.

[00:08:00] Good practice is also adding a list of unknowns. If we know that something is not very clear, something was not designed, and we are afraid that it might influence the development process, just put it there. It's information for the developer, so they can make a better estimation, and it's information for the project manager, who can then manage it better.

[00:08:24] And of course the last thing, and it would be perfect to have it in every project, but we don't always have the time and the budget: a design system. We don't have that much experience with that yet, but I can tell you that we are working with UXPin to improve ourselves in that process, and I'm sure you'll see the results soon too.

Deliverables: tools and checklists

[00:08:50] Okay, so we have the structure. What about the tools? We all should aim at automating ourselves out of the work: try to automate as much as we can, to have time for the more creative things. So use the right tools, select the right tools for your project. Right now at Netguru we are using Sketch Measure and InVision Design Studio [?]. If you choose the right tool for your project, you can shorten the time that you need to prepare those deliverables. You can do it with a few clicks, not spending the whole afternoon exporting asset by asset.

[00:09:32] Here you can see examples. This is a sample taken from one of our projects. On the right-hand side you can see all the parameters already in the tool, which the developer can check without asking the designer. They are just there, available with a few clicks.

[00:09:56] And checklists. We love checklists. At Netguru we have checklists for almost everything. This checklist, of course, lists the things that have to be done in order for you to have a successful handover. This is a one-time effort that you have to make at the beginning, that you have to prepare, and then with every project you can iterate on it, add more and more. The more complete it is, the better for you and for your team. You create efficiency. You just copy the template, cross the items out one by one, and you're done with the handover.

The design workflow system

[00:10:33] What we have is a design workflow system. This is an example from our files. In those rows you can see projects. Every project has a lead designer, and every project also has a reviewer. There you can also see the progress, whether the review was completed or not, and some statistics at the top. We all like statistics.

[00:11:02] So what is it? It's a process that allows us to keep high quality in the design projects. We have a design buddy, a designer outside the project, who checks the project against some agreed topics. Here you can see the example of a single project, with examples of what is checked. For example, is the project structure on Google Drive created? We try to have the same kind of structure and the same quality in every project. Of course you have to be wise about it, because, again, this will not work in all projects, but in the majority it will.

[00:11:51] And of course, this is not just a spreadsheet. There is a whole science behind it: the recommendations from more experienced designers, from designers who have worked for a longer time. So this is a document that we have that can be shared with the designers, and it improves our onboarding process. But it also helps the designers who work at Netguru and are a bit in their own flow. They have it all figured out, but it's not always the most optimal way to go about things. So we have the design process book, and I can already tell you that soon we want to share it with the world. So if you find it on Product Hunt and leave your email, you can be the first one to see it.

Handing over to developers and the product owner

[00:12:43] Okay. So we did the preparations. We have all the deliverables. They are all structured, all described. What now? We have to take it all and hand it over to someone else. And I think that there should be a separate handover to the development team and to the product owner. At Netguru, the product owner is the client, and the client is the product owner, so I mixed those two here in this presentation.

[00:13:15] So here I come back to empathy. Because there should be a different approach to the handover with the development team, and a different approach to the handover with the client. Developers think in terms of components. They are focused on edge cases, changes of state, interactions. They want to understand fully how it works, and they will ask questions related to that. But the truth is that if you just tell them about the components, this is not all that they should know. They should understand the idea behind it. They should understand what kind of problems we're solving. They should also know how the user thinks.

[00:14:03] Because then, in the development process, when the designer is not in place and there's a problem that has to be solved, something that was not designed, if you have a smart developer, a good style guide and some sketching skills, you can solve that without the designer. So it is very important to make a point of explaining to the developers during the handover call what this product is really about, and where they can find the elements, the building blocks that allow them to make better decisions even when the designer is not there.

[00:14:41] And of course, there's the call with the product owner, or the client. The client thinks in terms of the problems that this product solves. They're more focused on the flow of the application, whether the user will be satisfied, whether the experience will be great. But the product owner or the client, because in our company, when we work with clients, we call them product owners, doesn't always have the knowledge and the skills to be a product owner. We have to educate them.

[00:15:11] So here you have to help them understand the design decisions that were made, and why we designed this the way we did. Then, in the development process, they can support the developers. If a developer comes with a problem, "I don't know how to do this, because it's not in the designs," then the product owner can explain: "Well, the decision was to do it this way, so we'll continue here in the same way." That way we don't implement changes that don't come from business needs. The changes I'm talking about cannot come from missing knowledge, lost knowledge from when you were handing over the design.

Pain points and best practices from the team

[00:15:58] Okay, so that's the summary. We have the preparation, the deliverables and the moment of handing over. But I have a bonus for you. I did a short survey, it was today, with our team, to identify the biggest pain points and best practices in handing over the design. We looked at it from the perspective of a designer, a developer and a project manager.

[00:16:26] When it comes to designers: how to show the interaction, how to show and explain how this product should work, and how to make sure that the developers will keep that knowledge and use it in the development process. The solution: animated GIFs. This is a bit more work for the designer, but I think that it's still worth it. Or simply do a proper handover and record it. Record it, and then any other developer who joins the project can use it. Or developers who are already in the project, but five or six weeks after the handover have forgotten all that stuff, can get back to it.

[00:17:16] Then we have the perspective of a developer: painful inconsistencies in the design. If you have a front-end developer in your project who's a perfectionist, that's a pain. I tell you from experience, I have a project like that, not right now, with a front-end developer who is a perfectionist. There's a problem because I'm creating a component, as a developer, and I look at the design, I look at the first page and the fifth page, and they look different. And the difference is usually, I don't know, the color of the border, but they are all gray. So which one should I implement? The solution for that: review, review, review, review, review. Ask people for help, do bug bashes, do UX and UI reviews, ask for peer review, because after looking at the same pages for three weeks it can be difficult to spot those inconsistencies.

[00:18:16] And from my perspective, as a project manager: missing assets. You have a ticket in Jira, well described. You have a link to the design, you have a developer who can pick it up, you have a client who is excited and wants to see this view in the product, but then it turns out that you're missing two assets, and the developer cannot finish his work, and the designer is on vacation. So it's a big problem for all of us, especially from the project manager's perspective. The solution: create a checklist, follow it, and use the right tools. Use the tools that allow you to minimize human error, the problems that come from "well, I forgot about that, I forgot about this." Just try to automate yourself out of this part of the work.

[00:19:11] Thank you. Do you have questions?