When I joined WPMU DEV in 2015 at one of two product designers, I had never come across a company with so many products – especially so many without any design consistency - they were all designed by developers 😱. The other designer was solely focused on a big frontend project (ultimately fizzled and died) so I had the daunting task of maintaining 100+ WordPress plugin interfaces.
At the time we had a lot of customer feedback around slow updates, tons of bugs and no consistency across our products. I was involved in months worth of discussions around a potential business pivot from a once-off purchase business model, to a monthly subscription based service with vastly less products in the suite.
Over the course of ~3 years we decommissioned lots of niche plugins, and worked about developing a core set of plugins all websites would need - we would become the backbone of any WordPress development agency, with everything you really need for a simple monthly price.
Over the course of 5years with WPMU DEV I conceptualised, designed and product managed ~10 beautiful, powerful and award-winning plugins. With a solid trust between myself and the CEO James Farmer, I was given free reign to build a product suite of key plugins every website needed...
As we released new plugins, the burden of maintaining designs and new features of all these plugins became overwhelming, and so I begun the process of hiring designers to work with me. With multiple people now all working on my projects with me, it was clear we needed a proper workflow and design system that grew with us.
I researched, designed and implemented a company-wide design system that was used extensively by designers and developers and translated to cohesive, functional and reliable products. We had drastically less bugs and design inconsistencies, and we were able to work quicker by re-using components and styles.
As any aspiring designer does, they want to expand their skills and hone their craft. Over my time at WPMU DEV I was able to spearhead many critical pieces of the companies products and loved doing it.
I realised that whilst I could hire and manage people, I didn't necessarily enjoy the administration that goes with it. I got to the point where I spent 90% of my day living in emails, Asana, Slack, Invision and brainstorming ways to improve efficiencies. It was all good stuff, but left a very small amount of my time to actually spend designing interfaces - which is where my value lies.
Rather than pursue a role in Product Management, which is where I'd got myself to, I decided to leave the company in mid-2020 to take a mini hiatus, go sailing and hit the reset button. I was grateful to spend half a decade with so many exceptional people in a fluid and fun company, but I knew getting back into the craft of Product Design was what I wanted - not management.
As soon as I had another designer working with me on our plugins, I realised the need for a design system for us that worked the way we did. Simple, nimble, and just enough to ensure design consistency but not swamp everyone into rigid principles. It also needed to work for our developers, or else what was the point?
I love code. I can speak developer language, and perhaps that's the reason our plugins eventually won awards, but also the fact that our design system really did work. We had the Sketch library for our designers, which was the single source of truth - paired with a live, real-code, Github copy that was maintained by one our frontend devs and pushed out to plugins via regular releases.
Our library contained the building blocks for any interface – elements, components, icons and layouts. The icon system uses key maps assigned to a font-face that perfectly scaled to standard sizes used by our developers. We had a nice balance of components and states and widgets that provided enough visual cues for the developer to work with, without making things overkill.
Inserting symbols for common components saved a ton of time and guessing. Each component had variables that could be modified to suit the use case. Including states like hover and focus, or even adjustments like adding icons into buttons. It was flexible enough to translate design-function and user experience to developers hand way around the other side of the world.
I maintained the library Sketch file locally, syncing it to our shared Drive automatically which would then automatically update whenever the designer logged into the computer.
We also ran all our design files of Drive - it was just too each to always have up to date files and to track activity. I mean, this was before the days of Figma and Sketch's fancy shared docs and collaboration features - but even in 2020 it worked for us brilliantly.
Most of the developers who work at WPMU DEV are super talented people with a great sense of humour and an eye for detail. However, even the best developers miss things, and without things like shared components the translation between design and development is left open for interpretation. Add to that the language barrier for non-fluent English developers and it's a recipe for disaster.
Fortunately I can, and enjoy frontend coding so I worked with one of our star frontend developers to build out a modular and flexible shared UI. It was compromised of structural code, functional code and styling code and could be manipulated to only grab the components the project needed.
The relationships between designers and developers flourished when we introduced the shared UI (or SUI as we called it) – it took away all the guessing, and hours of bug fixing and rework at the end of the sprint.
To showcase a bit of the approach and consistency to each plugin, here's a couple of shots of the first time UX. These onboarding experiences varied based on the plugin/product and generally we tried to keep them as simple and focused as possible:
These little onboarding experiences helped beginner users set up 80-90% of the plugin settings in just a few screens. Once they had done the basic setup, the plugin functionality was able to get the first set of useful data for the user to start using and tweaking the plugin to their needs. Yes, we always had zero states built into the design, but we also attempted to get the user past this first using a combination of recommended settings and automation.
Through user feedback we learnt that for some users our interfaces were exceptionally each to grasp from the outset (usually developers), but for some they were confused by basic terms and functionality and needed more handholding. Balancing between the two proved difficult but my UIs always tried to educate first, then let power users 'hide' the tips as they go.
As form follows function in all my designs, you'll notice the layout heavily focuses on educating the user on what the feature can do for them, why it's important and how to effectively set this up. The left hand side was dedicated to the educational side, whilst we used contextual tips and pointers to help people along - such as example formats and default settings where possible.
The example plugin here is Smush, which is relatively straight forward - configure a few settings to compress your images both today, but also ongoing. Other plugins I designed involved hugely complex security plugins with a vast array of settings, but also confusing language. An empathetic approach to the user was the key in our plugins being understood, easy to use, and ultimately retained users due to the simplicity.
You can also see here that I lead a state-driven design team. Due to a fully remote working team, design handover meetings weren't often possible and so the designs had to speak for themselves:
This lead to each design project having in excess of 200-400 design screens. We were able to achieve this using a well-built and flexible design system, heavy use of symbols, and rules around maintaining our designs using version control and a shared file system.
