We need better ways of creating flexible yet reliable digital products that scale when and as you need them to.
People’s expectations about how digital products appear and work is on a continuous rise; be it a website, phone app, desktop app, and even something on a smartwatch or TV. It is not only a lot of work to meet these expectations, but even harder to maintain and scale as products change and grow.
Most organisations have an expanding portfolio of digital products, likely maintained by several disconnected teams using various mixes of platforms and technologies to build mostly the same, or strongly interlinked functionality… for the same people. As users move between devices, or even just various parts of one product - interacting with a multitude of screens and environments - even slight differences in appearance or behaviour will affect their experience.
The digital realm has become one of the most significant means through which people manage their lives and perform their jobs. Needs constantly evolve, attention spans are decreasing, and companies must keep up with addressing their customers’ evolving needs, and issues they encounter. The resulting complexity and often fragmented user experience of many software products is a testament to this fact.
Create the right expectations and direction early
During the inception of new products, we still find it most “productive” to start by immediately materialising our solutions in the form of features embedded in screen designs for desktop, tablet, phone, watch, etc. Where do you even start? Hopefully the strategy you have chosen to follow makes at least this clear - easily a topic of its own. However what they all have in common is that the users of each platform expect a consistent and seamless experience from your brand.
To be better prepared, the effort spent on delivering software must shift towards a universal design of user experience through better understanding users, and the problems you choose to solve - and solving them in smarter ways. Seek to establish a framework for good, coherent content - yes, even button labels are content - and patterns to produce consistent, (re)usable and accessible interface components. Developers should focus on things like minimising the risk of technical errors and ensuring the best possible level of performance and data security, not on reinventing the wheel day in, day out.
Software products need to be designed not only to satisfy requirements written yesterday, but also to cater for what you will discover tomorrow. That is where competition lives. Prepare for how you will change things when you realise in three months you got something all wrong… and perhaps the exact people who built your product are no longer available.
What might such an approach mean for managing interface design?
The most common strategy for organisations to avoid the inevitable degradation of brand identity over time has been the good old style guide. One of the most classic examples of one is NASA’s Standards Manual
from 1975. It is still as relevant in the digital age as it has even been, however it specifies rather static, fixed, and print-oriented information. For digital products we need a lot of other details, real examples, and principles that transcend the boundaries of the devices your products will be designed for and delivered on.
The software design community’s answer to this problem is the Design System
. It incorporates the style guide, enriching it with the universal principles and intentional constraints to comprise a design language with a digital focus. It standardises how design solutions should be implemented within an organisation’s family of digital products, keeping everything feeling consistent and familiar to their users.
It is becoming standard practice for how governments build their digital products; see the Australian
governments’ design systems. While for businesses, the likes of Google’s Material Design
and Salesforce’s Lightning Design System
illustrate how these resources can take ultimate form, helping third-parties create products that feel native to those platforms.
A record of design decisions is a core part of what a design system is. Having a framework for making design decisions and opening them to scrutiny and discussion is at the heart of what makes products better in the end. These decisions have to be made by someone whether they are recorded and exposed or not.
Making design decisions tangible and consumable by developers
The practical manifestation of a design system is the component library
. This is where the ultimate value lies. It is most notably a collection of components ranging from the smallest elements like icons and buttons, to more complex but still reusable interface elements such as navigation and search forms; and even the specifics of implementing the prescribed typography.
Even the simplest of these components requires a surprising amount of thought, for example to meet the agreed upon level of accessibility, how columns of content behave on different screen sizes, what interaction effects happen when you click on a button, etc. Notes on when and how different components are to be used are all recorded, along with practical examples and code snippets, ready for developers to pick up and use or designers to refer to.
One could say this model is somewhat analogous with the application of Object Oriented programming
to user interface design and architecture.
Things to consider
Given the effort of curating, maintaining, testing, delivering and evolving such a broad collection of documentation and code, it is common place for organisations to have a small but dedicated design system team. There are plenty of examples of the ROI, but it’s enough to just consider the amount of time saved by having a well-tested and designed toolkit of components that can be used to not only build, but rapidly prototype and test several new ideas. What the software developers get is a central source of truth to which they can provide feedback along the way, resulting in improvements that make their way into your entire suite of projects.
Of course, there are many richly featured and well supported user interface frameworks already available, such as Bootstrap
- which one could build a design system around. The downsides are that you don’t own them, the design principles are out of your hands, and your custom components will always be second-class citizens at the mercy of being broken by updates from the framework developers.
If your project is delivered in an Agile practice, the benefits are there too, as frequent interface changes become far more manageable with minimised user interface degradation.
What does this all mean?
It’s never too early (or late) to start thinking about future-proofing your digital presence, and even just by ensuring that projects begin by establishing some design ground rules, and a simple component library before building fully functioning screens. It can greatly promote a coherent product experience, and eliminate many avoidable issues and bugs while accelerating the development time down the line.
It requires some patience and acceptance of the fact that it is next to impossible to deliver the right product on the first try. The best we can do is build a platform designed to be shaped over time not only become the best product you can offer, but evolve to keep up with changing competition and the shifting needs of users.