IBM iX had been working with this client already to reinvent their digital presence, producing responsive interfaces for the website as well as a new mobile app. The project was scaling up, making it difficult to manage versions, keep interface elements consistent, and maintain and adjust existing designs with new requirements.
Some work was already being done to try and rectify some of the issues by creating symbolised Sketch libraries. This was not a perfect solution however, so I was asked to come up with a more bespoke, holistic solution that looked at the end-to-end context of the system to design something that worked perfectly for everyone.
Several designers and developers across multiple teams all need access to the design files, and without a centralised location, retrieval was arduous. This led to devs storing poorly named, outdated local exports of files for as long as possible, which led to inconsistent design implementation.
The design team were transitioning into more heavily using Plant as a version control system for their design files, and this did have potential. However, this wasn't a perfect solution either due to reliability issues and constant updates, which often led to issues caused by different people having different versions of Sketch, sometimes disallowing file access until version compatibility was found.
This problem came more into light as the team grew. The designs were initially all being made by a single visual designer, and when more designers were added, new components and style variations were being designed that had already been designed a different way, resulting in multiple inconsistently styled components that were functionally identical.
The current workflow also made handing designs off to developers a lot harder. I found that this was caused by three main things., and also the lack of easy naviga
I started by identifying the main future users of the design system and synthesising stories and user needs based on observations and conversations with the team. This helped us envision what an ideal design system for this project might have.
Through several conversations with stakeholders across design, development, and business, I synthesised and proposed a workflow through which design work travels from initial requirement to final development.
We considered integrating the design system earlier in the cycle and housing UX wireframes into it to establish decisions even before the visual stage, but when this was tested, we found that the designs felt too "finalised" when housed in the system, which led to confusion in the client team. It also would have removed some of the agility that was in the current UX ideation workflow, making experimentation harder.
The structure for the design system was required to be modular and scalable, so Brad Frost's Atomic Design principles were chosen as a base, with tweaking it to suit the project context.
The primary building blocks of the system, and closest to "Atoms" in Atomic Design. Elements are the smallest possible implementations of visual design, and include things like buttons, text, borders, icons, etc. These have nothing nested within them but can have variations and states, and are combined together to form more complex building blocks.
Components are the next step up from elements, and are closest to "Molecules" from Atomic Design. They are made up of elements and represent isolated containers of functionality. This could include simple and more complex functions as long as the function is generic enough to be used multiple times in the design in different contexts. Examples include date pickers, product cards, and sub navigation menus.
Modules are top level building blocks, and are closest to "Organisms" in Atomic Design. These combine elements and components to provide bespoke functionality for a specific purpose. They are not to be nested within any other container. These include things like the navigation bar, a carousel, or a notification marquee.
The first iteration was designed in sketch and used Invision as a platform to host, as this was what was expected by LFC. This was primarily a prototype iteration, and was the first "complete" project deliverable I presented to the client.
I built interactivity by using Invision and linking together the pages. This was HIGHLY inefficient due to the abundance of text style variations meaning I had to create and link pages for fonts, with links to any combination of base font + bold/regular + 4 colour options + 4 Size options for a total of over 1000 variations over 32 pages each linking out to 9 unique pages. (Demo available on request)
Invision was deemed unviable for the final release.
The structure of the first iteration of the system was as follows, and was designed with some initial inspiration from existing systems such as IBM's carbon and Google's Material Design. This was to maintain familiarity in structure and therefore work with the user's existing mental models.
In addition to the user requirements mentioned above, I also took into account other factors when exploring and evaluating possible platforms. For example:
All of the solutions I pieced together had trade-offs, and these were explored and evaluated. Some of these were cut for not meeting user requirements, some for implementation time or handoff time, and some were cut due to risk of lack of support. Here are a few of them:
After several iterations, the chosen solution involved connecting together Sketch, Invision DSM, Plant, and Zeplin, and using each for its unique advantages.
Here are some things I liked about the solution we ended up implementing:
To make life easier for designing for multiple viewports, I rebuilt a lot of the components using a css box model structure and with responsiveness using Anima.
The Storybook implementation was incredibly helpful for both the designers and the developers, as it allowed the devs to use the tool to maintain their modular codebase, and the designers could look at a live version to evaluate and request changes/updates to.
In addition to the solution highlights above, there were a few specific personal highlights that I felt were examples of creative problem solving or general skill-set that felt personally satisfying.
One of the fonts used was a modified font made in Sketch (a stroke was added and fill removed to make an outline variant of the base font), rather than an actual typeface. This caused issues in Zeplin that would only extract the css as far as the name of the typeface and the fill. This led to invisible fonts being exported and used by developers, causing confusion.
When I noticed this, I proposed that I build a custom outline version of the font. This was considered but deemed overkill for the situation. Instead, I discovered that Zeplin has an extensions feature, so I built an extension that extracted further css from the sketch file, allowing the developers to continue simply using the code that Zeplin provides.
Having large responsibility on a major client project proved to be a fantastic way to make myself more comfortable working with fewer safety nets. Extra responsibility also came when I later had to manage and direct a couple of other interns that were brought on to help me with the system as it scaled further.
I believe the project went very well, and I was able to achieve most of what I set out to do. However, there were a few inefficiencies that I learned from.
There were a few times where I was doing tasks that turned out to be disproportionately effortful for the value they added, such as using Sketch and Invision for the first iteration of the system. This taught me to better evaluate the tools and platforms I use for the context before defaulting to what I'm used to doing.
The daily client meetings, and playback sessions improved my ability to communicate not only my own but also other people's design work, and the responsibilities of later directing other people to some extent was a rush and a challenge that helped me improve the way I articulate thoughts.
I had the opportunity to really dive deep into learning all about design systems. This sparked an interest that I didn't know I had, and is something that I'd be really interested in tackling in a novel way.