Jordy vd Boom

From tiny cool concepts, to scalable design system

With the message ‘Welcome to the new world’ Eneco is transforming from an energy supplier that supplies electricity and gas to Dutch households to a sustainable service provider. I had a leading role in the creation of the concept, design and design system of Eneco.nl. Based on interviews, research and data, I worked closely with people from Eneco to renew the highly outdated Eneco website & app.

Challenge

How can I transform a written strategy to a sustainable design language? Can I find a way to keep consistency across different teams, with multiple designers and developers?

Outcome

A sustainable design language that not only reflect Eneco's design principles, but is also sustainable and ready to scale with its design system.

From strategy to design principles

The strategy was to make green energy attractive. Making this visible to different consumers in The Netherlands is a super cool challenge. In a small workshop with a few designers and stakeholders we came up with micro-concepts and visuals to define how this new strategy should feel like. With the same group we translated these concepts into so called design principles. These guiding principles were (and still are) the foundation of all the digital platforms. We made everything visual in a poster to inspire other designers, developers and stakeholders. We welcomed them in the new world.

Design Principles - Poster to having guiding rules in making features that match the strategy

From design principles to design

Translating tiny cool concepts to a sustainable design sounds like a huge thing, but is pretty easy. The trick is to don't push them into your design, but implement them when the right opportunity is there.

Tiny cool concept for a Wizard

Tiny cool concept for a Deepdive

Tiny cool concept for a Product carousel

Plot twist

The right opportunity won't come by just waiting, at least that's what I've learned. With 850K monthly users, having 5MIL monthly page views, you have to find a way to implement awesome ideas with low effort but high impact. I used these 3 steps to find my own 'right time' to implement our cool ideas.

Setting up customer profiles

The more users you have the better certain patterns in their behavior will be visible. That's why we I made four key customer profiles to focus on.

Analysing key pages & journeys

We made a list with all the key pages/journeys and made sure we had the conversion rate and NPS scores included. By sorting them from low to high we quite easily knew what journeys and pages were ready for something new!

Combined with the pages that have the biggest brand awareness we created a shortlist to start with.

Concept testing

What I do a different from regular designers, is starting with 75% of the test plan before designing anything. By having specific objectives, you also have more specific user stories to work with. This gives me and the team more time to get creative and brainstorm ideas based on our design principles.

We just created the right time to implement our tiny cool ideas! I made mobile and desktop designs for key journeys and product pages. Someone else did the actual test because I don't believe in doing a concept test with your own design.

From design to pattern library

My worst nightmare is inconsistency and when others start reinventing the wheel or use different patterns to solve the same problem. In 90% of all product teams this is also where the biggest waste of money is. To prevent this, I came up with three solutions that are still being used.

Creating a single source of truth

So the first thing I started with was creating a single source of truth for design. I made a Boilerplate that lets every designer start with the same blank canvas as I was working with. At least we know had the same starting point.

Eneco boilerplate

Up next I started to document all the other styles and building blocks. For Eneco this was extremely important in the adoption process. It gave other teams the opportunity to get familiar with a new style and it gave my insights in the implementation priorities of other teams.

Extensive version of the Eneco Pattern Library

Documenting patterns

By having these patterns in design libraries was a great start, but we had a problem... Designers started to adopt patterns, but developers had no clue what we meant with a pattern. They basically implemented everything based on the handovers we did, which wasn't super effective. So that's why we started documenting every pattern in Confluence. We documented our principles, guidelines on how to use colour, behavior of components and even patterns on a template and journey level.

By documenting these patterns I went from designing a form in 4 different breakpoints with annotations, to write down the type of form fields we needed. This upgraded our implementation speed by at least 50%!

Eneco pattern documentation in Confluence

Eneco next best action pattern documentation

Defining the same language

One of the most interesting parts of the pattern library was when we started to implement design tokens. I read a super interesting article by Nathan Curtis (huge fan) that opened our teams eyes completely. By implementing design tokens we finally started to have conversations in the same language.
Small example.. as a designer I think in pixels, so when I say 'this body-text should be 16 pixels', I say nothing weird. However, a developer doesn't combine pixels with font sizes, they use REM (which completely makes sense). This example is quite simple of course, but you can imagine what happens when the behaviour gets more complex. We fixed this by creating a simple tokens like: '$font-size-m = 1rem;'. Now we don't only think the same, but also mean the same. Which was HUGE in creating complex products at Eneco.

By having these design tokens we could also automate quite a few things. Think about spacing or type-scale in combination with responsive behaviour. By adding the the scale you see below, we actually never had to think about what font-size something should be on breakpoint-x.

From pattern library to mature design system

What you've just read was about 1.5 years of work. Our system got more mature and the organisation slowly started to see the benefits. As you've read I don't had a hard strategy on pushing a design system. It grew organically, which is in my opinion always the way to go. A design system is never the goal, so after a while I also had to explain this to the organisation. This completely made sense because we spent more complexity points up front, with would benefit everyone later on. I gave a strategy presentation on how the design system would align the company goals and how teams would contribute to that idea. To give you an idea about the outline, I mentioned the topics below.

Company goals

More focus on the problem
Don't 'over' design
Get grip on what's made

Design system purpose

Create a universal design language
Sustainable building blocks

Team goals

Pattern based design
Uplift journeys
Uplift Mijn Eneco

Quality control in the Eneco design system

After a while, as Head of Design, I noticed that my desk started to look more like a ticket booth where I approved designs and managed stakeholders. This made me super tired. That's why I came up with three (all best answers come in three) solutions that structured our communication to less but better.

Design Meets

Weekly design meet – Every week we had a design meet with all the digital designers and the Head of Branding. We divided the meet in two chapters. One about giving feedback on the actual design from a UX perspective and the other part on what the role of the design system was.

Design critique – We focused on the quality of the UX. We did this by letting someone explain how they used certain design principles to solve a users problem. Other designers gave feedback on how consistent the user experience was and how it aligned with the design system.

Design system – The second part was all about the design system. I introduced a topic 'Lessons learned' where designers presented why certain patterns work or need to be changed. We basically lived with the rule "Show Jordy when something doesn't work".
I personally presented the latest updates on components and patterns. So the first few weeks I presented on why, how and where use a Wizard, DeepDive or Carousel.

Bi-weekly heads meet

In the bi-weekly 'heads of meet' I discussed together with the head of content, development and marketing our bigger epics. The goal of this meeting was to get alignment on the bigger patterns components and behaviours. We answered questions like 'do we have the right tracking codes?, do we have x-characters available in this header?, do we have a generic behaviour for responsiveness of the typography?'

Quarterly design system presentation

In the quarterly meetings we presented our design system updates to about 100 stakeholders. They varied from management, to product owners, commerce, communication and other designers that worked on Eneco. The big difference from the weekly design meet is that we didn't talk about conversion. We talked new building blocks, what the variations were and how you could use them to solve user problems.
We secretly use these meetings to inspire our stakeholders, hoping they would like to implement a new cool tiny concept to the platform.

Conclusion

After working almost 1.5 year on Eneco a lot has happened. While a few tiny ideas grew to a sustainable platform, I personally grew a lot as well. Lets wrap this case study up with a final top 3 items that I've learned while working with Eneco.