Updated: Jan 12, 2022
The UX team makes up approximately 2% of the product development effort at Aptitude. And yet, we are responsible for the experience and usability of a portfolio of 6 complex, global products. Our potential impact is small. But our ambition is big:
We want to change the pace of creation and innovation.
Working harder won't make this happen but working smarter will. And the smart thing to do is to build a Design System. I’m writing this blog because I’d like to explain what this means for Aptitude and what changes you’ll see as a result.
Each Aptitude product currently has a styleguide: a document that describes the visual design. So, our first questions should be: why would we change this? And, what’s the difference between what we already have and what we want to build?
We are all aware that usability improvements are required across the portfolio. Undertaking this one product at a time would take a huge amount of effort and is simply not feasible with such a small team. The maintenance alone is unmanageable. We would inevitably end up with neglected products that underperform commercially for Aptitude and that underperform functionally for users.
If we printed out every design pattern from our product portfolio it would take up an enormous piece of paper. In fact, I don’t think they make paper that big. Each design pattern carries an overhead in development, testing and release effort. That’s a LOT of work. And a lot of the patterns are remarkably similar....but different! It is time for the design team to take a componentised, scalable, repeatable approach (much like developers have done for years). By reducing our design footprint, we will reduce the development, testing and release footprint.
We want to build one Design System to serve all our products. It will be a single source of truth allowing for a scalable UI language and streamlined UX guidelines. This is more important now than ever, as we look to a future of microservices. We need to be certain that putting any number of Aptitude services together is going to deliver a consistent and excellent user experience.
So, what’s the difference between a styleguide and a Design System?
Much like a styleguide, a Design System contains the visual design elements needed to build an application, however, it also contains important contextual information. A Design System is a collection of reusable patterns and components with clear rules and guidelines to assemble any number of applications across any number of devices. There is less room for interpretation which prevents inconsistencies when shipping at scale. And inconsistencies cost a lot to either maintain or rectify. Most simply put, the difference lies in the standards and documentation that accompany the assets.
A kit of UI components without accompanying philosophy, principles, guidelines, processes, and documentation is like dumping a bunch of IKEA components on the floor and saying “Here, build a dresser!” - Brad Frost
Take a look at Polaris, the Design System for Shopify. This will give you an idea of what we aspire to build for Aptitude.
So, how are just a handful of designers going to achieve this?
Until we can add more resource, we are changing our workflow. This makes it slower and harder than ever before. Great! We are trialing new software that will help to streamline our processes, so there’s a big learning curve ahead. Every time we create a new design pattern, we have the additional task of documenting and templating it for future use. We’ll write accessibility tests for our designs; our software should be accessible to users of all abilities, including those with low vision, blindness, hearing impairments or motor impairments. And we’ll design for multiple screen sizes with a mobile first approach, which, of course, takes more time than just designing for desktop. This investment prepares us for the future: A future where designers will be able to quickly compile high-fidelity prototypes that are immediately ready for user testing, and that work on any device.
Project Alpha (our fledgling product) presents the ideal opportunity to begin this new way of working. Everything we design for Alpha will contribute the Design System. As the Design System grows to a comprehensive scale, we then will then work on a migration plan for our other products. This will involve a full UX review and design pattern inventory. We will map Alpha patterns where possible and add new patterns only when necessary. Our aim is to keep the Design System lean to avoid any duplication of effort.
We should eventually think of the Design System as a product that serves products. When every product is served by this system, the benefits are exponential. Every Product Owner will have the confidence that their design is up to date, accessible and user tested. UX principles will be baked into every product. Updates and improvements will be reflected across the portfolio, slashing design, development and testing time. The whole portfolio will remain cutting-edge, making legacy design an issue of the past. And most importantly, we will better meet the needs of our users.
This is a long game, but it’s worth it. This is about systemic, organisational change. Investing now will ensure we can respond to change at speed without risking the integrity of our current portfolio.