Type, & Patterns, & Changelog’s, oh my
System Design at Tucows — Part 2

Something I noticed a couple of weeks ago is how many design systems forego accessibility in favor of glamor, or desirability. Often they’re dense, complicated collections of guides, rules, and patterns. Sketch files are sometimes missing instructions or labels. Documentation exists in multiple places. I understand that successfully deploying a design system requires instruction to exist where it can be most optimal but that shouldn’t be a reason to quit on one public facing vertical.
Accessibility is a major focus for design at Tucows. My goal for the TDS is for it to be both readable and desirable regardless of the tool. All systems designed at Tucows will be easy to learn, powerful in use, and an enabler of delightful & useful products.

Just my type
Recently our type styles had a bit of an adjustment:
- Down to 7 Heading styles (previously 20!)
- 8 Body styles
- 2 Caption styles
- Down to…. 0 UI styles (previously 20+!)
What happened?
UI Font’s were confusing as heck, that’s what happened. And the rest of the system wasn’t much better. In my haste I had created tons of redundant styles and worse, used inconsistent labeling. I tried to look at it from an outsider’s perspective:
I want to create something beautiful and effective to help users achieve a goal.
Originally, an unintentionally, it looked more like this:
As a designer at Tucows I want to produce a new product using consistent styles.
The problem is clear. The design system was designed for us, the designers. Even within that group there would be a learning curve to understand the semantics and it was unclear how to effectively communicate our end product to developers. To remedy the issue I lightened the load. UI font’s were originally captured as a way to use consistent sizing when creating components. The problem is that the list got so enormous that it engulfed the normal body font’s. Because the styles were listed together UI font’s were sometimes used for copy and body and heading styles were sometimes used when creating components. Updating one style cascaded down and would break things, often without our knowledge.
So I deleted them.

Heading styles suffered a similar problem with redundant styles clogging up the styles pane. That’s where type scales come into play. A type scale is the guiding principal of when to use what size. For example, IBM uses the following equation to determine font size:
Xn = Xn-1 + {INT[(n-2)/4] + 1} * 2Xn: step n type size Xn-1: step n-1 type size

Essentially a type scale dictates how big your H1, Body, Captions, etc. should be when the view-port size changes. The benefit of a scale is instead of having each style captured independently for each view-port size, you can use measurable styles like h700 or b400.
TL;DR
- UI font’s have been removed. Bye.
- Header font’s have been condensed because,
- Type Scales have been introduced. They’re a work in progress. Math is hard.
I can’t think of a witty title — here’s some patterns

Patterns typically represent common behaviors and flows in a product, or interactions that cannot be represented by a single component. I had originally intended on building out a collection of patterns to use on our marketing sites until something hit me,
Should a marketing site have patterns at all?
Hear me out:
- Marketing sites should have dynamic content that reflects the seasonal event’s and holidays (eg. Black Friday or Christmas sales or blogs)
- They should be reactive and adjust with cultural events (eg. the release of a new iPhone)
- They should be responsive and communicate the designed message effectively in all paradigms (web, mobile, etc).
Instead of locking designers into a cut-and-paste mentality I want to promote a culture of experimentation. This was compounded by the fact that our current marketing site has few reused styles between pages and doesn’t have any user flows of particular importance (aside from signing up for service or getting a rate estimate).
This doesn’t mean that NO patterns will find their way into the system.
- Page headers should be standardized. Our current production sites have some wild inconsistencies in style which should be fixed to maintain brand and usability equity.



- Certain CTA blocks should also be standardized as similar styles appear in a number of locations. These might fall out of the pattern definition anyways and just be regular components.


TL;DR
- Patterns are no longer on the design system roadmap, at least for our marketing websites (so… almost everything).
- Certain captured components are in fact patterns, like the Rates Builder, and they will be labelled as such.
- Header’s will be standardized and some CTA banners will be captured as components.
In the end, components hurt my feelings
Last week tabs hurt my feelings.
Not actually, because I have no feelings.

Kidding… of course 👀 but they did cause some issues when trying to create a reusable tab component.
- In our current design Tabs have variable string lengths + a highlighted bar that is the same length as the string.
- We have fixed spacing between the tabs, which is different depending on the view-port size.
Currently Figma does not dynamically resize components based on the content within, however they have announced that the feature is coming.*
This means that using a large component with different tabs contained inside wouldn’t work, for now. While I don’t think it’d be the end of the world to used a static component (one where we can’t change strings in our mockups) it would break the convention set throughout the rest of the design system.
So what can we do?
- We can break convention and design a handful of static elements that will not allow for changes in string (until dynamic spacing ships)
- We set specific content guidelines that set a maximum character length (still doesn’t address shorter titles).
or better yet,
- We clearly define active and inactive tabs and provide the tool’s to build them rather than provide a fixed tab component.
This pseudo-atomic way of thinking lets us be flexible and play with content. It does mean however that documentation will have to exist inline and be clear and easy to follow! 🌟


Other Changes
- As mentioned earlier, UI Fonts have been removed.
- Banners were first demoted from the system, and are now completely gone.
- Deprecated Components are now tracked in a separate Figma project.
- Structure has moved from Components to Foundations
- Added a sample Accessibility Statement to Accessibility
*It’s possible the feature won’t even work like I’m suggesting.
See any errors? Critical spelling or grammar? Give me a shout here, on twitter.com/aalexdee or elsewhere at https://lintr.ee/aalexdee
✌️ & ❤️️
