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 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.
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, behaviour 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.
By defining our Desktop sizes, we also directly defined the responsive behaviour of our typography
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.
- Translate a written strategy to not only a visual concept, but sustainable platform with reusable patterns, that have a united language between designers, developers and stakeholders..
- Setup and maintain a design system where various teams work with and rely on.
- Lead a team of designers by encouraging and learning them how to work in and with larger organisations.
