Egeria
ERP software used by hospitals, city halls and universities. I’m the lead designer in the project.
About the project
Egeria is an ERP software for public institutions, like hospitals, city halls or universities. It’s a web application created to help with managing countless business processes – from accounting and finance to HR, logistics or sales. The product is currently in its R&D stage, we’re set to release the MVP version to first clients in 2025.
It’s by far the biggest project I’ve been in. We have a team of +100 people (managers, developers, business analysts, testers and designers) all working in Scrum.
I’m the UX Lead of my awesome Design Team (7 UX designers, 1 UI designer).
My main responsibilities
Designing mockups
I create mockups in the logistics and sales area (invoices, inventory, cargo, that sort of thing).
Writing documentation
I’ve created the ever-expanding documentaion of our rules & custom components and described their usage for designers, devs, PMs, analysts and testers.
Preparing usability tests
I prepare the scenarios for our research team, I carry out some myself and I mostly convince our PMs that usability tests are actually necessary…
Supervising my team's designs
I make sure our designs are consistent and that everybody’s following the guidelines we’ve created.
Optimizing our workflows
I try to improve our design processes, so that the annoying parts are reduced to the minimum and we can focus on communication and designing.
Making sure we’re accessible
I’m teaching accessibility to everybody else in the project, I’m making sure our designs are accessible and I’m creating a11y guidelines for the developers.
The design part
Unfortunately I can’t show much of the actual designs here. The product is currently being developed and I’m not allowed to share it outside the company. (NDAs and such…).
Sorry for the lack of pretty UI to look at, but this particular project is more interesting for other reasons! So if you would like to see how I operate at work, on a real project, keep reading 📖
UX Design in a 100+ people project
How we do it
1 product, 8 designers
Have you heard the expression “too many cooks spoil the broth”? Well, turns out that if 8 people are designing the same product, the only thing that’s consistent across the mockups is the logo in the corner…
That was a first to me. Until this project I was used to working alone or with one other designer. Suddenly I had to oversee mockups from 8 people in 6 scrum teams. Each of us were creating mockups in different areas, for different ‘apps’ as we call them – we’ve drawn the availability calendar for HR, an invoice-creating form for Sales, huge settlement tables for Finance, diagram trees for Logistics… And it all had to be consistent. Consistent design. Consistent language. Consistant mechanics.
I’m not gonna lie, it wasn’t perfect at first, but we’ve come a long way!
Design system
An obvious solution to the problem seems to be a design system – our company has one, so of course we use it. But it wasn’t enough. The basic components like inputs, dropdowns and buttons were a start, but we needed more weird stuff for our designs. Custom inputs and tiles, enterprise level tables, toggle sections, interactive diagrams… All of which had to be created and then used across apps with consistent design and behaviour.
That’s why I insisted on creating our own design system for this project, on top of the main company DS. And we did! We’ve made a (still growing) list of our custom components, with detailed descriptions for developers, analysts and testers.
Making a design system, creating new components, working out their behaviours, consulting it with analysts and product managers, so that everybody’s happy with the results, was a very interesting challenge for sure.
Goodbye
Sketch!
Welcome
Figma!
About a year into the project, our company decided to switch from Sketch to Figma. I was happy with the decision, because I love Figma with all my heart, but we already had a whole design workflow with Sketch, Zeplin and Confluence so that designers, analysts, developers and managers can all work together on the mockups. We already had about 5000 mockups made by that time.
I was in charge of moving the whole project from Sketch to Figma, which was an adventure. We made a new project design system library in Figma from scratch, with Figma components and autolayouts and updated the wiki documentation. We migrated all the mockups created in Sketch to Figma. We created a huge wiki page with the whole system’s structure and Figma links. I made a new design workflow using Figma’s branches, to optimize our business → UX → UI flow. I wrote an extensive Figma instrution page and I’ve made a webinar Figma training session for the +100 of people in the project.
It was quite a bit of work, but I’m happy to say we didn’t screw up anywhere on the way and the whole transition was pretty smooth sailing! We are now enjoying the beautiful lands of Figma and working about twice as fast thanks to our new shiny design system.
I love you Figma, muah
The templates
The next step in the pursuit of consistency, was to create templates – generic mockups for pages inside the system that are similar or repetitive.
The idea behind it is very similar to the point of design systems. We made the templates so that our pages are coherent, look and work the same way. So the users don’t have to retrain their mental models all the time and can get their tasks done quicker. And so our design processes are easier and faster of course.
Now the base structure for our page types – our forms, tables, detail-pages, raports and so on – all look similar and they’re much faster to design and implement.
Tables, tables, tables
As you can probably imagine, a software for managing an organisation, all its resources and processes means... tables. Lots. Of tables.
And those tables should be usable for everybody - for the oracle loving Steve the IT administrator and for Greg the temp, still learning the intricacies of MS Office.
Tables are probably the most important part of an ERP software design. In our product we often have to convey a metric ton of information in one table, in a readable manner, which is no easy task.
I talked to our PMs and insisted on taking the time to design a table component that will be functional, easy to use and chock-full of cool features, for every type of user and for our every business need.
And… they agreed!
So I’ve read all I could find on the Internet about table design - articles, case studies, do’s and dont’s, failure stories, user research. I didn’t want to reinvent the wheel and/or to repeat the same mistakes.
By the way, shoutout to the Pencil & Paper Design Company. They have a stunning blog full of great articles. The one about designing enterprise tables was endlessly helpful.
I also wanted the component to be
as easy as possible for front-end developers to use in the future.
I wanted to say what type of table
I wanted and for the table to magically build itself, with almost no code necessary.
It took a good while. First to design, then to convince the Project Owner that it’s worth it, and then to code it, so that creating any table in the future would be a piece of cake.
And… we did it! I’m pretty proud of it.
Our Table component
Table features
And probably the most important feature from a project standpoint: it builds itself 🪄
All you have to do is put in the number of columns, their type and their name - and your table is ready.
It speeds up the implementation of tables and assures UI-coherence among tables.
#weirdflex
My company hosted a “Share the code” contest to find the best components across all teams in the firm. Our component won first place! Out of several dozen submissions as well.
Because of that, I won a week long trip to USA 🇺🇸 surreal
I knew my lifelong table obsession would pay off someday
okay sorry, flex over
1st prize winner component! 🏆
To sum up
This project was (and still is) a great opportunity to develop a weirdly broad range of skills – from designing mockups to managing people, crisis handling and being creative in the constraints of quarterly plans, efficiency charts and legally binding deadlines…
It’s my first time leading such a big team and first time in a project of this size. It’s quite a responsibility, but it comes with a significant creative freedom too. My ideas are being heard and implemented, my suggestions taken into consideration.
Most importantly though, I’m pretty happy with this product we’re all doing. It’ll be used everyday by people in hospitals, universities, city halls - by people that are used to working on systems looking like Windows 95 with boeing 737 controls.
I’m happy that they’ll work on a system that was designed with the user in mind - a system created to be functional and easy to use.
This type of product is always way more satisfying to me than making an e-commerce cart that’s converting well, you know?