Stop designing screens. Start doing this instead.
Reading technology has come a long way. A few thousand years ago, the first books were comprised of clay slab tablets, which were replaced by scrolls and parchment. When Johan Gutenberg invited the printing press [date], the written word on paper as a means of mass communication exploded. It exploded again when Tim Berners Lee invented HTML and the web as we know it. From tablets to…well…tablets, we’ve come a long way from printing on pages to pushing pixels.
The page metaphor on digital screens was a handy transfer of context. The first GUI, invented by Xerox in the 70s, was modeled on the office workers desktop (that’s why we call it desktop), with files and folders representing their physical counterparts. Even with the first version of the web, Tim and his colleagues at CERN would use hyperlinks to crawl through documents and files.
The metaphor of the page, over 20 years later, is still with us. Our UI is spread over millions of different devices from fridges to watches to mobiles — but we still look at our interfaces as fixed canvases of pages or screens. Working in the agency space, we still get briefs that outline how many pages a particular website would contain.
What’s wrong with this? Well, the way things are named and discussed can frame how we think. Our applications are more than fixed pages, they are essentially groups of components. These components are re-usable, varied and can live anywhere. This has been a stream of thought in the tech community for the last 5 or so years — from integrating design systems to building in UI frameworks like React, our work is more and more component focused.
Yet, often I still see designers designing variations upon variations of screens. Surely this contradicts any sort of component thinking. Not to mention, it’s incredibly time & cost-inefficient.
The typical designer's flow goes like this. Maybe you start with a discovery phase or a design sprint beforehand, but once you enter ‘production mode’ as designer will work with a PO or someone similar to flesh out the detailed requirements for a feature. They then take those requirements and any support designs (wireframes, prototypes, etc) and work out all the variations and screens they need to artwork.
Before I became a UX designer, I had a job in a printing factory as an art worker. I would take t-shirt designs and size them up, colour separate them and get them ready for press. Essentially what a lot of UI designers are doing is no different from this. This isn’t really design work, it’s incredibly inefficient and personally, I think it’ll dead-end your career.
As you can see the very simple screen above can easily rack up the different variations. When we do some simple calculation; 8 x 4 x 2 x 8 x 4 x 3 adds to at least 6144 variations. This seems insane for a designer to mockup all these, usually, we get around this by doing some and leaving the rest for a developer to figure out on their own.
A better way is to break these into components and look at what properties and variations those components need. Not only would this massively reduce our workload and potential to run into problems during development, but it also means we can structure these components however we want. We don’t need to mockup new screens every-time we want to make a change. This is what it means to be agile.
What we can do here, instead of designing 6000 screens or leave parts missing, we can design the system around each component, so the developers can create the screen variation they need on their own. It’s important for designers to remember that whatever you create isn’t the product — it’s just instructions on how the product should work. So let’s cut down the instructions to something more useful, easier to explain and quicker for us to execute.
This is what a Design System is. But you don’t need a complex library like this, you can create a single component guide. This gives a developer all the information they need. If a picture is worth a thousand words, then a guide is worth a thousand mockups.
Designers need to remember that they are designing artefacts, not the real thing. They are giving guidance and instruction to the product development process. This requires a more fluid and holistic approach. Don’t get stuck on the page.
