ARKO SEN

Design Systems

 SPECIALIST

Arko Sen standing in the times square in front of a billboard which says 'hands down better'

Philosophy 

Collaboration,
Functionality, 
Inclusivity,
Simplicity,
= Beauty

I've been building and managing Design Systems since before they were called Design systems :) the key lies in communication with your adopters and solving multiple problems while not creating new ones. Any design system which can do that, saves time, effort, money, and provides a solid ROI.

Core Values


Career Stats

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

Logos of Brands, BigFix, Star, Workload Automation, HCL Commerce, Appscan, ZAO, Bank of America, Allahabad Bank, Mahindra Navistar, ADGAS, netscribes, IDFC, ABP, BRICS, CESC, spiritCLIPS, NITI Aayog, and Autostadt

Portfolio

Design System management

2019 to present. Building and owning a code ready design system, led a team of 4 designers, 8 devs/testers, shipped 3+ major versions, grew adopters from 3 to 12+ delivering over 30% cost savings, reducing bug reports by 90%.

-Expand to learn more


Innovations and achievements


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


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.


Pictured: Sample complex component built using the design system
non-disclosable details have been redacted in portfolio.

Component Design

2023 - what goes into a DS component? An input box, some humour, and a lot of exasperation.

-Expand to learn more

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?

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:

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.

Interactive states for form control text input

Pictured: The interactive states.

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

Right, right, 

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.

Error and success interactive states for form control text input

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: the relaxed spacing input box.

At this point I will stop, you get the idea, the requests don't stop coming, the complexity keeps increasing, each new aspect increases the regression testing exponentially and multiplies the variants... And don't forget we're doing all of it in dark theme too!

Back to the original question again, an input box, how difficult can it be?

Well now you know!

Color Theory and Design Tokens

2020 to present. Researching Color Theory and Design Tokens, moving to wide gamut OKLCH colors, advancing industry standards and staying ahead of the curve.

-Expand to learn more

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


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

Design handoff protocol

A figma handoff example for an OTP flow and the handoff protocol documentation. Reduced post-handoff interventions by 70%. 

-Expand to learn more

Pictured, launch page and comments in the handoff.

View figma file

Note: The figma pattern was originally created in 2021
- hence some old-school layout, framing and components may be present.

The scenario

We had a lot of complaints both from designers and developers on handoff miscommunications, so we decided to create a handoff demo, we chose the OTP pattern being built which was to be used by 2+ product teams, we created a handoff file for the pattern using our components, with a prototype built with reasonable accuracy, comments on each relevant conditional, and annotations on the launch page. We built a set of steps that would convey the full flow and design specs with as less extra work from the designers as possible. 

We have been updating and improving it since. This is the 2024 version of the protocol. The handoff protocol is part of our extended conformance protocol which has been successfully employed to reduce design conformance issues by 90%.


The handoff protocol

For designers:


For developers:


For QA


Outcomes

Custom Component - Color Finder

2022 for an E-Commerce product, we needed a very exclusive component. I had to end up coding the prototype.

-Expand to learn more

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

color finder 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

Color finder searching by color name

Overall, the incorporation of the color finder got very favourable response from the customers, the test users could easily spot the closest match they wanted and could successfully make a decision on the best sounding name for their content as well as extra color names for metadata.


Pictured: finding a color by typing a color name

UX talks


UXIndia 2020 - Design Systems, take or make?


JSLovers talks - Better design handoffs