Schema Wireframing Library
Designing a flexible Sketch library for the firm that tackles everything
Schema Design is a research and design firm based in Seattle. Their clients range from startups to Fortune Three companies. One week might be spent working on a site widget. The next, a display for an installation of 60 monitors.
I thought it was a great challenge to deliver a component library for wireframing that’s as flexible as they are.
Visual | UI/UX
Three weeks, July 2018
To begin, I performed an audit of Schema’s wireframe boards to look for shared colors, components, and icons. I was able to identify several commonalities between projects, such as actions that were typically demonstrated and recurring layouts and components.
I had access to nearly five years of wireframes generated by many different designers, and synthesizing an appropriate-fidelity visual language out of them proved a challenge. The use cases were exceptionally broad.
I also discovered another function of the wireframes: communicating concepts to clients. With this in mind, I knew I had to stay faithful to the Schema brand.
Sketch’s nested symbols is one of the main reasons it’s such a powerful tool. A scalable, flexible library would have to be made out of modular parts.
Schema has a way of doing things and swears by several plugins. Notably, the library would have to respect run-line adding of symbols.
Big and Small
All nested components would need to resize correctly with wide . Not only is this handy for design, but makes sense given the context of Schema’s work: many windowed applications. I also wanted to design them to shrink correctly, too, with appropriate overflow boundaries.
Schema deals largely in data visualization and specialized tools. The inclusion of specific features like symbolized graphs and charts would be appreciated. Too many overrides would be preferable to too few.
COLOR “PARTICLE” SHEET
For the most part, most components share an edge. Strokes lie on the middle to avoid weight confusion.
Typeface: Graphik (Schema’s branding typeface).
Static components have a black fill and a white stroke. Disabled components have a dark gray fill and a medium gray type fill. Active components have a medium gray fill and a white type fill.
No rounded corners except on chip components.
Icons are constructed from 2pt white strokes. Icon target size is 24 pixels.
TYPE STYLE SHEET
PANELS—BUILDING BLOCKS OF PAGES
I designed the component library on an 8pt grid for improved legibility, consistent scalability, and better visual hierarchy.
Additionally, the screen template used in Schema’s presentation decks is 1440p. Knowing this, I used divisible component measurements (120p, 160p, etc) that would allow for maximum modularity and minimal resizing with the intention of cutting down on decision fatigue while designing.
Small components designed on the 8pt grid, when assembled, require few if any modifications to fit the rule system.
All nested components have appropriate width or height freezes and are anchored to scale up logically (corners or axes).
Symbols scale down well and generally have appropriate clipping fields. In some special cases, the clipping is a feature. For example, the symbols meant to represent body copy and headlines will clip upward to allow for easy staging of any length.
Sketch features symbol overrides that allow any component made of nested components to be fully modular. But from my own experience, the more modular a symbol, the more time spent tweaking and concealing unwanted components. That’s not to mention the lengthy override list, which itself poses a usability issue.
I addressed this by introducing a new class for all higher-level complex symbols: /Prime.
/Prime is a naming convention suffix that denotes a symbol has all its overrides intact. Keeping highly modular symbols separate allows users to work more effectively by default while still having options. All /Prime symbols and default symbols are interchangeable.
THE FINAL LIBRARY