Handing off designs

With accessibility annotations

Design frames breakdown by content type

A UX designer doesn't just focus on how people experience your website. They can also help with your internal process, such as design handoffs.

When I joined MAIF (a French insurance company), I wanted to integrate accessibility to our design process. But I didn't start from scratch. The UI lead already had a solution to organise Figma pages. There were also several pairs of UX and UI designers who had been working well together for years. I didn't need to review their process but I could learn from them. And that would help my team where the process wasn't clear.

The project was a good opportunity for integrating accessibility annotations. I needed to work on helping people finding them, reporting them and using them. It's also how I got to understand the dynamics of a large company with countless stakeholders.

Design pages breakdown

In Figma, I organise UI frames depending on the content type. There are forms (desktop and mobile), information pop-ins, error messages and documentation. This breakdown helps people navigating the file. Whether that be to write specs, user stories, or code, and to test what's been developed.

I always start with a typical user journey, where the person holding the insurance policy is also the driver of the vehicle.


At MAIF, I design subscription forms for the vehicle insurance products. I work in collaboration with a UI designer and we split up frames by step. For each step, we mock up the design in both desktop and mobile versions. And for each of these, I provide alt-text annotations. Depending on the context, a same image may have different alt-texts. It can also be decorative in one instance and descriptive in another. "So, the alt-text needs to be specified for each instance, even if the image appears several times on the same page.

For each step, we specify the number and status. There’s a desktop and mobile version as well as alt-text annotations for each image.

It's important to mark each individual frame as signed off or not. Once signed off, PMs and engineers can start writing specs and user stories. This doesn't replace regular communication within the team. But it can be helpful, especially if you have people from other teams looking at your file. That's also why the files include a "UX draft" page followed by a "UI mockup" page. It helps me explore various ideas before committing to one version.

Information pop-ins

Insurance jargon is difficult to understand. So we provide information within the subscription forms to reassure people. The information is displayed on demand, via a pop-in system that we mock up alongside the forms.

For each step, we design the pop-in frame and its question, as well as the corresponding aria label.

In some of the steps, we can have up to six different questions. So that means we can also have up to six information pop-ins. To keep the page clear, I group the information pop-ins in a dedicated section under forms.

This is where I annotate aria labels for each information icon. These icons serve as a link to open pop-ins, which is why we provide an aria label rather than an alt-text. Example:

"What type of coverage do you want ℹ️? Third party or comprehensive.

The aria label on the information icon would be "what is the difference between third party and comprehensive coverage?" Thanks to the aria label, a screen reader user won't need to open the pop-in if they already know the difference. But if they need information, they can check the information pop-in.

Error messages

The same error messages can appear at various steps of the form. These are cases where the user may need to contact support to finalise their subscription. We organise these error messages in a separate category. They go below the form mockups and information pop-ins.

Error messages


The responsibilities of a UX designer may vary depending on the company you work for. The methodology may be similar, but processes change. At MAIF, the mockups I design result from a close collaboration with many departments. That includes communication, marketing, legal, SEO, design system... Sometimes, we also learn things from user research or AB testing. We also need to consider accessibility, GDPR, and each project has a set budget and deadline. So my job is to assemble design based on business inputs and technical constraints of the moment, while meeting user needs.

It's important to keep track of these arguments, constraints, and needs. When projects span over a long period of time, documentation is essential. It prevents us from challenging the same things over and over again. It also helps us to revisit past solutions when the context evolves.

So I document everything about a project in a final section below all the others. Adding this to Figma helps the product team understand what we are working with immediately. It's also useful in design reviews when we need to justify our choices.

If necessary, I can also export the documentation for colleagues who don't know Figma. Because even though the process is now clear, it takes a bit of time to get used to it in the first place.

Documentation slides : project, constraints, inputs, ux proposal

Specific use cases

While I always start with a typical user journey (e.g., policyholder is the driver), I also need design other use cases.

And for a vehicle insurance subscription, there can be a lot of them. Such as the policyholder who wants a quote for their spouse or child being the driver. It could also be someone who has previously obtained quotes but has never subscribed. Or a young driver whose both parents are policyholders but with different client accounts. So many variations that impact the way we collect and retrieve data. It's important to keep track of them, so that everyone's journey remains consistent.

So I make a list of these use cases below the typical user journey, and I only mock up the screen that changes. It keeps the maintenance of those design mockups to a minimum and helps us reduce files' weight.

Specific use cases, where you only add the frames that change

Other accessibility annotations

Accessibility annotations don't just include alt-text and aria labels. There's also focus order, heading levels, HTML tags... But at MAIF, most of this information is associated to the components we use. So there's not a lot for UX designers to specify. This industrialisation of our components reduces the time we spend in design and ensures consistency. But if you need those annotations, I recommend the A11y annotation kit. You can also use my Figma template (in French) to organise your designs and handoffs easily.

Publication date

April 2024

More articles