ARKO SEN
Design Systems
SPECIALIST
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
Visual and Verbal Communication that ensures brand stakeholders, developers, and designers are all on the same page — how to best enable the users - for design system, it is themselves.
Streamlining Stakeholder Interests via surveys, discussions and in-depth interviews into coherent actionables that define design system needs perfectly.
Map the product teams' minds with UX research techniques both behavioural and attitudinal, qualitative and quantitative so that we can model them with Personas, maps and Journeys, aiming to realise the products' needs before they do.
Leading Cross-functional Teams of varying sizes, from small to enterprise, coordinating with SMEs, collaborating with departments, vendors and clients spread across the globe. Guiding researchers, designers, developers and ensuring quality and timely delivery.
Keeping ahead of the industry by evangelising UX, predicting and adopting trends, giving talks, participating in W3C workgroups, championing accessibility and inclusivity principles.
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
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
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
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?
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: 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
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.
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
- 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:
Use components without detaching as much as possible.
If detached, check if changes deviate from default component behaviour, if yes, drop a comment and explain.
Use design tokens through and through, avoid non-tokenised measurements, colors or styles.
If you have to use, drop and comment and justify.
Before creating flow prototype, show key pages to dev and check feasibility.
Create a launch page for the prototype which details out the behaviour of the flow, in as much detail of conditionals as needed.
During prototyping, for each of the conditionals, drop a comment at the relevant element in the relevant screen.
Invite devs and QA, demo the prototype, walk through the comments, explain the conditionals, then share file.
For developers:
Raise any immediate feasibility issues or edge cases in the handoff call itself.
Upon receiving figma file, check for components and tokens thoroughly.
If you find any deviant components or non-tokenised measurements without a comment, check with designer, ask them to rectify or comment.
Begin development, reply to each comment with 'done' as as you incorporate the instructions.
Make sure all comments are replied to.
For QA
Make sure test cases cover all comments by designer.
Check for developers marking the comments done before beginning to test.
Outcomes
Design teams adopting the handoff protocol reported drastically reduced rework and miscommunication.
Post handoff intervention reduced by 70%
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
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
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