Hey, I’m Saurabh. A designer by profession and a curious child at heart. A few of my close friends had recently suggested that I start a blog, and it made sense. Who am I kidding, it was almost 6 months ago and I’m still stuck on my first article. For the longest time, I wasn’t aware of why. Maybe it was just a lack of ideas, perhaps I’m bad at articulation or I just need to learn how to write. The workbook by Julian Shapiro did help a lot but still, I was stuck. It was the first step all over again - until recently.

I think I’m just scared. Getting stage fright, just digitally. I’m scared that my ideas aren’t worth being out there in the world. I’m scared about what I will do if my opinion evolves in the future. I know it will, *it always does*. Will I keep getting ideas? Will I be able to write enough? The list goes on and on. I know a few of you out there who are just amazing at writing and I’m glad to be friends with them. They keep iterating that these issues also haunt them. The next step is always a little blurry until you lift up your foot for it. But it’s hard to have faith when you’ve been stuck on your first article for months.

This article sounds a little demotivating but that’s exactly the reason I’m making this my first article now. It’s a reminder for me to not go so hard on myself. I don’t have to write a lot. I don’t have to write regularly. I don’t have to expect something amazing out of it. I just need to express myself. Put my thoughts out there. If my mind evolves, I’ll write about my new fresh perspective. I don’t have to disown how I used to think. I don’t have to be scared of how I’m going to think.

I hope this article realigns me when I’ve lost my way or just down in the dumpies. It’s a hug to myself to just go easy. And I’ll try my best to make it feel like a warm one.

Till the next one. See ya.

Why I'm starting now

## Context

Primer is a payments infrastructure product which allows merchants to accept, automate and optimise their payments. In order to optimise a merchant’s payment performance, we’ve built Observability, a payments analytics suite which presents payments data in a digestible format enabling merchants to make the right decisions. Sometimes, you need to zoom in on a particular slice of data to get a better view of what’s happening. That’s why we’ve got filters for different properties, and one of those filters is a date-time range. This nifty tool lets users focus on a specific period of time, which can be a game-changer when it comes to understanding what happened and exactly when.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FEmDCLIKvURJ2kaR4rLod%2F282fa72d-621d-4876-9a4c-3a18160ac9c3.png?alt=media&token=47e639e7-6ba6-4e65-a9fb-29e1b676205f","id":"282fa72d-621d-4876-9a4c-3a18160ac9c3","width":2967,"height":1969,"filename":"obs-dash-with-picker.png","type":"image/png","caption":"Observability dashboard with date-time picker","border":false}]}
```

### My role

As the design systems designer, the project was under my ownership while working closely with 3 other designers who owned different parts of the Primer product - Workflows, Observability & Payments.

### Project duration

3 months (excluding development)

---

## First launch

A date picker isn’t something that would be developed from scratch on the first go and I believe it’s a good decision. Almost perfect date pickers have been made multiple of times, readily available in the form of libraries, and making one from scratch takes a lot (I mean, a LOT) of time. Our need for a date picker started from a single date & date range selection, which any of there pre-built libraries could fulfil effectively.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FEmDCLIKvURJ2kaR4rLod%2F4fce27fd-e66e-4af5-8f06-4d6d82b1caac.png?alt=media&token=3235bab9-b21b-4a2c-95c1-70c169d4559b","id":"4fce27fd-e66e-4af5-8f06-4d6d82b1caac","width":1426,"height":826,"filename":"Untitled (7).png","type":"image/png","caption":"Date picker on Primer dashboard, using a library","border":false}]}
```

So, we used one and it worked for a long time until we fine-tuned our requirements realising that we needed something more than just a date picker — we wanted a date “time” picker to provide users with super precise control over their data. This decision was also supported by our growing design language, which dictated that we would need a visually different date picker that matches with Primer’s design language — clean, simple & functional.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FEmDCLIKvURJ2kaR4rLod%2F8457c964-f7aa-4c67-8d7e-96bb5f4095bf.png?alt=media&token=ae3d8b17-eaf7-48d2-9953-91e0fe0031a6","id":"8457c964-f7aa-4c67-8d7e-96bb5f4095bf","width":2188,"height":1784,"filename":"Untitled (8).png","type":"image/png","caption":"First version of the custom date time picker from Goat","border":false}]}
```

---

## Challenge: Unreviewed submission

While we were building our custom date time picker, our developer, [Euler](https://www.linkedin.com/in/eulermenezesjr/), noticed something interesting about the date range picker. It had a default interaction that automatically submitted the final range selection as soon as the user picked the end date. While this sped up the process of getting results, it didn’t account for any misclicks or allowed a review stage. A review stage is crucial because every submission would lead to a query in the backend and the whole data on the page would get refreshed. Additionally, there was no clear indication to users that their chosen range would be submitted immediately upon selecting the end date.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FEmDCLIKvURJ2kaR4rLod%2F93c0c156-4ec1-4835-9ede-6d1849ad427d.gif?alt=media&token=cb1e4ad4-3142-485d-80dc-5675d3101e75","id":"93c0c156-4ec1-4835-9ede-6d1849ad427d","width":1708,"height":1080,"filename":"Untitled (1).gif","type":"image/gif","caption":"Interaction flow of the date picker","border":false}]}
```

To tackle this issue added an action bar at the bottom of the date picker to allow users to review and modify their selected range before hitting the submit button. This change provided users with more control and ensured a smoother experience.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FEmDCLIKvURJ2kaR4rLod%2F9b324e92-7dec-4eab-8ff5-3c0004c8e913.png?alt=media&token=c2297fa4-9202-4c48-8e86-20c2c46d1af1","id":"9b324e92-7dec-4eab-8ff5-3c0004c8e913","width":4162,"height":3724,"filename":"Untitled (9).png","type":"image/png","caption":"Date time picker with confirmation buttons","border":false}]}
```

---

## Challenge: Multiple time zones

When you’re dealing with a global product like Primer, one tricky factor to consider is time zones. I’m not talking about Einstein’s general relativity here, but the kind of relativity that comes with comparing time zones. For example, if it’s 01:00 PM in London, it would be 05:30 PM in India. Now, picture this: you’ve got a dashboard that’s pulling in payments from all over the world, each in its own time zone. How do you know if the date picker is speaking your time zone language or your customers’?

This was a real head-scratcher because it could affect all of our users. We knew we had to find a way to make it crystal clear which time zone the date picker was using. As we researched more about the time-zone implications, we realized this wasn’t just a date picker problem, it was a dashboard-level issue as well — our dashboard didn’t give any hints about what time zone it was operating in.

To tackle this issue, we made two moves. First, we inserted a time zone indicator on the dashboard topbar. This enabled users to see that every chart and statistics was playing by the rules of a specific time-zone.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FEmDCLIKvURJ2kaR4rLod%2F692478d9-7c57-4e93-9573-b8bf8889c508.png?alt=media&token=3d40e314-7187-4819-af13-3c3d09f615fa","id":"692478d9-7c57-4e93-9573-b8bf8889c508","width":2720,"height":754,"filename":"Untitled (10).png","type":"image/png","caption":"Time zone (UTC +3:30) in dashboard topbar","border":false}]}
```

Second, we added a time-zone indicator in the date picker itself to guide users while setting those date filters. We brainstormed a bunch of spots to place that indicator, but in the end, we settled on placing it right where the time control sits. Simple and effective!

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FEmDCLIKvURJ2kaR4rLod%2F81412b34-9f3d-4bc0-bfef-35591429ef88.png?alt=media&token=54928aa4-bbac-473b-a797-bfb4535d1ddf","id":"81412b34-9f3d-4bc0-bfef-35591429ef88","width":4162,"height":3724,"filename":"Untitled (11).png","type":"image/png","caption":"Time zone (UTC +3:30) in date time picker","border":false}]}
```

---

## Challenge: Preset visibility

Let’s talk about something we haven’t dug into much yet: range presets. In the earlier versions, these presets were basically buttons that, when clicked, would fill in the date range for you and hit that submit button. Seemed like a time-saver, right? Well, not so fast. We had to make a trade-off in terms of design and resources, which meant we didn’t show the selected date range. So, if you picked “Last 7 days,” it would auto-fill the dates, but you wouldn’t see which range you had actually chosen.

That’s when [David](https://www.linkedin.com/in/dvd-p/), our analytics engineer, came in with some fantastic feedback. He suggested that a hybrid input field — one where you could pick your own dates and another to select those nifty range presets could be helpful for our use case. We loved the idea! It treated both the controls independent of each other which was a clear logic and an overall better experience than before.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FEmDCLIKvURJ2kaR4rLod%2F314796ec-cdaa-48d5-b3fa-38da65617810.png?alt=media&token=617211c8-4018-48b6-8cbc-1c607b80c857","id":"314796ec-cdaa-48d5-b3fa-38da65617810","width":4164,"height":3726,"filename":"Untitled (12).png","type":"image/png","caption":"Calendar view of the hybrid date time picker","border":false},{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FEmDCLIKvURJ2kaR4rLod%2Fcaf9eaa5-d3ff-43b2-b6d2-97424839ce5f.png?alt=media&token=cfa1d10b-eb32-4a5c-95b1-931996c3f378","id":"caf9eaa5-d3ff-43b2-b6d2-97424839ce5f","width":3390,"height":2563,"filename":"Untitled (13).png","type":"image/png","caption":"Range selection view of the hybrid date time picker","border":false}]}
```

This change gave the users the power to choose how they wanted to do things. They could tinker with the input date field and select their dates without any fuss or distractions. And if they were in the mood for those handy presets, they could simply pick one from the preset range, again, without any interference from the date picker.

---

## Results & Conclusions

* At the time of writing this case study, the designs had reached the state of the hybrid date time picker with range select but the code was only updated to the last version with the time zone indicator.

* There were 3 major products where the picker was essential - Payments, Dashboards & Workflow runs. All 3 of them had adopted the new component within 3 months of its code release.

Designing a custom date time picker for Primer's design system (Goat)

The world of design systems is fairly tricky in my limited experience. Design is subjective and systems are complex - that’s not a very attractive pair. Anyone working in design systems would have to work in multiple areas like designing, selling, and advocating for the system. Designing high-quality accessible components, tokens & behaviors is just a small (but essential) part of it. More often than not, people start with design systems and give up on them soon because of the lack of adoption and acceptance by other team members. Why? Because people have inertia in their processes. They won’t change their way of working just because you came up with a new radical idea. It has to solve a problem - be it velocity, consistency, or alignment. The process of building a design system starts way before you create a new Figma file, it starts with people.

I’m not here to convince you that you need a design system at your company, that’s a different topic for some other time. Nevertheless, if you do find the need for one and decide to go ahead with it, here are a few things I learned a bit too late.

## Have a vision

This is not an idea specific to design systems. Every big project you take up in life or work should have a tangible vision that you work towards in the long run. I’m emphasizing this because I’ve often seen teams ignore this part and just start building a design system because it’s the next hot thing to do in tech. Without a defined vision for the system, people might start building it without a clear direction. This often leads to confusion and no progress. Without a vision to work towards designers might not feel the need to take initiative to extend and evolve the system. They’ll eventually stop after making a Figma library and then developers would not invest in developing the components and tokens. The idea of a vision has power because it’s a shared understanding. Everyone in the team has a responsibility to work towards something they believe is possible.

A vision could be as simple as making the product cycle process faster. A design system can help achieve this by allowing quick and efficient design iterations once the basic foundation is set up. Another vision could be ensuring coherence within the design team, especially when it grows larger. Without frameworks in place, keeping everyone aligned and working together can become challenging.

## Go beyond Figma libraries

You must’ve heard a lot that “Design systems are more than a Figma library”. It’s true but it’s also incomplete. Libraries are an important foundation for the system because that’s the very first tangible deliverable of a design system initiative. While UI kits are essential, they are not everything. What makes a UI kit into a design system are the documentation, guidelines, constraints, and people around it. A UI kit dictates that a button is a navigational element but a design system dictates what to use when you’re trying to navigate the user - a button or a link?

A design system helps designers make decisions about which elements to use and how they fit together in the overall design. It's like a language for your product, with guidelines as its grammar. So, think of a system as more than just a library—it's a comprehensive approach to designing the product. If people have to ask you repeatedly how/where to use a certain component, your documentation needs work.

## Keep documentation simple

Documentation is a way to share information passively. It means putting things in writing, so anyone can access it, regardless of who created it. Even if you leave your company, others should still be able to use the information easily. However, when you start explaining concepts, there can be a lot of information, and people might not have time to read through it all.

As a systems designer, your job is to make using the system as smooth as possible. Too much text to read or difficult-to-find information creates friction. Instead, be intentional with your documentation. If something is obvious, you can skip it. For complex topics, use visuals to make them easier to understand. Be creative in how you present information for your designers and developers to consume it effortlessly.

## Plan for the future

A design system that only suits the present won't last long. In the fast-paced digital industry, designs continuously evolve and change. That's why systems are essential—they help automate decisions when things scale up. For example, a simple change in a design token can impact how the entire product looks, functions, or behaves.

When you're working on tasks related to the design system, always consider how your decisions might affect multiple aspects in the future. Aim to create solutions that make future modifications easier to implement. Thinking ahead will ensure your design system remains adaptable and relevant in the ever-changing digital landscape.

## Embrace feedback loops

As I said earlier, change is inevitable. But change has to be guided by something, and it’s best when it comes from feedback. In this case, that feedback comes from your designers and developers, the system’s primary users. To ensure healthy adoption and maintenance of your system, you’ll have to collaborate with them to figure out opportunities and areas of improvement. It can come in different forms, like a personal Slack message or a company-wide email about why your dashboard sucks. When people have a part in shaping something, they feel more attached to it. When your team gets involved in shaping the system, they’ll be more likely to adopt it and hence come up with more feedback. It’s an awesome chain reaction!

## Be patient & considerate

All good things take time. And systems take a lot of time. I know you want to change the game as soon as you join the company but that’s the most novice thing you can do. A good designer listens and understands what’s happening in the company and then figures out what to do. You can’t function if you don’t have the intel ☕.

Working in systems and not seeing them getting adopted can be frustrating. That also means you’re doing something wrong. Remember, a product team has many priorities, and a design system might not be at the top of their list. That's where the skill of selling the idea of the system comes in. Show how it will make everyone's work easier, and once your team is on board, the system's importance will rise.

However, be patient. Sometimes, product-related demands take precedence. Don't force things to happen unnaturally. If the need for a design system arises, especially in larger teams, your good groundwork will come in handy, and others can take over and continue building on it.

I hope you found this article helpful. I’ll be writing more on the niches of building, selling, and maintaining a design system. See ya later!

A survival guide to design systems

## Context

Charts are an integral part of Primer's [Observability](https://primer.io/product/observability) product dashboard. Observability acts as a central nervous system for a merchant’s payment infrastructure, offering a holistic view of their entire transaction ecosystem. From the moment a customer initiates a payment to the completion of each transaction, every step is recorded, providing them with invaluable insights into the health and efficiency of their payment systems.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FZi21N7AmHtJ7jwHw0awH%2F35123645-3fbe-4eae-b5ae-810da0b54b44.png?alt=media&token=aeb93104-d166-4911-bd5d-56274525484f","id":"35123645-3fbe-4eae-b5ae-810da0b54b44","width":2967,"height":1969,"filename":"image.png","type":"image/png","caption":"","border":false}]}
```

### My role

As the design systems designer, the project was under my ownership while working closely with another designer who owned the Observability product.

### Project duration

2 months (intermittent)

---

## First iteration

Majority of the charts we use are line, area & bar charts, sometimes as a combination of two types as well. We also cater to various other use cases of data visualizations like table charts to ensure that our merchants have the most optimal scanning experience with their data. The data that we show in Observability often requires us to superimpose multiple data points which made it necessary for us to rely on color to make proper distinction. This is why you see so many legend keys and such colorful charts.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FZi21N7AmHtJ7jwHw0awH%2F8b100bf6-f8e6-4e02-9283-c132028e107a.png?alt=media&token=6022d4d4-2b8c-4417-b2a2-a3ebbeaabc50","id":"8b100bf6-f8e6-4e02-9283-c132028e107a","width":2388,"height":1340,"filename":"old-charts.png","type":"image/png","caption":"Some supported charts at Primer","border":false}]}
```

Instead of being completely static, one can interact with our charts by hovering over the chart elements to see more specific details about that specific node. This helps increase the focus on that specific chart element and reduces noise from other data points.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FZi21N7AmHtJ7jwHw0awH%2Fb14ed76c-07d4-4588-8e36-c1f57e5b1870.png?alt=media&token=2f657b89-1ad9-47f5-b725-e5480dc9d006","id":"b14ed76c-07d4-4588-8e36-c1f57e5b1870","width":1401,"height":640,"filename":"chart-hover-focus.png","type":"image/png","caption":"Hover focus interaction in a line chart","border":false}]}
```

During the collaborative design process with Daniel (from the design team), we successfully implemented several positive aspects:

* Ensured all text elements meet the required color contrast of 4.5:1.

* Incorporated clear labels for each element within the charts.

* Enabled hover focus functionality for chart elements.

---

## Identified problems

In some later stages, we identified some areas for improvement while demoing the product to some merchants and also during internal demos:

* Chart colors lacked sufficient contrast, impacting readability.

* For high cardinality data, the charts get too chaotic which made it harder to focus one a single element (lines) from the graph.

* The chosen chart colors did not take into account the needs of color-blind individuals. (Lead PM on this product was also color-blind)

* There was no keyboard accessibility - which could limit usability for certain users.

While our first approach considered accessibility in the design process, we missed out on a few details from WAI which we aimed to address now. According to the [Web Accessibility Initiative ](https://www.w3.org/WAI/tutorials/images/complex/)**[(WAI)](https://www.w3.org/WAI/tutorials/images/complex/)**, it is advisable to provide a detailed description for complex images, such as those represented in the charts. This can be achieved through alternative text (alt text), tooltips, or by directing users to a separate page containing a comprehensive summary of the chart’s content. Additionally, the [WAI Non-text contrast guidelines](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html) recommend maintaining a contrast ratio of 3:1 between graphical elements to ensure their visibility.

Another valuable resource is this [article](https://wearecolorblind.com/examples/visual-website-optimizer/) which discusses the use of hover interactions to focus on chart elements, reducing reliance on color alone. To help our case, our current charts already support this functionality, allowing users to hover over elements for more information. However, the charts currently lack keyboard navigation capabilities, preventing users from accessing the elements via keyboard commands.

Overall, while we accomplished some critical design goals, there were notable areas where we could have enhanced the charts’ accessibility, legibility, and usability for all users. This is why we decided to revisit the charts and try to tackle these issues.

---

## Explorations

We went for exploratory approaches that change how our charts look completely. At Primer, we strive by diverging our ideas to the limits and taking help & different perspectives from other designers, developers, and other members of the team. These are a few approaches we took to reduce our dependency on colors and take help from other visual elements. We tried using dotted patterns for the line charts, introducing visual nodes and also a monochrome palette.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FZi21N7AmHtJ7jwHw0awH%2F378911b3-f30a-42de-aef0-e0e70d50e2d5.png?alt=media&token=b531522f-db8b-4a17-b176-91f26d91e2a4","id":"378911b3-f30a-42de-aef0-e0e70d50e2d5","width":3223,"height":2040,"filename":"line-chart-explorations.png","type":"image/png","caption":"Line chart explorations","border":false}]}
```

While the charts successfully adhered to theoretical color contrast requirements and accessibility practices, we encountered some flaws when testing them with full-color vision & color-blind users on our dashboard, like:

* In tight spaces, the presence of nodes within the charts made it even more challenging for users to differentiate between the lines.

* The effectiveness of dotted lines diminished when the chart contained more than four lines, as the dotted pattern became difficult to discern.

* Although a monochrome palette improved distinguishability between different lines, it created difficulties in mapping the lines to the corresponding legend keys.

> Sometimes what works in theory doesn’t work exactly the way we want it.

This experience was not in vain. It highlighted the need for better contrast, even for users with full-color vision. Due to the complex nature of multiple graph elements crossing each other, maintaining a 3:1 contrast ratio among them proved unfeasible. These insights emphasized the importance of finding alternative approaches to address the challenges posed by tight spaces, dotted lines, and color mapping.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FZi21N7AmHtJ7jwHw0awH%2Fae3ea350-f985-4bb0-afa7-e6433f5f4a1c.png?alt=media&token=4b492343-ac66-4500-bc3a-6a858b93e514","id":"ae3ea350-f985-4bb0-afa7-e6433f5f4a1c","width":3220,"height":2040,"filename":"bar-chart-explorations.png","type":"image/png","caption":"Bar chart explorations","border":false}]}
```

Similar challenges arose when exploring patterns and a monochrome palettes for our bar charts.

* The patterns used in the bars became harder to distinguish from one another due to their size.

* Utilizing high-contrast colors with a 3:1 ratio (including white) did not align well with our brand identity.

However, we did discover a few effective strategies:

* Introducing a 1px gap between the bar elements proved helpful in enhancing the distinction between bars.

* The monochrome palette worked well in this context because the legend keys followed the same order as the bars, making it easier to establish connections between them.

We also considered implementing an accessible high-contrast mode for the entire dashboard. After careful consideration, we decided that we’ll pursue this option later in the roadmap and focus on fixing the usability issues on the chart level for now.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FZi21N7AmHtJ7jwHw0awH%2Fb6bbe1bd-ac2d-4a9b-bbca-3e904dcd9676.png?alt=media&token=caa4f152-4f41-46a9-a143-a163e173aa15","id":"b6bbe1bd-ac2d-4a9b-bbca-3e904dcd9676","width":1062,"height":730,"filename":"Frame 1073713819.png","type":"image/png","caption":"Preview of high-contrast mode","border":false}]}
```

---

## Solutions

We had to make several trade-offs considering what we uncovered in our explorations implementing accessibility features. These insights imposed constraints on our design choices, leading us to deviate from conventional approaches that could potentially undermine the user experience. As a result, we made the following changes to address these considerations and redefine charts at Primer.

### Updated colors & order

We enhanced the color system by introducing more vibrant colors compared to the previous version. We decided to stray away from the WAI guidelines suggesting a 3:1 contrast ratio between different chart elements. Our testing revealed that it wasn’t helping our use case much since we have multiple chart elements overlapping each other and our requirement to adhere to the brand identity.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FZi21N7AmHtJ7jwHw0awH%2Fb5e25142-8fba-420c-abec-5e583208f23f.png?alt=media&token=b19dc44e-499a-4159-9233-160e78569719","id":"b5e25142-8fba-420c-abec-5e583208f23f","width":2568,"height":2040,"filename":"updated charts.png","type":"image/png","caption":"Updated chart colors & order","border":false}]}
```

The image below illustrates how the color order in the bar charts made it easier to distinguish between the different graph elements.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FZi21N7AmHtJ7jwHw0awH%2Ffbcc548a-3321-4f14-bb9f-fe2c123f1841.png?alt=media&token=fc18e934-269c-4ca8-a0cb-1e3fe434536f","id":"fbcc548a-3321-4f14-bb9f-fe2c123f1841","width":3548,"height":2102,"filename":"Untitled (14).png","type":"image/png","caption":"Color perception matrix for bar charts","border":false}]}
```

### Better legend interactions

Rather than solely relying on colors and graph elements, we expanded our approach to enable more interactions within the charts. By incorporating focus elements within the chart, users can now:

* Hover on a legend key to preview the respective graph element.

* Click on the legend key to lock the respective graph element.

* Use the keyboard to navigate through the legend keys and easily correlate each key with its corresponding graph element.

This improvement significantly reduced the reliance on color when multiple chart elements are introduced, enhancing accessibility and inclusivity for all users.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FDYL8qOdLgqRUxMTsvLNi5u64j0s1%2FZi21N7AmHtJ7jwHw0awH%2F203596b3-a856-4b1d-9fbc-534a5c3b4380.gif?alt=media&token=91600a4b-04a7-42c5-a8ba-a578b545c1c0","id":"203596b3-a856-4b1d-9fbc-534a5c3b4380","width":2824,"height":1530,"filename":"Untitled (2).gif","type":"image/gif","caption":"Legend key focus interactions","border":false}]}
```

---

## Results & conclusion

The project was a big success in terms of increasing the usability of our charts and the Observability platforms as a whole.

* According to Hotjar, we reduced the rage clicks down by 28% in the 30 days after release. (data from 203 sessions)

* Qualitatively, the small improvements were warmly accepted by our users, some of them saying "This is so much better."

Improving usability of Observability charts

We keep hearing that the journey is better than the destination. I agree but what I wonder is why no one ever says the same principle about other situations. Is playing a sport better than winning the game? Is the drive better than reaching the store? Is baking a cake better than the cake itself. Well, sometimes it is, sometimes it isn’t.

I was recently talking to a friend of mine and the conversation steered into what smartphone she would buy in the coming days. Turns out she was planning to NOT get her desired phone just because she didn’t get a good bonus. I was baffled because I know she doesn’t need an extra bonus to get that device. She felt that her bonus is a metric to evaluate if she deserves the device or not. For her the results, sadly, far outweighed the effort she put into her work.

The axioms we use for journeys and destinations are nothing but mere metaphors. Your journey is a process and the destination is a result, and you are the force that puts all the effort. When you think of them in terms of process, result and efforts, they start losing their direct relationship. You can get the same result via multiple processes. The same process can yield multiple results. The effort you put into the process affect the shape of your results. But if the results are unsatisfactory, does your effort get the blame or your process?

Marathons are an immaculate sport, where a number of people run to finish a 42km stretch. The podium only allows 3 individuals, who make it till the end, to take their claim. For the rest who didn’t manage to complete the race, can you say they didn’t run? Everyone puts in their best effort and for some it bears fruit - the one they wanted. Here arises a disparity in scale, the results everyone wants is the same and there is a minimum effort required to achieve that result, but the best each individual can do is highly variable. A marathon runner who gave their best effort but didn’t manage to get the podium, do they deserve a cheer or not?

The final destination of our lives is (*softly)* death. It is the only singular act we all will perform in all our individual and collective grace. Prior to this destination, all of what we do is part of the journey. And this journey is made up of a series of overlapping journeys and destinations like running a marathon or baking a cake. All our momentary destinations are the ones we chose to acknowledge. There are often more than one result which we consciously or subconsciously ignore for the sake something measurable. This varies from person from person, and we’re great at evaluating the whole journey on the basis of that “something measurable”.

All I can think now is how I’ve myself beaten myself up keeping a tunnel vision on these lucrative results. I was no longer reading for joy but to score good grades. I was no longer playing basketball for the energy but just to win that tournament. I was no longer having fun with decorating my room because I’ve to move cities again.

Maybe we can take a step back from the destinations for a while and see where the journey is taking us and how it’s making us feel. Maybe we’ll find something completely new, maybe we’ll reap good results, maybe the cake will actually turn out good. If not, I’m gonna try again and enjoy it.

Enjoying efforts

Untitled

It was the summer of 2021, I was just about to complete my internship at Axis Bank working on their design system, Subzero. I had the best time working there, good problems but better mentors. It was my last college semester and I had to figure out what to do next. Should I start cold emailing again or should I do something more risky? What did I do? I replied to a tweet. It was Dann Petty’s tweet asking for people to share their portfolios so that prospective clients can discover them. And I got discovered. A few calls later, I started my first freelance gig as a product designer. It’s been 2 years so far and I haven’t looked back since. My advent into freelance was rough, unprepared, and daunting but there were quite a few things that I learned along the way.

What separates being employed as a designer and being a freelance designer is what you represent in public. Being an employee, your design opinions and quality of work are perceived as being attached to the company you work for. It adds to the maturity and recognition of the company, you’re just an enabler for it. As a freelancer, your work represents you, regardless of where you work. It becomes part of your brand. And your brand becomes you. Your brand is the pitch deck that flashes through everyone’s eyes when they think of you. More than anything, having a brand builds trust. A client needs to know if you can do the job and having a strong brand reinforces their trust in your craft. This is why bigger companies go with creative agencies instead of hiring a novice freelancer. Bigger agencies have a stronger brand and hence come out as more trustworthy. Getting to that level as an individual takes work, get comfortable with that idea. No need to beat yourself up just because your work is not on par with the agencies. Also, not every company can hire a big agency to delegate their design efforts. This is where you come in.

The general idea is that you should show how you work and what you work on. You need to show your clients that you can do this job and you can do it right. A brand could be anything public facing. For me, it was two things. First, making a design portfolio. It was a representative of my work and my own practice. Second, being active on Twitter. If you’re a nobody and want to be seen, you need to put something out there to be seen. And posting on Twitter did just that. It made it easier for people to discover me which led them to my portfolio. If the portfolio resonated with them, the job was done.

There are two ways of getting discovered and finding leads - inbound leads and outbound leads. Social media and broadcasting your work gets you inbound leads i.e. people reach out to you with work “for you”. Outbound leads mean the opposite i.e. you reach out to people to find work. Best way to do that? Cold messaging. I say cold messaging because it can be anything from a cold email to a cold DM on LinkedIn. How to cold DM is an art of its own and beyond the scope of this article but here’s a [great guide](https://tkkong.medium.com/a-guide-how-to-cold-email-e105a67ebd74) by [TK Kong](https://twitter.com/thetkkong?lang=en). Pro tip: Always follow up twice.

Another way freelancing gets different is your flow of income. A salary is a consistent flow of income that seems stable for most individuals. Freelancing is a series of projects for which you get paid. It means that there will be days when you don’t have a project and hence no income. On those days, your job becomes to get projects. And you know how to do that - Get discovered and be on brand. When you’re just starting out, it’ll be harder to get clients. Hence, I recommend that keep looking out for clients all the time - even when you do have an ongoing project. If an opportunity comes, get on a call with them, discuss their needs, and let them know you don’t have bandwidth now. Even if you don’t get the project, you got a connection. That’s what all networking is about. For days when you don’t get projects, it’s good to have some money in your savings as a safety net. Personally, I recommend keeping 6 months of expenses as your safety net at all times.

If you’re fresh out of college or doing a full-time job, don’t quit your job and start freelancing. Instead, make something tangible that you can show to clients and start broadcasting it. Let yourself be discovered. Once you get a project, start working on it alongside your job i.e. moonlight. I know it’s tough, but it’s much safer than quitting your job. Keep that up for a few months. In these months you have to do two things - expand your network & get confident in your work. Once you feel like you are ready, take the leap.

Let’s say you got your first lead. You’re so excited that you can move a mountain. They ask you to set up a call to discuss the details and see if you’re a good fit. The rush is real but you don’t have the project yet.

Getting a project or not depends on these 5 events -

* You got noticed.

* They liked your work.

* They have a job vacancy.

* You are the right fit for the job.

* They could afford you.

Since they asked you to set up a call, they did notice you, they did like your work, and they “may” have a job for you. This is why having a portfolio is important. People can know a lot about you way before they reach out to you. That’s your very first impression, make sure it’s a great one. This call now is for them to check if you’re a right fit for the job and if you are under their budget.

Going into a call unprepared is not professional and it can sometimes make you lose the client. I like to do two things before I join a call with a new client. First, I research & learn as much as I can about the company so that I can know the significance of the project, find points to drive good discussions, and make decisions on the go. This shows the client that you know what you’re doing and hence reinforces trust. Second, I set up a base hourly rate I would charge for the project. I keep a number for the hourly rate so I can calculate the project details on the go, be it a weekly project, monthly project, or a fixed-price project ([Raycast](https://www.raycast.com/) helps a lot but you can use a spreadsheet too).

For example, I set my hourly price to be $50/hr (not a real amount) and I can work 2 hrs/day since I also have a full-time job. The client says they need a website and they are willing to pay on a weekly basis, time is not a constraint as they want revisions. In this case, the weekly rate would be ($50/hr)*(2 hrs/day)*(5 days/week)=$500/week. You can do any kind of calculation like this. If they want the project to be done in a time constraint (like a month) and the work is too much, charge higher and go for a fixed-price project. Here, you’re left with your own judgment of how you want to charge them based on your speed, time commitment, and execution quality. For me, if I have to work twice as fast, I’d charge twice as much. This is why you should never go for a rate charge for a time constraint project - the faster you work, the less money you get.

Okay, call prep is done. You know stuff about the company and you know your price. The rest of the call can go as you and the client wishes but when you get to the price part, don’t say your price first. This is where it gets a bit tricky. The client wants to get the job done at the cheapest price and you want to get the best offer out of this client. The one who says the number first loses. When they ask for your rates, say that it depends on who you’re working with and you’d like to know their budget first. Personally, I charge more if I’m working for a company and much less if I’m working for an individual because the value my work brings to them is different. In the best case scenario, they will say their budget right away. If it’s below your calculated price, either you can take the project (you’re being undervalued) or you can tell them that you can’t work on this amount as your project rates are <Enter your calculated price>. The client will either stretch his budget or decline, either way, what happens next is pure negotiation, and you’ll have to learn that skill on the job. During your beginning days, it’s completely okay to work for less, you’re building relations and they are more important to you at the moment than money. That being said, never work for free - neither will it make you satisfied, nor will you do your best work. Freelancing doesn’t work if you half-ass your craft.

If you do get the job, you’ll see that all the 5 events I mentioned before happened. You got noticed. They liked your work. They have a job for you. You are the right fit for the job. They could afford you. Mission successful.

Finally, you got your first project. Your responsibility now is to do a good job and deliver. No, let me correct myself - Overdeliver. By overdelivering, I mean doing something of value apart from what they asked for. You do something extra for them, free of cost. It’s a gesture. It makes the project more than a simple transaction. And they remember you. Next time when they have an opportunity to recommend a designer for someone, they’d recommend you because you overdelivered. This is how word of mouth works. You did more than what people usually do. In my projects, I have been hired as a designer but I’ve helped in product, I’ve shaped ideas, and often solved small engineering issues. It goes a long way.

During the project, it can be easy to get lost in your work. I always keep reminders to check in with my clients and collaborate with them. This helps them understand what’s the progress of the project and shows full transparency of your work. The answer is not micromanagement, it’s collaboration. How & when should you share is something that you’ll learn on the job and it varies with each project. You would also have come to an agreement about your compensation and it’s breakdown. Make sure that you send your invoices at the right time (& for the right amount).

Getting a successful lead will be hard when you’re just starting out. 100 people will see your portfolio, 10 will reach out to you with work and maybe 1 will agree to sign a contract. This is pretty much accurate. The thing is, you don’t have to worry about the 100, you just have to focus on the 10 that reach out to you and make sure that most of them sign a contract. That can be all of them or maybe just one. Because in the end, all you need is one client to start out.

This is but a small part of what freelancing is all about. More than anything, it’s a way of managing yourself with utmost precision. I will not say that you’ll be alone in this journey but it will certainly feel like it because there would be only a few people to guide you as you grow and you’ll rarely find those people to be the ones you work with. But if you do, you got lucky again. Collaborating with another freelancer could be a fruitful experience. It’s a gateway to learning about their way of working and freelancing, both would be extremely helpful to you if you’re just starting out.

I’m not here to convince you to start freelancing but if you do intend to venture in - welcome to the ocean, there’s enough water for all of us to swim.

I may be writing more about the intricacies of freelancing, I’ll see you then.