Design Systems

3+  Versions shipped  | 5+  Years of building DSs  | 12+  Products served  | 100+  DS users

 14+  Years of UX  |   20+  Years in the industry  |   25+  Brands worked with

Domains

Enterprise productivity, Banking, Healthcare, Fintech, News, Media & Entertainment, Advertising, Branding, Power, IPTV, Ecommerce, Government, Tourism, CRM, Analytics, Non-Traditional-Interfaces, Design Systems, DesOps (Design Operations)

Brand showcase

Innovations and achievements

• Semantic design token systems for theming color, corners, typography, animation and spacing.

• Design conformance protocol and conformance checkpoints throughout the dev-test-release cycles.

• Reduced conformance issues by over 90% from 20+ bugs per month to less than 2 per month.

• Methodical check-ins with products to understand their usage needs.

• Metrics reported upto 30% costs saved via upto 50% increased velocity for design teams.

• Contribution model and pattern library for cross-product redundancy reduction.

• Participant of W3C DTCG and OpenUI workgroups.

• WCAG 2.1 AA accessibility testing for each component and accessibility recommendation documentation.

• Presented a talk in UX India 2020 on "Design Systems, take or make?"

Pictured: a sample component page - with theme switcher - light and dark themes - 2024

• Codename: Patronus.

• Time: Oct 2019 to present.

• Organization: HCL Software.

• Customers: 10+ enterprise products and websites with a wide user base.

• Platform: Responsive web, desktop and mobile. Design toolkits for Sketch and Figma, code libraries for Vanilla JS, React and Angular.

• Personas: Product designers, UI developers, enterprise end users.

• Releases: 4+ stable and major releases. Multiple minor and patch releases.

• Team: 4 designers, 5 developers, 3 testers, 1 dev manager across multiple locations in India, US and Italy.

• Role: Owning the design system, leading the design team, reviewing component designs, designing complex components, creating and maintaining design tokens, creating documentation, meeting regularly with the users, taking feature requests, deciding on how the system evolves.

The challenge

HCL Software had a wide range of sprawling enterprise products which were using a mixed bag of design systems, some none at all. Universally adopting an open source design system was possible but it would dilute the brand identity and custom requests were hard to field. Furthermore, the growth and direction of an open source system was not in the hands of HCL Software. Meanwhile, the products themselves are not mandated to use any specific design system, so they had to be convinced with due evidence to pick up a homegrown one.

What we did, tl;dr

We researched some of the leading design systems at that point, Microsoft Fluent, IBM Carbon and Google Material, and created our own from scratch. It started with 25 basic components with 2 adopters and then grew as per the products' needs. It has grown through 3+ stable versions, to 60+ components, 100+ patterns, supporting 12+ adopting products.

Pictured: The set of components in V2 - 2021

The role and journey

I took ownership of the design system from get go, I had to evangelize hard the power of a design system which grows according to the demands of the products. I had to listen closely to the customers' requests, pre-empt them and cross-reference them wherever possible. Every product synergy we discovered in the way was an extra win for us. Moreover, I needed to deliver stable releases every few months in tune with the dev and release schedules of the products. 

I had to manage the feature and bug backlog prioritization, the versioning decisions, the process and workflows, documentation, support for products, design iterations, all the while keeping an eye on the minutiae of the components and guidelines themselves.

It started with only two adopters, a lot of bugs and design conformance issues. But we thrived under the pressure and today it's a major success story, helping products shed up to 30% of their design and dev time per sprint.

An input box, how difficult can it be?

Oh boy, I've been asked that by an executive, I have generally been able to restrain rolling my eye and instead replied with the grace of a saint - it can be very difficult. 

But it's too often been tough explaining the intricacies of component design to stakeholders, especially the non-design bigwigs who want to push out a new component in a week or two. 

So I created this case study document to give them a general estimate of considerations of a moderately complex component, the input box. See if I did it with a button you'd be scrolling for the next three hours, so be thankful.

First we research

So the basic input box is the text field, we get that down and everything builds out from that. So we looked at the big ones, Microsoft Fluent, Google Material, IBM Carbon - we also looked at Lightning, Spectrum and Atlassian DSs but the first 3 contained the major variations. The outline box, the pale fill, the bottom line, the weird material jumping label, we got them all. 

Mind you, these designs are matured, well thought and have considerable effort behind them, just because we'll not be using all their aspects doesn't mean we won't notice the work that has gone into them.

Pictured: text fields in Fluent, Material and Carbon design systems.

The initial decisions

Alright, so which one to take, considering that we represent a group of product families with multiple branding, domain, platform and product types, we'd need to be flexible, but some basic decisions can make our text field look sufficiently similar to the things out there (Jakob's Law), yet have its own unique look, so what are our design principles and constraints? What decisions follow?

• We're no nonsense, but friendly  =>  Soft rounded edges and clean lines.

• We're big on accessibility  =>  No tiny text for labels, make sure borders get at least 3:1 contrast, text gets at least 4.5, focus mode clearly visible, error text mandatory, the works.

• We have lots of platforms to support, some of them old  =>  Simplify the core design, no jumping labels, no different borders.

Sounds good till now, so we go through some design iterations.

By the way, from now on, every time you see a design, please assume it went through multiple rounds of prototyping and testing with a bunch of product designers and our own dev team members for usability and feasibility before it went into the DS.

So for starters, this is what we get.

Pictured: The first core text field design.

Everyone is happy! The exec says, "See? It wasn't difficult at all? Just took a week!" - well if it weren't for the research and validation I'd have done this in 5 minutes flat. But nonetheless, the journey has just begun, let's get it ready for developers shall we?

Interactive states

Okay so let's talk interactivity, we did some brainstorming, and my learnings were:

• We love elements that respond to user actions  =>  Hover states, often not present in input fields, we'll have them - deepen the border, subtle but visible.

• Especially for input boxes, focus and active are the same thing  =>  Alright, they can share a state, and a dash of primary color to spruce it up.

• The focused/active state is an important change, we can't just do it with a color change (WCAG 2.2 - 1.4.1) => No worries, let's add some thickness change to the border.

• Wait, the active state won't respond to hover?  =>  Okay this is getting complex, you know what? let's reduce complexity, we'll continue with deepening the border again.

• What about disabled state? => Ugh, we hate disabled states, they are so problematic for accessibility and usability, nonetheless, for legacy support, we gotta have them, but let's put some strong warnings in the docs okay?

Now we go through some design iterations and testing. Some product designers chime in that they have a read only state. Good feedback! Let's dim the border below accessibility, since it's only decorative in read-only, but again, it's an important change, just a color/contrast change sounds weak, let's add an icon. We can revisit this one and tweak as needed.

I crack the whip on my designers, soon, this is what we come to.

Pictured: The interactive states.

We ready the handoff, devs begin coding, by the way, What are the timings for the microinteractions?

Right, right, 

• fastest for hover in, 50ms.

• slow for hover out, 300ms.

• fast for focus in, 100 ms.

• slow for focus out, 300ms.

• medium for border thickness animation, 150ms.

• medium for icon change or size change animation if that happens. 200ms.

There, we have animation tokens if we want to tweak those later or pause animations for a11y, that should take care of things. Coding done, testing done, let's roll! That only took like 3 weeks - exec nods sagely "Yeah I understand how these things can take some time. We're finally done." I sadly shake my head.

At this point adoption has begun, so feedback has started rolling in.

The plot thickens

We get the dreaded feedback, what about placeholders? Okay, hate is a weak word, we loathe placeholders. We hoped no one would ask for them... But but but legacy support! Meh, okay we have a design, but we're not even going to demo it in our docs and storybook, we dislike them so much. Only people who beg us will get it, even then we'll do the best to get rid of them, and some of our products still have pages where the labels are set as placeholders, we prepare for war.

Pictured: The abominable placeholder.

Help text please?

At this point you'd hope we are done, but there's the matter of support text, help text, whatever you call it. Alright, we get it, after a tiny week-long debate on whether it goes between the label and the box or below the box, and how does the error text play with it, we did a compromise and put it below the box, because overall that made more visual sense, the error text will supplant the help text and we will have to expect that the error text contains or overrides the help text content. Also, let's put the icon in it, and see how the full package looks?

Pictured: The core input box model, v2.

Does this work for dropdowns?

Okay since we have the icon, the dropdown model works exactly the same, put the icon as a chevron, then add a menu when active, no biggie.

Pictured: dropdown mode.

By the way, the error state.

Right, how's the error state gonna look? Insert another debate on nomenclature, what are interactive states versus what are validation states, so we call it error mode. Meanwhile, we paint it red, then realize this is an important change and the icon needs to make a show for that too. Cue docs about error message content guidelines and design patterns about jumping to errors in a form.

Pictured: the error mode.

And finally it was over... Nope, you wish!

By the way, our exec? Not a happy camper, this looks like a lot more trouble than initially expected.

It's not over yet.

The testers chime in this time, what about the interactive states in error mode? Oops, we overlooked that. Here we go again, a short debate about whether the hover state going black makes sense here too, and we decide yes, because the error message and the icon stays red. So there!

Pictured: the error mode interactive states.

Do note at this point the combination variant count is around 70+ already. It's been more than a month, the exec is sympathetic to our plight, they see what we meant. Now we think we are done. But...

Umm, success mode, por favor?

...

Yes, yes why not? What's 50 more variants at this point? In fact we create a variable mode system where you choose any color and a new icon and it will create a new mode with all the states packed in. By the way, the thin tick for success is too faint, choose a thick tick! This is how it looks.

Pictured: the error mode and success mode interactive states.

Someone reminds me that there's also an active+hover state, but then the old decision to just deepen the border still works, so that saves another headache.

Pictured: the colored mode active hover state.

Doesn't all of this look a bit too tight?

Says one of our products who does hybrid mobile apps.

The exec is tearing their hair out and ready to just say no, but we have spacing tokens! A bit of tweaking and voila, a relaxed input box variant. Almost no code effort needed apart from a theme file. How awesome are we?

Pictured before - one of my early color token systems - 2021.

The scenario

10+ products with separate branding, theming, often differing color systems, have required us to think on our feet when it came to colors and tokens. We also suffered from lack of flexibility in color systems when trying to create dynamic themes, which led us to the limitations of sRGB and hex colors and palettes built on it.

What I did

I adopted color tokens early in 2020, in fact not just colors, over the years, we had to build token systems for typography, borders, accessibility, animations and spacing. It increased our theming capabilities to support multiple products in multiple modes, light, dark and high contrast. To better enable our products to theme without having to check contrasts, we built uniform luminosity color palettes, which can be hot swapped and can support P3 gamut colors - allowing our products to show brighter colors in modern displays with graceful fallbacks.

Innovations and achievements

• Semantic and descriptive design token systems for theming color, typography, borders, accessibility, animations and spacing.

• Creating new palettes which use OKLCH base with uniform luminosity and wide gamut support.

• Creating dynamic and adaptive color systems.

• Participant of W3C DTCG and OpenUI workgroups.

• WCAG 2.2 AA and WCAG 3 APCA contrast testing for all colors.

Pictured next, building and testing OKLCH based palettes and streamlining token systems and themes using figma variables and plugins - 2024.

View live prototype in codepen.

The use case

The ecommerce product wanted to let shoppers search by product color, both using color pickers and color names. For which the backend needed product color metadata, as well as the content writers and searchandizers needed the names of closest colors to a product color to be able to better write content and metadata for the product entries.

The state of the art

What was already present was an interface to pick a color from the product photo to identify the product color, it produced a hexcode.

This was late 2021, we tried AI solutions but they were iffy, very often identifying the wrong product color or picking a name too obscure or outlandish - it needing frequent manual fine tuning.

Research

A bit of user interviews and I figured out the basic ask was simple, search by the hexcode they picked from the image, or search by a name which they think matches the color, we needed to show them what color was it and what were the closest similar colors called. A quick tour of googling gave us a bunch of tools which could do that. In fact a few of our test users mentioned using some of these tools to initially do the task. Of course an in-product interface would be a better option.

Persona deep dive:

A bit more ethnographic study and further interviews proved that these content writers and searchandizers were quite knowledgeable when it came to colors, and something that the current tools lacked was one particular feature: a clear visualisation of the color space  - not in those words, but they wanted to look at the nearby colors, and see exactly how close to the target color it was, a percentage value helped but the visualisation would help them make decisions better. Especially when they had to choose between a color which was a close match but a weird name and one further away but better suited for content. Which is the specific scenario where AI failed.

What I did

This was to be a very niche component but a crucial one for the ecommerce product - we still asked around and a few other products also expressed a casual interest, especially some other content management products in our group. So after gathering all the requirements. I created a design using the HSL color space as a visualisation space, laying out all the named colors as artifacts. Because HSL has the most human understandable color parameters.

When I sat down with the developers, it turned out a bit too difficult for them to comprehend, so I went ahead and coded the vanilla JS prototype myself.

Pictured: the color finder component, finding a color by clicking on the color space

When it came to finding the matches, I coded my own matching algorithm, and put the sensitivity of match finding as settings using progressive disclosure for power users.

Pictured: settings allowing configuration of the matching algorithm

When a hex color came from the color picker, or just pasted into the search box, it would generate a similar list of matches, clicking any match would rematch to the new color.

Pictured: finding a color by pasting a hexcode or using a color picker

When typing a name of a color, it would show name matches.

Pictured: finding a color by typing a color name