Designing Design processes
The problem
Ever since the emergence of concepts such as “Design System”, and the propagation of UX Design with a phenomenal speed in almost any IT-oriented company, a need for better organisation started to emerge amongst designers.
Up until a couple of years ago we were still struggling to catch up to developers in terms of smart tools and integrations with other design-related services like InVision, Marvel or Zeplin. That being said, during these past couple of years, we’ve seen Sketch become a staple of UI and sometimes even UX Design due to its flexibility, simplicity and ability to support plugins. Be they from fellow designers or otherwise, said plugins made our lives a whole lot easier.
Enter Abstract
As A tool, Abstract was designed to replace Git for us, designers, and add something on top of it. The very first iterations were quite solid and already provided some benefits to the growing number of services and options available to establish a solid, flexible design workflow that allows for interoperability amongst designers, scalability — since it can let you plan out a product as granular as you’d like, and last but certainly not least, modularity.
That last part is the key here, and is the whole reason why I’m writing this article in the first place. Brad Frost’s take on design systems, of going from tiniest bit to the largest organism can also be applied here. And funny enough, it can also be found in development workflows.
Think of it as this: Your product is a house. In order to build a house, you need:
- Bricks
- Mortar
- Iron & Steel framing
- Pebbles & Sand
- Plaster
- Paint
- Wood
But you also need people. People need to be able to work with each part with as little friction or overlap as possible. So what does that translate into ?
Design for Modularity
Modularity is an awesome concept that basically splits the functionality of an application into modules that are interchangeable and can be decoupled from the main project file, allowing for more than one developer to author a feature. More plainly put, it resembles a lego game, where each brick is symbolised in this case, by a set of files, that together, make up a module, that is part of a feature, that itself, is part of a project.
So how does it fit into our neck of the woods ? Well, Sketch by itself allows you to work with libraries and sketch files. That by itself is cool, but adding Abstract on top of it, and the fact that you can have “external” libraries linked to an Abstract project, is very very cool beans indeed.
This means you can organise your project to fit as many designers as your company has, while ensuring they don’t step on each others toes while working on a new feature. At the same time, you ensure that no new UI elements are invented, because you’re always pulling sketch symbols from the single source of truth that is your design library, which is what your Design System Should be producing (amongst other things)
Let’s dive a bit deeper into the nitty-gritty of it.
Here’s a schematic of the process I’ve designed for this purpose
I apologise for the low resolution, but trying to capture the whole process complete with choice paths was a bit daunting.
However, this by itself will probably not tell you all that much, if you don’t know how the Abstract projects are structured. And sooo….
Our projects have several components, and each project is a granular as possible in order to keep the maximum of designer independence (in situations in which 2 people are working on the same product but on different views and features for example).
The hierarchy is as follows :
Project :
- Feature or View :
- View, Dialog :
- Controls pulled from the Design Library Project by referencing either the Wireframe or the Visual Design Library.
The Design System File is split in components (Controls), Patterns, and Foundations. Each of them as separate pages of the same sketch file. Each page with its representation in a separate document in the Compass Design System Project.
Example: In the SynetoOS Library, the Buttons page has a correspondent sketch document in the Compass Design System Project, where all of the buttons are stored in a local symbol manner.
Once they are considered ok and are reviewed and approved, their symbols are going to be copied and pasted into the “official” Syneto OS Library, which is the ultimate source of truth.
A new merge is going to be done, propagating the new buttons onto all instances of the design library that are linked to any project.
Abstract Projects
- Design Library Project, where we keep all of our Sketch Libraries, and the source of design truth. The libraries are linked to all projects as required
In this case, the library contains:
- Wireframing Library: which helps us build really fast low-fi wires to test and validate, as well as use within stakeholder meetings, design reviews, etc.
- SynetoOS Library: Acts as our main design library whenever a new visual design is required, or if we’re building high-fidelity prototypes.
- Charts (Wireframe): This is part of this design library: https://www.ls.graphics/charts.
- Charts (Standard): Same as the other chart library, part of the same set.
2. Newsletter Project, which also references the SynetoOS Design Library.
3. Compass Design System Project, this is the working project of the design system. Any new control si designed and added here first, and only after being thoroughly reviewed and checked will it be added into a new release of the Design Library
4. Visual Design Projects. In reality 2 separate abstract projects, both contain sketch documents with Visual Designs for of our products. Design Library is referenced in both cases.
5. Wireframing Projects. Same as above, 2 separate abstract projects, both contain documents with wireframes of our products. Wireframing Library is referenced in both cases.
How to deal with the mess
As in all projects with linked content, this too can get messy. That is why i love to use 2 specific Sketch plugins which make my life so much easier.
Symbol Organizer
This plugin is incredibly useful when dealing with libraries the size of ours. I’m always falling back to it to order all of my symbols on page, according to their organisation within menus. Can not recommend it enough.
Symbol Swapper
Again, life save. If you work with Abstract a lot, this will come in real handy. Why ? Well, you will be able to remove local symbol instances and replace them with library symbols automatically
Additionally, you can and SHOULD also use it to replace all existing controls to the same library release version. This is something I cannot stress enough.
Whenever you do a lot of merges and design system releases, you will accumulate a lot of controls from different versions of your design library because of how Sketch and Abstract work together. Using this, every now and then will ensure you will always keep a source of truth up to date on your working documents.
Ideally you would perform a cleanup every 2 months on a files, bringing them up to date and using the very latest library, just to be sure.
Being Organised as a Designer
This is kind of sensible subject, as a lot of designers I saw, were one hot mess in terms of organising their work. But I can’t really blame them entirely, as they were always in a rush to the next meeting, grooming session, design review, etc.
However, it’s so incredibly important to be organised and to plan ahead as a designer, simply because, in most cases, you will most likely work with 2–3 other people. We’re not developers and we won’t have the luxury of having someone cover our ass. Or at the very least, we should prepare for the situation where, if we work alone, someone else might come along at some point, and would need a ramp-up.
Designing a design process would then become pretty important and useful, as it would allow the flexibility of having 2 people work on the same projects without hiccups. Unfortunately, design files are rarely subversion-able, exception being sketch, which means, we need to work by splitting up a huge piece work into as many chunks as possible to allow more people to shape it.
This kind of goes against the traditional design mentality where you would keep everything in one place, because there’s only you who’s working on it.
Additionally, little things like having naming conventions, and organising symbols goes a long way into helping other designers make sense of larger projects. Think of how you struggled, and think about helping others struggle less when they come on board.
In closing
Hope this helped you out in some way to make some sense of large design project organisation. It definitely helped me, and I MUST credit a good friend and former colleague of mine, Paul Axente. Cheers Paul !
He shared with me his experience of working with Abstract, and breaking the things down into smaller chunks for the sake of collaboration between designers. I just took it one step further and changed some bits to make it more flexible and adaptable.
I am a bit surprised that a lot of the articles I read on medium are not really helpful because they just glaze on the subject, hovering, not really going in-depth on how something was done. And I feel like that doesn’t help the design community to progress, because people are just holding on to information because it gives them some advantage in the field.
I think seniority and maturity should come from being able to handle anything someone throws at you, while helping juniors and mids with tips and tricks you know for them to realise their full potential. Help them grow, not hold them back and let them bang their heads against a wall because you did.
