Rethinking the engineering and processes of interface creation at Arkea

From 2018 to 2020 I joined the Arkea banking group as a UI engineer to help modernize the technical stack and processes. We moved from several intricate SASS codebases to a single library of components, flexible enough to support several designs and 100% WCAG compliant.

As this technical change restricted a very freeform design culture, I volunteered to participate in design meetings to help the designers, marketers and product owners understand how to work with a design system.

This team effort resulted in a sharp decline of interface, accessibility and responsive bugs. It reduced drastically the cost of making, delivering and testing user interfaces.

The client(s)

The Arkea group is a local banking behemot here in Brittany, employing around 5000 persons. The Credit Mutuel de Bretagne (shortened as CMB) is the oldest business of the group, with agencies in almost all cities in the region.

The CMB has a technical banking solution used internally by multiple subsidiaries that all have their specific needs. It also sells its banking solution to external companies, resulting in a very large codebase.

I joined a 6 persons team in charge of developing user interfaces for all subsidiaries and clients and delivering them to other teams in the same service (around 100 people).

The problem(s)

Quite surprisingly, the whole service didn't have a dedicated design team. All product owners were grouped together in a single service, not in the same building, where they wrote specifications and designed their own interfaces by copy pasting and assembling bits of existing interfaces with Microsoft Paint. A single product owner with design tools experience would then translate those specifications into usable interfaces and deliver them to our team.

User interfaces were initially developed in isolation as mockups, using HTML, SASS and native presentational JavaScript. Each subsidiaries or client had its own static "gallery" of mockup templates. Once developed, the code was delivered to teams of Java + JavaScript developers that implemented them into AngularJS applications and "splitted" the CSS code in smaller chunks using a Gulp task (affectionately named Merger3000).

Of course this freeform way of working resulted in a lot of problems during implementation. Bits of existing interfaces would be merged into others. Product owners with no relevant UX or UI experience would sometimes create extremely complex user experiences, or try to differentiate their projects from others by asking for specific design changes like extra colors or font-sizes.

There was no graphical chart or design system. An existing SASS codebase developed by an external company years before acted as a basis. To allow design transgressions, each project parent <div> had a class acting as a namespace. Inside those namespace, the CSS of existing elements was copied then modified for the specific design changes, resulting in an incredible amount of duplicated code for just tiny details.

For the main website, the uncompressed main CSS file weighted around 7 mega bytes.

Duplicate this process by dozens of projects for a dozen subsidiaries and clients, and you realize the amount of code our team was in charge of. This situation made every project extremely expensive and long to deliver. The AngularJS Teams, bothered by the process, would sometimes fix the CSS problems themselves, resulting in a delta between our CSS and theirs. And if we delivered once again our CSS, it would erase theirs, resulting into regression only visible in production.

The put it simply: the design process, the technical stack and the delivery methods needed to change.

The solution(s)

In 2019 our team was asked to reduce its time to market and reduce accessibility issues. Jérémie Le Scoezec, a member of our team, had already identified solutions and proposed the creation of a design system made of Web Components. As they are native to browsers, Web Components can be used in any situation. We could use just one of them in our existing pages, or use them in future stacks (at the time the successor of AngularJS wasn't yet decided between React, Angular and VueJS).

Jérémie and Marc Foletto, another member of the team, joined a task force for several months and started the implementation of our future design system. I took the role of technical adviser of our team, resulting in more contact and dialog with product owners. We decided together to deliver HTML/CSS mockups more close to the final product, so product owners could experience them and give us feedback before the AngularJS Teams took over.

When our design system library started to take shape, I decided we should use it in small projects and see what happens. With the help of Jonathan Perchoc, a senior AngularJS developer from the AngularJS Team, we created a entire insurance subscription course that made it to production, validating the proof of concept.

This new approach created by Jérémie and Marc made our team work incredibly more easy. Accessibility problems could be fixed in a single file and then propagated to all clients. The AngularJS Team didn't have to touch any CSS, resulting in an easier identification of graphical bugs. The delivery tasks using Jenkins took seconds, instead of the 40 minutes needed for our old mockups. If the cost per components was higher than basic HTML and CSS, their reuse progressively reduced the time needed to assemble user interfaces.

After a year the library was mature and the team fully operational and involved in the project, thanks to JavaScript training sessions and meetings. We decided to deprecate our old mockups and only deliver user interfaces made with the library.

However, this technical change was not very appreciated by product owners. They feared this new process, not yet tested at scale, would cost more and delay delivery dates. They also felt disempowered on the design side. The library in itself was not a full design system with constraints, since there was no graphical chart. But it acted as a single source of truth for design elements, it enforced accessibility and good practices, resulting in less freedom.

The design habits that clashed with accessibility and good practices were numerous. First, most pages had a lot of text, some of which were for good reasons (legal, accessibility), and most often for bad reasons (repetition of existing information). Secondly, to avoid surcharging pages, a lot of these texts were either hidden inside modals, or sprinkled in the page. This resulted in strange situations, like paragraphs in the middle of forms, which is not compatible with screen readers ; or text about the usability of a form being located after the form.

Moving all those texts before the forms resulted in extremely verbose pages which made the marketing team unhappy. I volunteered to participate in weekly design meetings with them, to answer questions and find solutions. Most of the time, my role during these meetings was to help question the importance of each element. Do we need to repeat this information so many times? What texts could be read the first time the user visits the page and can be hidden in an accordion on a second visit?

My involvement allowed me to know almost all components in the library and avoid duplicates or propose existing solutions to problems. Working together helped reduce the anxiety and fears of product owners and marketers and streamlined the design, development and delivery process.

Lesson(s) learned

• An old codebase becomes technical debt when collaborating, testing, debugging and delivering become painfull.
• Major technical stacks changes opportunities happen during small windows of time and should not be missed.
• Making big changes is not just about code but also about people, communication and training are as important as clean code.
• Web components are hard, and accessibility is even harder.