Mariana Manrique

Livsmedelsverket

The Project

Livsmedelsverket is the state management authority for food issues with the task of working actively in consumer interests for safe food, fairness in food handling, good food habits, and legislation on food. All the information for consumers can be found in their website. The aim of this project was to both update the UI and make sure that the website is accessible for every user. With the web accessibility laws coming in effect on June 2025, Livsmedelsverket like many companies and authorities, have spent resources into making sure that their websites comply with the Web Content Accessibility Guidelines (WCAG).

"We want to have our website evaluated, get UI improvements and suggestions to comply with the WCAG."

- Livsmedelsverket's web project owners.

The Users

Are both private and corporate. Private users ate mostly concerned about safe food, food handling, good food habits, and food recalls. The corporate users go in the website to learn, and know how to comply with food legislations.

The Product

In Livsmedelsverket’s website, guidance to the legislation on food, and food control can be found. The rules that apply and what they mean, and read about how food control works. Advice on food consumption, food handling and recalls can also be found. As such the website contains articles, advice columns, product recall lists, divided in different categories and subcategories.

image of the old website, it shows different sections. From top to bottom: banner, a grid with links to different articles, a recall list, and news listed with title and a brief paragraph.
  • The design when I was introduced to the project.

The Team

Illustration depicting two characters.
  • Two Project owners
Illustration depicting one character.
  • One Project manager
Illustration depicting one character.
  • One Tech lead
Illustration depicting one character.
  • One Fullstack developer
Illustration depicting one character.
  • One UI/UX designer (Me)

The Process

The project started with a meeting with the project manager and the tech lead where they explained the context and what had been done so far in the project. After I had a meeting with the project owners. They explained that their objective was to comply with WACG and update the UI. They shared a sketch to show what they had in mind for the start page. I used it as an inspiration, and to understand what new features they wanted to offer.

image of the top part of the start page sketch. Includes the top navigation, header and 3 teasers.
  • Sketch of the start page given by POs section 1.
image of the second part of the start page sketch. It's the news section. The layout is two columns, left column is a list with the title and paragraph for each article; on the right there are bubbles to filter by category.
  • Sketch of the start page given by POs section 2.
image of the third part of the start page sketch. It has 4 columns and two rows of teasers. The top row the teasers are tiles with an image and text underneath. The bottom row has a solid background and text.
  • Sketch of the start page given by POs section 3.

Besides the start page, some changes had to be made to the navigation and to the content pages. The content pages needed changes to the line length. The spacing and size of the font were a global change.

The navigation got a cleaner look and the secondary colours were used more often, for example to bring contrast to blocks of text so the scanning of information would be easier and faster.

image of a content page with annotations about the contrast changes.
  • Content page example for big screen.
Image of content page in small screen format.
  • Content page example for small screen.
Image of menu in a small screen format.
  • Menu in small screen, when a content page is active.

Some other elements were also considered and given suggestions for improving, such as the tables. The tables are often used in the website. I created some alternatives on how to improve their readability and usefulness. There were two main alternatives. The first one, was to add colour for contrast between rows. However keeping the tables as they were came with challenges for small screens. I designed a table that used tabs, so the user would be aware of all the columns at a glance and could change between what they considered the relevant content faster. The second alternative, was to reconsider the use of tables for all the display of data. Specially when the information in the rows wasn't related. For these cases I designed cards to be used instead of tables.

image of the table that would be seen in a big screen. Every other line is turquoise.
  • Visualisation of data in the table for big screens.
image of the cards that would be seen in a big screen. The background is a solid colour, and the cards are collapsable.
  • Visualisation of data in cards for big screens.
Image of the table in a small screen, it uses tabs to switch and inform the user of more content.
  • Visualisation of data in the table for small screens.
Image of the cards suggestion in a small screen. The cards have a solid colour as a background and are collapsable.
  • Visualisation of data in the table for small screens.

I had weekly meetings with the PO’s so there was constant iteration until only one alternative was left. Once the designs for the different sections were approved I would deliver it to the full stack developer through a meeting and Figma specifications. Who would then implement and sometimes come back to me when questions or concerns arose.

image of the third part of the start page sketch. It has 4 columns and two rows of teasers. The top row the teasers are tiles with an image and text underneath. The bottom row has a solid background and text.
  • Start page of the website for big screens.
Image of website in a small screen, showing one of the big teasers.
  • Start page for small screens, showing one big teaser.
Image of the website in a small screen, showing the news section.
  • Start page for small screens, showing the news section.

Lessons Learned

Writing more to save time

I believe the number of meetings during implementation could have been reduced if the designs had more annotations. Specially regarding the decisions directly related to WCAG. So, be more explicit with my annotations within the design and use them to stress the importance of the design decisions made.