App Style Guide

Here comes the time to talk about Ui-Jungle-Fever and everyone wants to say its own belief as usual! The truth is: this job is all about a never ending process, as long as everyone can handle it in different ways. Not to mention the country you're living in.

In fact the design approach in Italy seems to invest too little and as consequences there is so little gain that it would not be worth the effort at all. Maybe these teams always seem to be struggling to ship work they're proud of under deadlines that always feel too tight. But something is missing. I could feel it, deep down in my bones; there must be better way to build product. Thus, based on my past experience as a designer, I’ve naturally arrived at a design-centric solution: I need a design system!

In fact, years ago, I envisioned something that our overseas fellows have already envisioned many more years ago as well (Design systems, back then “component libraries”, were used throughout the 2000s, and even at least as early as Dell.com’s library of “atoms and molecules” in 1999 created in partnership with Frog Design).

So far I came a long way. Having spent the majority of the past few years thinking about how to design, build and present design systems for service products (see case history ), I figured I’d share some of what I’ve learned along the way. Let me show you how creativity is the production process itself to make a better product. (I'm speaking of the design process only, user research aside)

It’s no secret that designers love a good UI kit. However, beyond just putting together toolkits and style guides, it seems that recently there’s been increasing focus placed on designing systems intended to tie whole products together. Big companies all around the world are building in-house teams focused specifically on designing systems. People are starting to realise the importance of systemic design. This is encouraging, especially in Italy. In fact, in most companies the delivery process from the concept to the user is so disjointed that the products feel nothing like what the designers first intended. The signal (the concept) fades as it goes through perturbations (inefficiencies), and ends up into the product in a much lower fidelity. Such inefficiencies have a massive impact on the company’s ability to ship high quality products, which has a huge business opportunity cost.

No doubt, I get asked about design systems and, whenever possibile, I produce a very simple version of it. I'm saying simple coz there's no much interest in it yet. But who knows, maybe some day we’ll have a design tool that doesn’t assume we’re starting from scratch every time we open a new document…? Starting with something like this one, zeplin or som design version control tool like adobe-cloud or even better Craft plugin for Sketch and many many more I can't mention here

WHY

The best products are built by teams with great communication bridges between designers and engineers. Whether you’re one or the other, at the end of the day… we’re all shipping software. As I already mentioned, when a Design System is invited to the party, communication is even better. It will bridge the gap between the design team and the engineering team.

A design systems must get into the designers’ shoes, and have a feel for what they are trying to conceptualize. At the same time, Design Systems need to understand the engineering requirements and define methods that will help shipping and scaling the design system. In a way, a design systems is the key translation between these two worlds.

As a matter of fact, building a design system is extremely useful. It is more than a framework, UI toolkit or component library. It’s more than a style guide or set of code guidelines. It’s even more than the sum of those parts. A design system is an evolving ruleset governing the composition of a product. Never fit the content to the design, the system must work with any content. I don’t just design for the best case scenario —  I account for all scenarios

WHAT

Style guides, pattern libraries, design systems: all help normalize practices and design patterns around a common language.

Design systems can start with: naming colors, objects, conventions, components… down to documenting the finest details of the experience, such as animation timings or the roundness of corners on form elements.

A good design system helps make design decisions much faster (e.g. “what color should a call-to-action be”). Designers can then spend more time on user flows, and exploring multiple concepts in the same amount of time. A good design system also helps engineering teams refer to a single source of truth at the implementation phase. This is good for consistency, as all call-to-actions, for example, will look the same across screens.

Some design systems also ship patterns using code. These design systems can prove to be valuable from the beginning of the concepting phase, to the prototyping phase, down to the implementation phase. It’s a good sign for both productivity and fidelity when a company follows that path.

I've been watching the prototyping tools evolving since 2009. Long time, no talk. Check out my post on wireframe 'n' prototype tools to get a better insight

Yet, some design systems don’t get the love they deserve and end up being glorified lists of patterns, afar from production code. That’s because a partial investment from a few designers and developers is not enough: a design system isn’t simply a project, it is a product serving Products (quote by eightshape )
For a design system to show sustainable value at scale and at all phases of the delivery process, it needs proper planning, user research, and methods (and lots of love!).

Other portions of Micro design system I started off with, years ago in 2009

HOW

When creating a design system it’s important to be mindful that you won’t be the only designer (or developer) who works with it. Literally documenting the design system was the biggest challenge for me on every project.

Normally I create annotated specs — typically these are a series of .psd or .sketch files, to accompany the design(s). A good example of this approach can be seen in my case study down below (see case history at bottom page). While specs can contain every detail imaginable, things can still be missed or misunderstood when a new or replacement designer steps into your shoes.

I started out reading and researching how other teams had done this. Fortunately the Internet is full of answers for this, and many companies have made their documentation public.My initial goal, having seen so many stellar examples online, was to create a website to document the system, specs, showcase example uses, and specify guidelines for all patterns and components. It would act as a quick reference, or a bible to study in detail.

However, I didn’t want to be held back by the design, build and time constraints of creating a website for this  — the only reason to create a public, branded website for this would be as a ‘pride project’ or as a resource if we open-source the system (I did it anyway - interactive ux app ). So to get started I simply created several templates file among Illustrator, Photosthop and Indesign (Google docs as well why not, not to mention the useful tool by L.Benazzi, Ux Map for Axure ). As the document grew, I realised these templates did exactly what I needed it to.

As the documentation was taking shape, design needed a way of efficiently communicating and tracking the build and integration of the system to the developers. I heard of designers choosing to use GitHub in order to engineering their design system. They created ‘issues’ for specific components — sharing previews of the design, specs to ease the development process. This way engineers can tackle these bitesize chunks one-by-one as they’re ready, they’re held accountable, and nothing gets missed! However, I'm aware there are online tools out there ready to accomplish this critical task like Zeplin and other design version control tools on the market, like the tremendous Craft Plugin made by Invision for an incredible software, Sketch (version 44 updates with constraints and overrides. Great move!)

But, what if your project has to be hand over somebody else? I mumbled for a while, then I realize the installing solution could be just great ( tools on Packaging ). A package is a bundle (with a .pkg extension) which contains an archive of files to install and information on where to install them. It can also includes Read Me, License documents and scripts to run before or after the installation. Remember google docs I mentioned before? Even tools like Notion are great companions to achieve this goal.

Developers and designer should get along and understand each other world techniques (with proper limits, of course). This would reflects in the production process, and the quality of the system. Via this documentation I like to expose designers to coding, encouraging them to understand how things work. From a ‘learning to design with the system’ point-of-view, it helps to explicitly see and learn the values, spacing and naming conventions in the build. It also helps to bridge the gap between design and engineering.

Last but not least: One of the goals of the design system is to get designers, developers and product managers all speaking the same language. We can help to achieve this with consistent, semantic naming conventions we’re all familiar with (in the design and code), be it coding variables, font styles, colours, UI patterns and components, templates or page names.

If you don’t start off on the right foot, you’ll trip the whole way through. My folder structure helps keep me organized, and gives me a way to share design resources with various parties (asset, reference, marketing, dev, etc.). You may want to create an automation to create all of these folders for you and you can get it here for free, New Design Project Automation Tool. Also you may want to keep your finder organized as well. You've got covered on this too, check this out, Divvy.

Order is a priority either I'm working on common files or design files ( e.g. - Etiquette ). I’ve naturally arrived at a naming-centric bullet-proof solution as the projects I work on are likely to host more than one platform in the future (mobile and web application)