Betsson Group | Design of sportsbook back-office systems

When I came to Betsson, there wasn't a proper design process about how to handle the requests and that led to a bit of inhomogeneous design work, so we worked out the design process to follow:

1. Start documentation (create Wiki page, Figma file with mandatory elements)
2. Schedule (add request to the Design Roadmap)
3. Investigation (check existing functionality, clarification with the PO/Traders)
4. Discovery (use cases, ideas, drafts, prototypes, check existing Design System components)
Iterations:
5. Design Critique with design team members
6. Update design based on DC
7. Discuss design with PO, Traders, Devs
8. Update/finalise design
9. Finalise documentation (Wiki page, Figma file, Design Roadmap)

In 2022 both the existing back-office system, both the new B2B system had different, unique UI design, but both Dev teams decided to start (re)implement their system in Angular web framework. From design and development perspective it was an ideal time to introduce a unified, standard Angular Material based Design System for the two back-office systems. Because development was underway, we decided to build up an atomic system with the already used components as soon as possible, and after that, as new features came into the back-office systems, we added the necessary new components and templates. We didn't take over all Material components with all variants, just the necessary ones and we customised them to our needs.
The existing system had a dark tone, while the predecessor of the new B2B system had a light tone, so we kept this differentiation and created all components in two tones. For keeping components unified and manage them easily, we introduced tokens for the parameters using the Tokens Studio for Figma plugin.

I took over the design of the new B2B Site Manager system from an other designer. The existing design consisted of uncommon components mixed with Material components. After we decided to introduce the new standard back-office Design System, but differentiate the two systems, I got the responsibility to work out the new UI style for the B2B system.
A back-office system is used for long hours on a daily basis, so I wanted to build up a style that was convenient for both the eyes and mind during the long work. It also had to be easy-to-understand, accessible and feasible. So I investigated the DS of Shopify, Booking.com and Emarsys to collect insights and guidelines from their matured systems.
After created many colour and component-style variations we selected the final one with the Design Team members, and validated it with the Product and Dev side as well. Some parts had to be refined during the two-year usage, but the foundation stood the proof and remained unchanged.  

The user requests came from the Product Owners containing the business need, sometimes with user stories, acceptance criteria and sketches. My first task was always to understand the need and investigate the possibilities how it can be aligned to the existing flows. If it was necessary for getting the proper understanding I did process or information architecture modelling in Miro, deepened the user stories and discussed the details with the PO / traders.

We used Figma for creating Lo-Fi wireframes, Hi-Fi designs and building prototypes, every request or feature got an own Figma file. Until having the approved final design, every version had it's single page, while the unique assets, components and templates used only for the request, were collected on an Asset page.
If a component could be used as a common one, we created a sub-task to integrate it into the Design System.

One of our new rules was that a design mustn't be shown to Product or users without validating it first on a Design Critique with Design Team members. After the DC the updated/validated version could be discussed with Product, traders and Development. Having the insights from these sessions we iterated the design until we got the suitable and feasible version for both the business and dev side.

The Sportsbook Design Team had a dedicated part on the company's Wiki system, and every design was documented on an own Wiki page, which contained the participants (from Product, Design, Dev), links to the specification, the main decisions regarding the design, use cases, links to the final Figma screens and prototypes. Creating and updating this page was the responsibility of the designer of the request.