For the ones that haven’t heard about design tokens, I recommend watching one of Jina’s talks who introduced the topic when she started working on the Salesforce’s design system Lightning, and you should check out the design tokens community that takes care of the design tokens syntax and specification, trying to unify the token file formats.

I’ll try to cover our approach and the biggest challenges when deciding on how to proceed by building a design token eco-system with a common language.

Choosing Chakra as a frontend UI library

You can always start building a design system in Figma on the design side. But not syncing with the engineers in the beginning would be a big mistake. It’s much easier to work together if you agree on how you will build both the tokens and the components up front.

Hence, we first wanted to land on a decision on which frontend UI library we were going to use. We were looking for something that works with React, we knew that we wanted to go fast (so we didn’t decide on building every component from scratch), and we selected several libraries that our frontend engineers tried out with a small demo. Besides that, we also checked out whether there are frequent updates and an active community so we knew that the library will be updated regularly.

We landed on a decision to use Chakra UI. Chakra is still quite new, so we knew that a lot of the components we needed won’t be available (e.g. a date/time picker or rich text editor). For anything missing, our engineering team were willing to include other component libraries and customise them to our needs when needed, and building the rest of the custom components from scratch.

Chakra has tokenised components by default (every value that is passed on in a component comes from a single file / source of truth) but they also support semantic tokens. It was a great decision to go with them, having the flexibility to adjust some of the tokens in code directly when needed, in order to fine tune them with the tokens we passed on from Figma.

Conditional tokens are also used, so we could very easily adjust our tokens and palettes if we wanted to introduce dark mode in the future (which we already planned on doing from the beginning), or override a specific state that we didn’t prefer in the Chakra approach (e.g. the shade of the focus color that was not part of the assigned color palette).

The components themselves also support creating variants of the same component, which was very close to what we had in mind in the Figma design files, and it was pretty aligned in the approach we already used.

Overall, their basic styling approach is to have a palette of colours that they apply as a set to any component and use specific shades for different states, and an array of values for sizing and spacing that they apply in the background, but in the components you can choose the component size by using pre-defined t-shirt sizes like “xs”, “sm”, “md”… That gave us the flexibility to both use their native tokens and still apply our own tokens when we wanted to.

Of course, Chakra came also with a fully responsive behaviour and the capability to adjust your custom components with props where you pass on media query sizes without even writing one line of CSS for this. We didn’t need a completely responsive version for our dashboard, but we leveraged this feature wherever we could.

Kudos to Chakra’s team for the approach they used for both providing a great foundation but also an enormous flexibility for adjustments and customisations.

Connecting Figma to the codebase

Having in mind that Chakra already used a specific format for their tokens, we needed to find a way to export the design tokens from Figma into a format that is the same (or almost the same) to Chakra, being able to easily re-format it in code if it won’t match.

We explored the following plugins:

• Toolabs: Looked like an awesome tool which provided customised output of the file token formats, but we noticed that it hadn’t been updated for several months and after a brief chat with the author who said he’s deprecating it, we decided not to go with it.

• Figma Tokens (now Tokens Studio): It’s by far the most extensive and flexible plugin, but unfortunately it didn’t provide a format that would be useful for us to use in Chakra. They include the internal Figma tokens with “_” and “.” that are supposed to be ignored in Figma’s native behaviour, and the biggest downfall for us was to store all possible tokens in the plugin and apply them from the plugin itself to the whole design file which is a bigger risk on the long run. We still preferred to use the native styles for colours and typography provided by Figma.

• Design Tokens: provided a very interesting approach for the spacing and sizing tokens, which was to create a component with a certain width whose value is passed on as a token value. They also have a customisable settings for the format which was very convenient to adjust to the format we needed to import in Chakra.

The pitfalls of choosing Design tokens

The biggest pitfall of not choosing Figma tokens over Design tokens was not having the spacing/sizing tokens available to apply directly to our Figma components, the design team had to learn them by heart and document them properly for the engineering team.

The other pitfall was that it was a bit more difficult to pass on the file in the codebase being able to update through Github (engineers had to create .yml file for this). Unfortunately the file size that we got to pass on was also an issue, and once we hit a specific file size, we were limited on using the expanded/uncompressed format and had to use a compressed JSON output file. Not using the uncompressed file limited us to clearly view the changes of the file in Github whenever a token was changed.

The compressed file size eventually became an issue as well, so we had to compromise on defining all possible component-based semantic tokens that we wanted to pass on from Figma, and stick to the most basic semantic tokens we could define.

I still hope that Figma will integrate all functionalities for the spacing and sizing tokens into their native app and will provide a way to skip the plugins overall… fingers crossed :)

Translating the token values

We also briefly explored Styled dictionary which can transform and save every token in the codebase and reformat it to other types of files, very convenient if you also pass on the tokens to mobile apps in .xml or other formats instead of JSON.

But for us it didn’t provide much value and we decided to translate some of the tokens in code with a custom script that we could have a bigger control on, and not adding one more tool in the whole eco-system.

The design to code eco-system

So, finally we ended up with something like the following chart:

1. Exporting the tokens via the Design tokens plugin

2. The JSON file was passed on into our Github account (we created a bot account that handled the generated pull requests)

3. Then our engineer Kire created a javascript file that slightly adjusted the tokens into the format we needed in Chakra (so I called it Kire.js :D)

4. We overrode the default “teal palette” with our “purple palette” which was our primary color to override all existing components, as well as the main font family

5. We continued to use Chakra’s native tokens, but also introduced semantic tokens to override some values for Chakra’s components (like changing the hover colours of the outlined button version) or use them in custom components

We wrapped all Chakra components into our own components, to be able to handle any updates in the library that might come unexpected from Chakra. We created all necessary components in Storybook where we showcased all possible variants and states of the components. The frontend engineers from other teams could just copy the code and use the component as is, directly into their scope of our new Dashboard.

We had an extensive documentation in Figma and we held several presentations and live coding session to pass on the knowledge to every designer and frontend engineer in the company, so over time we had a huge improvement of the usage of the components and how engineers customised the components.

The troubles of naming semantic tokens

Colours

As Mia explained in the first post, for the colours we used the foundational 10-shade palettes that we didn’t really use in Figma, but were directly applied to the Chakra brand theme provider.

It was fairly easy, Chakra uses color palettes for their overall styling schema where they assign a color value of a scale of 10 different shades from the same palette that we already used as an approach in Figma, we just needed to shift some numbers to adapt it to their format of scale (to use “colour.500” as main, “colour.600” for hover, “colour.700” for active state, etc). We did use the semantic naming for every override and a custom component though, so we didn’t have any loose naming around the code either.

We used the following approach for the semantic color naming: defining a “primary" as a non-colour name but its function, then added the rest of different props and states which included the information whether that’s a background or on-top-of-the-background colour. So both designers and developers know that if you have $primary.main as a background color, you should simply use $primary.onMain as the text colour on top. Viktorija has explained this approach pretty nicely in her blog post “Setting up the most flexible design colour system”.

For the dark scheme that would eventually come, with this approach, we could just use a different palette directly in the Chakra provider that will cover all the dark mode colours with the same naming.

We ended up on a design token naming system similar to the following, where we took the liberty to leave out some of the levels that were really not necessary to define:

[function]-[context (background/onBackground)]-[property]-[state]

We used the same approach for defining all colours that are applied to every form / input type of component so they are all consistent without any shades being mistaken and we avoided any loose ends.

The border of inputs was a specific challenge, cause we had to work with a default border colour, border hover colour, border colour if the input is in focus, but we also had a “danger” variant where we change the colour based on the input state :) We kinda figured it out along the way and this was the most complex naming variant that we went with in “Stream”.

Typography

Translating the typography into the codebase was a bit different since Figma exports everything in pixels, while in code we want a more fluid unit that we could scale up the whole app by zooming in or using responsive styles.

Here’s what Figma exports via Design tokens as a typography style “object” for our text style “text-xs-regular” defined in Figma:

"typography": {
    "textXsRegular": {
      "description": "0.75rem",
      "fontSize": {
        "type": "dimension",
        "value": 12
      },
      "textDecoration": {
        ...
      },
      "fontFamily": {
        "type": "string",
        "value": "Inter"
      },
      "fontWeight": {
        "type": "number",
        "value": 400
      },
      "fontStyle": {
        "type": "string",
        "value": "normal"
      },
      "fontStretch": {
        ...
      },
      "letterSpacing": {
        "type": "dimension",
        "value": 0
      },
      "lineHeight": {
        "type": "dimension",
        "value": 16
      },
      "paragraphIndent": {
        ...
      },
      "paragraphSpacing": {
        ...
      },
      "textCase": {
        ...
      }
    },
...
}

We first used the description field to add the value of the font-size in rem units directly into the file, but it’s not scalable since we also needed this for the line height, letter spacing, etc, and probably needed to parse a big string afterwards.

So, our engineers wrote a small script that basically put the appropriate calculation for the appropriate unit, knowing that we come from the 16px base font size for the whole application and that it translates to 1rem in the code. So it turned out to be a simple math :)

The letter spacing is the only value that is not exported in pixels, but in em so, this only required to add the specific unit. We didn’t parse the rest of the values because we didn’t use them in the design either.

The font family was set once, directly in the theme, and we didn’t really fetch it from the tokens file.

import { getTokenValues } from './formatTokens';

const typography: any = getTokenValues('typography');

const baseFontSize = 16;

export const typographyVariants = Object.fromEntries(
  Object.entries(typography).map(
    ([key, { fontSize, fontWeight, letterSpacing, lineHeight, textCase }]: [
      key: any,
      value: any
    ]) => [
      key,
      {
        fontSize: `${fontSize / baseFontSize}rem`,
        fontWeight,
        letterSpacing: `${letterSpacing}em`,
        lineHeight: `${lineHeight / baseFontSize}rem`,
        textTransform: textCase,
      },
    ]
  )
);

Sizing and spacing

Sizing and spacing were a whole different challenge since they are not yet supported in Figma like the colours or typography styles.

Chakra have their own sizing and spacing scale, that was missing some of the granularity that we wanted to introduce, so we created another system that worked better for us and passed them on as sizes/spaces tokens.

We only used the sizing tokens specified in the Design token plugin for both sizing and spacing, just used different naming. We didn’t use the spacing tokens format, since we wanted an individual padding/margin control instead of a group of 4 values for top/right/bottom/left that they supported.

This was of course, not enough, so besides standardising some default values like “space-md” being “16px” (highlighted in purple), we also introduced some additional semantic tokens that took the values of these basic tokens.

We used them for the detailed component specifications, custom components and all the overrides of the existing Chakra components. We paid most attention to the form elements and spacing between different types of content (form gaps, different titles sizes and descriptions that follow, between different button sizes, layout paddings, etc). We also introduced our own custom form containers that were more suitable to our designs than the default Chakra values.

We could have broken the semantic tokens even in more detail, for example creating different token for each component (e.g. text input, text area, rich text editor, date picker, time picker, etc). But we really wanted to be able to control the same tokens from one place and not introduce complexity without really having the need to do so.

The biggest downside for the designers were to come back to this file all the time to check and apply the appropriate value to the component in its auto layout properties instead of just using the token name as we do with colours. As said before, we’re looking forward for Figma to actually implement native spacing and sizing tokens that would really facilitate the whole design and handoff process.

Border radii

For the border radius we used the same system of the native Chakra tokens, and even though we passed our custom tokens with the same values, we did continue to use Chakra’s native radii tokens and just override some of components’ values (e.g. downsized the value of the border radius on the checkbox).

They are also not supported natively in Figma, so we figured it’s better to use Chakra’s tokens in this case. We just specified in a document which value is used in which component, so we can keep our designs consistent.

Shadows (effects)

The shadows are effect styles in Figma and they are exported as a group of values. We had to parse them into our codebase which would cause another code bloat, so we decided to define the shadows as a CSS value string and pass it on through the description field of the effect and JSON file.

This was mostly done due to the opacity value - we didn’t want to parse the hex value and we used the RGBA color format that included the Alpha channel. But it also enabled us to pass a CSS variable as a semantic colour, for example, to override the focus state of all components.

    "shadowSm": {
      "description": "0 1px 4px 0 rgba(29, 41, 57, .1)",
      "type": "custom-shadow",
      "value": {
        "shadowType": "dropShadow",
        "radius": 4,
        "color": "#1d29391a",
        "offsetX": 0,
        "offsetY": 1,
        "spread": 0
      },

Final thoughts

Could we do this whole thing better? Of course.. we did some smart decisions, but we also failed some. Defining the semantic tokens were one of the best approaches we used, especially cause they kept both the designs and code very consistent throughout our daily work. We could have introduced even more of the semantic tokens if we didn’t have the file limitations, so we could really control the values from Figma directly.

Overall, we are quite happy of what we developed during the past year!

We’re still definitely looking forward to Figma working on the topic of design tokens and have everything done from the same place, in the formats we would need or just in the design token specification. That way we would get the flexibility to pass on values to our codebase in a usable manner, while simplifying the work of the designers and engineers, and keep everything consistent through a well-connected design system.

This December I’m celebrating my first anniversary as a product designer at InPlayer. It is also the month we launch our new, completely redesigned self-servicing dashboard that we have built in only eight months. The way the design team achieved this in such a short period is thanks to our structured design process. Our Design Director Sandra previously wrote about how we organize the Design team at InPlayer. As a follow-up, I want to expand on how we customized the design processes to our needs and cherry-picked techniques and tools that suit us best during the complete project life cycle.

At the very beginning

Whether we start a feature from scratch or redesign an existing one, we communicate the high-level goals with the PMs. The aim at this point is for everybody to be on the same page and understand the crucial elements, the problems we might be facing, and the goals we want to achieve from both user and business perspectives. 

Since designing for the user experience addresses users’ pain points, we form an understanding of the problems they face and come up with the questions we need to be answered to get there. And that helps us create a design success strategy.

At this point, we are very curious and have tons of questions about the product. This is the crucial moment when we have to slow down and think about all the questions and assumptions we have before thinking about solutions. It is easy to develop design ideas, but it’s hard to solve the right problem. Building a product with lots of unanswered questions introduces risk. To avoid this, we like to take some time to prepare a good research plan.

In tune with the user

We start our research plan in Notion. This is where the questions we will use for our interview sessions are our first project artifacts. We frame the questions more open-ended to avoid prematurely building the solution into the statement. Even more valuable is having team members participate in the question brainstorming, usually the PM, so we can have more diverse input.

After reviewing, sorting, and prioritizing, we have a straightforward question in mind. Now we are ready to turn them into a hypothesis and think about how we would answer them. It’s crucial to have a measurable outcome for the thesis to determine whether it succeeded or failed. Conducting user interviews is one of the methods that has proven to work for us. If we work on a redesign and have an existing product version, we combine it with usability tests. We talk to people, try to understand how they think, act, and feel, and take many notes during the process. We are fortunate to have our CAB (customer advisory board), our base of customer representatives who are willing to help us anytime with such sessions. Also, colleagues from the other company’s departments, like customer success, sales, and marketing, are the ones that are always here, helping us a lot in answering our questions and confirming our assumptions.

Performing 3 to 5 sessions helps us start seeing the patterns, validate or invalidate our hypothesis, answer the questions, and at the end, state the problems. Writing a report helps us summarize all of the notes well organized by the severity of the problem. The idea is that everyone on the product team can easily understand the most significant users' pain points and state their biggest concerns. We present the reports at a weekly Product review meeting where we analyze and discuss them together before proceeding further. When we design a possible solution in the ideation process, the problem statement will serve us as our north star. 

Describe the scope

So far, our favorite way of analyzing our research findings is through creating user personas and journey mapping.

We use user personas to step into the shoes of our customers. We form them by defining their: age, gender, location, occupation, behaviors, budget, needs, and pain points. If we ever encounter a challenging problem, we always refer back to our persona and ask, “What design best services this user needs?” And we don’t narrow down all of our target users into one persona; we create multiple personas to represent our varied users.

We create a user journey map to help us understand what our users will be going through when using our product. Only then can we build the best product for them.

Representing the user’s interactions with our product, we believe that the journey maps are beneficial for 

• Building empathy

• Providing a “big picture”

• Breaking down silos

• Bringing focus

• Revealing opportunities

At the end of this phase, with the problem statement in mind and in close collaboration with our PMs, we write down the requirements and the user stories we need to start working on the solution.

Extract a lot of ideas

After defining precise requirements, we look at the problem from different perspectives and start to ideate. All designers use different ideation techniques and approach the solution differently. But we all collaborate, try to think outside the box, and explore new angles. Workshops can be organized if needed and don’t always have to be very structured. It’s all about creating as many ideas as possible. It’s an iterative process, and we do not get it all done in the first go; we design, redesign, scrap it and design it all over again. We explore many designs using Figma and our well-known design system. There is a blog post from our dear colleague and design system principal, Mia, where you can read more about Stream - InPlayer’s design system.

Prototype the solution

When design systems were not “the thing,” I used to make prototypes with sketches or wireframes at the very early stage, not focusing on the details but on what needed testing. Now, with our design system, with all rules defined, compliments and patterns created, and even ready-made page templates, the actual design work is more straightforward. We can make high-fidelity designs and focus on the details from the beginning.

At the end of a creative iteration, we are ready to showcase our work and ask for feedback. On the weekly Design team sync/critique, we present the prototype to the design team first. That is the time to get a valuable opinion from the other designers. I love how we all think in different directions and cover many design aspects. Usually, we announce when someone has something for review in our Slack channel a few days before the meeting so we can have it on the agenda. If some design needs quick feedback and can’t wait until the meeting on Friday, we can just send a Figma link in the channel, and the designers will review it when they can and leave us feedback in the form of Figma comments. Whatever the form of feedback is, we have agreed that whoever designer is presenting the work needs to follow these practices:

• Set the objectives. Before starting the critique, we reiterate the goals of the work—a quick reflection of the persona, current pain points, user tasks, or previous flows. Sending out the work beforehand with written objectives is our practice to avoid the initial reactive feedback based on someone’s gut reaction.

• Present quickly and efficiently. We like to be concise. After presenting, the team can circle back to something that needs more discussion. Sometimes we let other designers see our work as our users may, without much explanation. During the subsequent discussions, questions and explanations will arise naturally.

• Pre-prepared designs. We always have them on a separate Figma page, named appropriately by the design version with differences pointed out and the reason we made them. It is good to have the designs available after the meeting in case an extended discussion is needed or someone comes up with an idea later. 

Scheduling individual follow-up meetings is also a case if we need to discuss anyone’s feedback in more detail or if something we work on conflicts with someone else's work. Such sessions can happen at any stage in a design process, and usually, there will be different critique sessions for several iterations of the same design.

After “passing” the design team review/critique, the prototype will be presented in a weekly review session to the Product team. Here we get feedback from the PMs and the CPO. Having varied disciplines in the room always brings fresh perspectives and leads to a more productive outcome. Then we communicate the solution with the engineering team and make sure that the solution is technically feasible. Presenting the work doesn’t end here. We show it at the company’s monthly town hall sessions. And if we iterate the design, we do all presentations repeatedly.

Prove the validity  

It is already clear that, as designers, our job is to ensure that we create practical and usable solutions. But what does it mean? How can we be sure that we did it right? 

There is only one way to find out - test the solution. We start validation well before the product gets built and shipped. Before our team determines whether that new feature we’re building is delightful and easy to use, we run prototype validation to pinpoint critical elements or interactions. Sometimes we find out that many of our ideas won’t solve the problem, and that’s a good thing to find at this stage.

​​The value of including prototype validation is in getting answers faster. Even if we fail, we fail fast. We always have PMs and/or other designers in the validation process. The designer facilitates the session, and the PM is the note-taker. The testing candidates are usually the ones we did the interview session with earlier in the process. Later, we share the results with other stakeholders. They shouldn’t have to rely on our interpretation of what the user is saying, and we make sure they learn from the user directly, so no matter what the next step is, we are all aligned that it relies on data. 

Hand it over

After doing a ton of a great job, and we are sure that we have a version ready to go into development, we do two things: sync with the devs once again to confirm the technical feasibility of the designs. The second, and one much heavier, is creating a well-rounded, in-depth handoff document. Multiple information layers must be conveyed when a design is handed over to the developer. Marking each section’s progress, the devs know what’s work in progress and what is ready for implementation. Using local components we wrap the design system components with relevant content for the project. We describe the interactions in as many details as possible. The research plan and the latest prototype are also linked here. Ultimately, we make sure we mark everything accordingly and attach the document to the relevant tasks in sync with the PM.

In addition to the screens, interactions, and copy, one must share the design system components, specs, and tokens. All these cover different aspects of the design solution and need to collate into one organized piece.

Screens

First, we must name the screens accordingly and ensure that the file name does not possess any versioning. The name of the screen simply describes its function. Plus, we make sure we use consistent casing when naming the screens. Second, archive the rest. At the time of handoff, we collectively chose an option we would build. That is why we highlight the latest version and archive all the older iterations & explorations. 

Interactions

Link the latest prototype. It helps understand how the user journey is panning out and allows the developer to plan their approach to code. We add explanatory comments to emphasize specific flows, interactions, or what gets away with platform-specific standard interaction patterns. If the interaction is simple, we do not spend time writing comments about it, and if such an interaction pattern exists, we just add a link to it.

Copy

This is something other than what we as designers do or should do, but we have made some input, even though the majority comes from our Support Team Lead Nikola, who always suggests the best copy for our designs. As a design team, we agree on a Design system copy for consistency, ex. When to use “save“ and “save as“ as a label for a CTA button. We have to include the final copy of our designs in the handoff document.

Design system component

We want to break down the screen and point out what design system components are used, describe the variants we use, and link the component from the design system where a component description and tokens can be found.

Specs and tokens

We have a screens section named /Specs next to each screen. That section is with highlighted design specs usually highlighted using the Outline Figma plugin, and then we write appropriate tokens next to each outlined area.  

Last but not least

We specify the max/min sizes of the component and communicate the breaking points and other responsiveness-related information.

Verify the outcome

Limited resources, technical issues, and the timing of releases can impact even the best design implementation. As the design gets passed on from the design teams to the engineering teams, each team can change according to various temporal issues, leading to significant misunderstandings. Ultimately, we realize that the final product doesn’t correspond with the design team’s result.

The designer’s work doesn’t stop when the design goes into implementation. During this phase, we must evaluate whether the developed product aligns with the design teams’ vision, technical possibility, and user experience. In other words, reviewing the developed project helps verify that all visual and technical components are displayed and behave appropriately. 

Closure

With many product design processes, the challenge is choosing the right one. Every specific product, team, and company has different needs and goals. But we naturally adopted all the processes to our needs and with good reasons. We believe that having our design process in place doesn’t just give our users an intuitive and pleasurable experience but gives us a chance to iterate and improve our designs and learn along the way doing it.

But all that was not the core of the problem. The main problem with our analytics and reporting offering was that it was not providing our customers the data they needed. In today’s data driven world where business leaders rely purely on data to make strategic business decisions, InPlayers customers were unable to do so because the data that was provided to them didn’t answer their questions. 

The decision to end procrastination

Reporting was the elephant in the room. Everybody was aware that it’s a problem. And everybody procrastinated solving this problem. Because there were more important problems to solve. Until there weren’t. 

We conducted an investigation in order to quantify the problem and found out some terrifying insights on the amount of time spent on crunching numbers - internal and external.

• An account manager spent nearly 2 days per month on creating custom reports for their customers

• The whole finance team spent nearly 3 days per month on creating custom financial reports for internal and external facing purposes

• A customer spent on average 2-3 days per month on creating custom reports, pivoting tables and filtering raw data in order to get to some summarised tables and be able to pull out some meaningful insights about the performance of their business

Until then, the problem had never been quantified before. Everybody knew it was a problem, just nobody knew how big of a problem it was. After revealing these numbers, it was more than obvious that the time is now. 

User research - the key to solving the real problems

As opposed to how we did things in the past, we took this time a “slightly” different approach. Putting user research at the core of problem solving, we reached out to our customers and conducted a series of user interviews. It was not a particularly difficult task to do, because InPlayer has a customer advisory board which is essentially a group of customers the product team talks to on a regular basis for product discovery, innovation testing & hypothesis validation. In return they get early access to new features, freebies, and similar.

There were a couple of things we wanted to find out. 

1. How do they use our current data stack?

We asked the customers we interviewed to share their screen. We asked them to show us step by step their working routine with the InPlayer data. How do they get it, where do they click, when do they get it. Why do they get it? How frequently do they get it?  These questions were important to identify unoptimised user flows on the UI and identify repetitive patterns that can be optimised in the future. 

2. Why do they need this data and what do they do afterwards with it?

The more important question we wanted answers to was - what do they do with the reports afterwards. We found out that the raw exports used to be merged with other raw exports. Our customers then applied filters, pivot tables and aggregations only to come at the end with a basic 2x2 table or a simple pie chart that would showcase the performance of their business. 

The key finding was that our customers, if provided with the right information in the right format, actually do not need the raw data at all. 

3. What KPI’s do they monitor?

During our interviews we concluded that our raw data exports are used by internal analysts at our customers' side in order to calculate some of the industry standard subscription metrics,  like monthly recurring revenue, customer lifetime value and average revenue per user. It was an expectation that as a subscription management service provider we would offer these KPI’s and metrics out of the box. 

Back to the drawing board

Knowing all the information we gathered during the interviews, it was time to get back to the drawing board and start analysing the feedback. 

We usually record each interview and have a transcript of the conversation so that we can come back to it later. All those recordings and transcripts were then transferred to a more readable and eye friendly Miro board. The intention was to identify repetitive patterns, pain points and requests. 

It was a pretty difficult job. Analysing qualitative data was probably the toughest job of all. Not only because of the nature of the task, but also because our customer base is very versatile. From large enterprises to small independent publishers, with one time concert streamers to VOD subscription based offerings, we needed to find out what was common for all these people in their data needs. And the problem was that there was very little that all these guys had in common. We went back to the drawing board over and over again - until we concluded: There is no one size fits all for this job! 

So we came up with the solution that we have today - Business model tailored dashboards. We currently support three business models: PPV, Subscription and a combination of both. So whatever your business model is, you would see relevant data that fits your business model. 

Reinvent the experience - Self served data 

Once we cracked the main problem, it was time to work on structuring the data and figuring out who gets to see what. Together with the product designer we came up with a set of dashboards that fit more than 80% of the problems we identified.

But dashboards are so 2000 and late. We live in the decade of data. And we live in a data driven world. We can’t always rely on analysts to get us the data we need. Executives and decision makers must be able to quickly get the information they need and make decisions on the go.

We put self served data at the centre of the new user experience. We came up with a solution where customers would not need to drag and drop measures and dimensions onto X and Y axes in order to find out what the monthly churn rate has been over the last 6 months. Our solution simply enables our customers to search for it: Churn rate last 6 months. 

The solution gives a wide range of self served options for data analysis. A graph can be sliced with colour by a dimension so that users can segment the data and gain more insights, there are filters on widget and on dashboard level, the explore mode lets our customers customise the graphs to get exactly to the visual they need, and there are options to add time filters and compare and replace existing data. All in the manner of self-serve. 

Validate, validate, validate

Now that we had put it all together, we had to validate the solution with our CAB members, to see if it actually made sense. 

Validation consisted of another round of scheduled user interviews where we handed our customers a clickable Figma prototype and asked them to use it and tell us what they saw. The key was not to guide them, but rather ask them to perform an action and monitor if our solution was intuitive enough so that they use it the way we intended it to be used. We had to see if the data provided to them was clear, self explanatory and meaningful. If not, that meant that we would have to go back to the drawing board again. 

Luckily enough, our solution was pretty intuitive and satisfactory. After a couple of iteration rounds and small improvements that we implemented during the validation, we were confident that we have the solution that is worth building. 

Measure success

The product work doesn’t stop with the validation. As we have just launched our new dashboard as a Beta to a limited set of customers, it is the next goal to monitor user adoption and DAUs/WAUs. Based on current product usage, we aim for 30% of the migrated customers to the new dashboard to be daily active users, and 90% to be weekly active users.

Our go-to-market strategy also involves a customer satisfaction survey, from which we would derive (again) qualitative data about the satisfaction level of our customers from the new analytics experience, but also a quantitative measure on how satisfied they are. We aim for a score higher than 8. 

If not achieved, you already guessed it - we’ll have to go to the drawing board again.

Conclusions

A huge part of product work is a very thorough process of identifying the biggest problems users have. We must never start building something unless we’ve made sure that the problem is worth solving and what the outcome of that will be. Investing in time and resources for a thorough research process accelerates the identification of the problems to be solved and helps product managers and executives in making decisions on prioritisation. And it is without a doubt that only product-led companies understand the need and the benefits from investing heavily in user research and validation. 

Welcome to our 3-part case study where you’ll learn how, in 8 months, we built an extensive design system from scratch. We will walk you through all aspects of building a design system, including DS principles, foundations, component best practices and how we integrated design tokens.

Intro

Why a new core experience and a design system (DS)?

The initial version of InPlayer was created in 2010. Since then, the product has expanded significantly, but due to a lack of a design team and design system, the information architecture became confusing, and the UI and UX were inconsistent.

All of our user research led to the conclusion that the dashboard appeared confusing - customers frequently complained that they lacked the confidence to manage the dashboard. As a result, our Customer Success team (Support + Accounts) had to create extensive user manuals, conduct several training calls per customer, and frequently set things up for them.

“I don’t understand how to use the app. On top of that, the app looks completely unprofessional and outdated. I would have switched to another product by now if your competitors had the same features as you do.

But they don’t.”

So, we set a goal to define an MVP and rebuild the dashboard from scratch using a new design system in about 8 months.

Before opening Figma…

As a designer, there aren’t many things that are even remotely as tempting as being given the creative freedom to build a design system from scratch. However, building a design system doesn’t start with choosing your primary colour…

Setting up a goal

The goal that we set for the new dashboard was to build a modern, slick, yet functional and scalable app, that’s self-served. This means that our customers would be able to complete all flows as seamlessly, confidently and independently as possible, without the need for reading long user guides or getting help from our Customer Success team.

This goal became our “north star” and helped us define the goals of the new DS:

• Align all teams by giving them a more structured way to build the product.

• Speed up our design and development process, i.e. focus on meaningful discussions about the problems and the solutions, instead of discussing styles.

• Improve product trust through consistent, familiar and predictable experiences that allow users to accomplish their goals.

• Promote accessibility of the product by crafting all styles and components to be compliant with the WCAG guidelines.

Brand audit

To better understand the current state of our existing design ecosystem, we started with a UI inventory of our main interface foundations and components. As a result of this exercise, we identified a lot of inconsistencies, which only proved the need for a more systematic approach to creating, documenting, and maintaining the new design system.

Plan

The brand audit helped us define priorities and phases for building the DS:

1. Establish the foundations (colours, typography, icons, grids, etc.)

2. Design the most commonly used form components (buttons, inputs, dropdowns, alerts, etc.) and its variants first

3. Build the essential flows and features

4. Slowly build the rest of the components as needed

All of this work was managed in two-week sprints. This was necessary in order to keep each scope digestible, while delivering value in as little time as possible.

Work smarter, not harder

We were aware that we couldn't afford to develop a custom design system on our own because of the rather short timeframe. With the assistance of the developers in the Core Experience team, we carefully examined each of the component libraries that were available and decided to adopt Chakra UI since it met all of our requirements - it’s ReactJS based, responsive, themeable, and contains most of the commonly used components.

The downside of using Chakra UI from a design perspective was that their Figma file was quite weak. Many of the components didn’t look the same as in code, a number of components were missing, some were not responsive and auto layout was not used in many cases.

This made it impossible for us to just copy and paste Chakra's Figma components into our DS. Instead we had to draw every single component from scratch.

Not that we minded…

When we got to the stage of building the foundations and components in our DS, we tried to change Chakra’s styles as little as possible to avoid unnecessary additional dev work. The main changes that we did were colours and spaces.

High level file structure

We followed the atomic design methodology, however we adapted the structure towards our needs. Below you can see a high level overview of our DS structure.

Foundations

When defining all of the foundations of the design system, our main principle was:

Colours, contrasts and tokens

Primary colour

Since InPlayer’s logo is an orange → magenta gradient, from a design consistency perspective it made sense to use one of those colours as the primary colour, but that would have been a bad choice from a functionality perspective. Both of the colours are typically used to communicate warning or error states, so using them as primary colour in a web application can be very confusing and misleading.

Colour palettes

For the primary colour we took inspiration from the lighting that’s often used in cinemas and arena events, and ended up using a “cold” palette, with purple/indigo as a primary colour.

Contrasts

When defining each colour, it was really important for us to also define the allowed foreground shade (aka “onColour”) for each background shade. So for example, on grey/300, the minimum allowed foreground shade of grey would be grey/800 in order to achieve the minimum allowed AA contrast.

We also wanted to achieve colour and contrast harmony not just within each palette, but also in each vertical. For example, since the shade 500 was set to be the main shade in each palette, we made sure that the 500 shade in each palette can be used with a white foreground colour (a combination mainly used for buttons and toasters).

By defining all contrast rules in the DS foundations part, we didn’t have to worry later about contrast in the components, because all of the contrast rules had already been defined.

We mostly used the A11y - Color Contrast Checker plugin, because it allows simple shade adjusting for easier contrast match.

Colour tokens

After defining all of the colours, shades and contrasts, we started defining the colour tokens. The tokens had a crucial role in the consistency of colour usage across all designs and code. For example, if we needed to define a border colour for a form component, we didn’t need to remember if it’s grey/300, grey/400 or grey/500. We simply applied the token form/border and that was it.

There isn’t a single component in our DS with a “loose” style (e.g. Red/300). All components are built with tokens (apart from space, size and border radius tokens, because of Figma’s limitations).

Sizes, spacing and grid

We then continued with defining the base units, because how you define the base units will determine the typography specs, sizes and paddings for all components.

We opted for the commonly used 8pt linear scale for elements, with a 2pt and 4pt half step for spacing icons and other smaller elements, which worked well with Chakra’s own base units.

We use 4pt baseline grid for typography which means the line heights are always divisible by 4. This also ensures that when a component contains text + paddings (e.g. button, inputs, etc.), the height of the component will fit perfectly on the 8pt grid.

Typography

Chakra’s font of choice is Inter. This worked perfectly for us, because that was our preferred font too.

We decided to tweak Chakra’s text styles, because we wanted to follow Inter’s guidelines for how to best use the font, while making sure that all of the line heights fit our 4pt baseline grid.

Components

Base component and variants

At the moment of writing this blog post, we have 64 components in total.

All of the components have been formed by using nested base components so that when we make changes, we only make them in the base component, instead of in each variant of the component.

When we started with the design system, Figma hadn’t released boolean properties yet, so most of the components had a ridiculous number of variants. For example, the first version of the Input component pre boolean props contained 391 variants (with 66 variants in the base component), but after reworking the component to use boolean props, there were only 39 variants (with 26 in the base component).

Accessibility

Making the colour contrasts for each component in the DS to be WCAG compliant is not enough to achieve DS accessibility. Some of the things that we also took into consideration were:

• Hover and focus state on components which ensures that each piece of UI that’s meant to be interacted with, has defined states for both mouse and keyboard interaction.

• Label on Inputs and Selects, as opposed to using the placeholder text as a label, because if a screen reader comes across an input field without a label, it will try to find some text in close proximity to use as the label.

• Validation, error and helper texts on Inputs and other form components.

• Using double visual cues for messaging components (e.g. Alert) - we’re using icons in addition to just using colour to express intent (success, error, warning), because relying on colour alone is not enough.

• Hovering over an IconButton always triggers a tooltip that explains what action the icon represents.

Autolayout

All of our components are fully responsive by using Figma’s autolayout.

Placeholder/slot components

Slot components are one of the best tricks we’ve incorporated in our DS. We use them in all components that need to contain variable nested components or different number of nested components, so that we don’t need to detach the instances from the main components in order to customise the instance.

Plugins

Propstar was also a great find that I stumbled upon on Instagram by chance and it cleaned up our DS massively. The plugin generates all possible instances of a component (given that some of them are not shown if you use boolean props), including every combination of variants and component properties, in a labelled table. Even the most heavy components look simple with this plugin.

Component patterns

ComponentPattern is a component stored in the design system, which has been created from a corresponding component in the design system and then overridden with content that’s fixed and appears on multiple screens on the dashboard (e.g. specific page header, tabs, “Save changes” modal, etc.).

We decided to use component patterns because if we decide to make changes to the overridden instances, instead of editing the content in every occurrence of the instance, we would just make changes in the component pattern component.

For example, the PageHeaderPattern where the title is “Video assets” is currently used in hundreds of screens. If we decide to change the title to just “Videos”, we will just need to change the title in the pattern component and simply update the PageHeaderPattern component in each file.

Documentation

Our Figma documentation consists of two parts:

1. A guide on how to use the component (intended for designers, and devs)

   

2. Tokens documentation (mainly intended for devs)

   

Design fast, test and iterate

Each component in a design system may look absolutely flawless when viewed in isolation as a grid of variants. However, users don't engage with it in that way.

As we were building the foundations and the initial set of components, we were constantly performing visual DS tests. We tested each component in different dashboard pages and UI patterns, in order to be able to see how different components look like when positioned next/close to each other, to test sizes, paddings and margins, and find subtle component inconsistencies.

These exercises helped us identify things that could be improved early on in the design phase, which we would have otherwise missed.

Sometimes, improving a component meant fundamentally altering its structure, which had an impact on the instances of the component used in our design files. Here’s how we handled those situations:

InPlayer Technology

Pro tip: Updating a component's structure in Figma without introducing breaking changes

While working with Design Systems and Figma’s component libraries, we often have to introduce more structural changes that might affect other files that are using our library’s components. We, the design team at InPlayer, have found a way to introduce changes in the library’s components that won’t affect the used instances of the components in current o…

Read more

4 years ago

DS sync meetings

We conducted weekly DS sync meetings with the frontend devs from the Core Experience team, in addition to generating comprehensive design tokens documentation, to ensure that our designs in Figma made sense and to examine the components that have been translated in code.

We also had sync meetings with the Frontend developers from the rest of the teams, so that all teams are aligned with the latest DS updates.

Conclusion

Apart from following all of the guidelines and best practices for each style and component, one of the most important things to remember when building a design system is to know your users and then build for functionality over (just) appearance. Having a Dribbble-worthy DS won't help you attract new users or keep the ones you already have. It’s your product’s simplicity, usability, and consistency that will determine its success or failure. At every stage of building a DS, keep in mind that you are designing for humans with a range of technological proficiencies, as well as cognitive and visual abilities.

Product & Engineering

Let’s start with a short intro, the way we are working together is thanks to our CPO Edit Kovács who introduced a product & design (re)organisation when she joined the company last year.

The Product team consists of 3 Product managers, led by the CPO, and 4 Product designers, led by the Director of design reporting to the CPO. We operate together on the product side, while on the engineering, we participate as part of the product engineering teams.

The four Engineering teams are split based on different areas of our product and each of them have a Product manager (currently two of the teams share one PM), Product designer, and - depending on the product area and the need of specific profiles - Backend engineers, Frontend engineers, Data engineers (in the Analytics team), Platform engineers and QA engineers who are all led by the Software Development Managers (SDMs). The teams are cross functional, and if needed share team members, so whenever we have common projects we join forces with very close collaboration for all the joint efforts.

Product design team

Our team was gathered as a very diverse group with different design skills: we adopted one re-assigned designer from the marketing to product team (junior) and the rest were part of an intentional hiring strategy through all different levels - from intermediate to experienced (seniors).

In the past year, we managed to learn how to work together in a consistent manner, contribute to the common goals, and boost each other’s communication & practical skills. I’m very proud of the culture, open feedback and mentorship approach that we managed to cultivate and how it helped us thrive.

Responsibilities

As designers, we are part of the Product team which has been a great and amazing change for most of us that haven’t worked on products before. Being involved, from the very beginning of setting a goal to prioritising and learning more about our business, was a great way for us to be aware of what’s coming, to be able to adapt to changes and fluid priorities and really contribute to the planning of our chunks of product without any miscommunication along the way.

We were heavily involved in the product discovery phase, participating in all the initial customer interviews and contributing in the Design document which is a living document for a whole initiative’s lifecycle - don’t mind the name - it includes the business case, research phase, reports, as well as designs, prototypes, high-level estimations and technical planning.

Not to get lost about who does what in the whole process and output artefacts, we used the RACI matrix so we clarified who is an owner of any initiative or document, and who just needs to be kept in the loop.

Hopefully we’ll reveal more about the way the product team works in a following blog post.

Documents & templates

In order to facilitate repetitive work, whoever started writing some form of document, we tended to create it as a template and then iterate on it. This kept us consistent and every collaborator outside the design team knew where to find the things they needed. All the research and Figma links are always linked in the appropriate Design document, but we also interlinked whenever we considered it useful.

Some of the documents and templates we created along the process:

• Defining a research plan (Notion)

• Conducting the necessary research items including interviews with customers, journey maps, user flows, workshop templates, etc (Notion, Figma, Miro, Google Meet)

• Research reports (Notion)

• Design critique sessions among team members (Figma, Miro)

• (Iterating on) design system components & libraries, design research & explorations, UI solutions, and prototypes (Figma)

• Usability testing & reports (Google Meet, Notion)

• Syncs with the development team on feasibility (Figma, Miro, Google Meet)

• Design handoff documents with all possible flows for a user (Figma)

• Tasks for research, design implementation and designing & building of components with checklists as a guideline that can be adapted to make sense for the specific task (Notion)

• Follow-up on the implemented changes (Storybook, Daily environment, Notion)

We might share more about our templates in the future.

In order to keep track of what we have decided both for the design system and the UI and UX patterns we use throughout our app, we have introduced the Design decisions document in Notion, where we write down all of the decisions that span across teams, we update with topics for discussion and to-do items weekly, track the following steps (like create a dev task), etc. We cover details about components and changing token values, but also UX patterns that we follow across the app. It has become one of our go-to documents that we really do keep up to date.

We also keep a resource base of links, tools, courses, best practices, case studies etc. It’s nice to have a way to come back to one topic without searching for the best resources you can find out there.

Cross-functional collaboration

As part of the product team, we agree on the research methods, the data we need to gather, backlog grooming, even in fine-tuning the user stories.. in general, the Designers collaborate on daily basis with our beloved Product managers. The design team is also involved in the details of the Design document, giving feedback early on on what is missing as an input for the planned work.

For the research needs, since we worked on an existing product with features customers already use, we collaborated on daily basis with out Customer Success team - the Account managers and Customer support team members. We now consider them an initial gold mine of information gained by working close to our customers throughout the years.

Some of our customers were offered to be a part of the Customer Advisory Board and we’re happy they accepted spending their time with us in interviews and usability testings ran by the product managers and designers. From these pleasant and laid-back discussions, the product team gained valuable feedback that is greatly appreciated. We built the Personas based on the customer interviews and insights, and they were the basis as a guiding star when we discussed some customers’ use cases. In return the customers got a sneak peek into our latest work and will be included in the beta release that’s coming very soon!

As part of the development process - we are part of the grooming, planning and retro sessions within the Engineering teams, giving introduction to the designs and coordination of what needs to be done in the following sprint. Since we were creating the design components in Figma as part of our Design system “Stream”, we were very involved with frontend decisions about their implementation, but also conducting design reviews after they were built in Storybook and the daily environment. This turned out to be a great success, bringing great quality not only on the design details, but also improvements of the user flows throughout the app.

We also ran a Design sprint workshop, which significantly brought light to everyone about the benefits of such collaborations.

Design system

A very big part of our work went into our Design system which we named “Stream” - appropriately related to our video monetisation platform :) We introduced a whole new way of working to both designers and engineers that took away a lot of pains of possible misunderstandings and mis-implementation of features on the long run.

Investing time into building the design system with solid foundations, with a flexible atomic-based approach, solid documentation for proper usage, and design tokens synced directly into our codebase, we have gained a huge advantage into delivering designs and code implementation in a fast and consistent manner.

The Core XP team is the owner of the Design system and the core of the new dashboard app we redesigned during the past year.

For the ones interested, detailed blog posts on the design system will follow!

Meetings

We participate in the Product team meetings including weekly Product sync, Product review and Product learning meetings with the Product managers.

In the beginning when we got to get to know each other as a design team, we ran several design team exercises like the “Team strengths” aka the skill spider-map and discussed heavily on the meetings we’d need in order to stay up to date, get valuable feedback and in general work in a more collaborative manner.

We started off with one Design sync meeting a week and recurring 121 (one-to-one) meetings between me (as a Director of design) and each designer.

During the Design sync meetings, we tend to discuss what everyone is working on and offer design-eye feedback before we present on the Product review meeting the following Monday. To make sure we all have the same level of understanding, we start with showcasing the problem, challenges we had and experiments we have been trying out in order to achieve something.

Sometimes, we use the design critique format when we want to get thorough feedback from every member of the team and we make sure that all of us have some time to think things through on a deeper level. Very often, when we don’t have time to wait for a meeting or we’re too busy, we use async reviews for smaller issues using sticky notes and Figma native comments.

During our 121 meetings, I check on all design team members how they’re feeling, if there’s any blocker, or if I can help facilitate something they need. They often use this time for a feedback on their work before presenting to the whole team, which is not forbidden :D It’s their time with me, so it’s their choice how we get to spend it.

Knowledge sharing sessions

After a while, we realised that we spend a lot of time discussing fine-tuning components during the Design sync meeting, so we introduced a Design system updates meeting where we invited the frontend developers, so both the design and engineering teams know what is new in Figma and in Storybook and if we’re introducing any major changes.

We also introduced a “New dashboard” presentation meeting for our Customer Success and Marketing teams, where we presented everything that is coming with the new redesign, so they are prepared when the time comes to support our customers in the best way possible.

Several times we have also organised some ad-hoc training presentations on how to use the design system on the design side, engineering side, but also a live-coding session which was a great way to really show how the design system can be used in the best possible manner.

Director of design participation

As a Director of design, I also participated in bi-weekly meetings to sync with the Marketing and Engineering teams (Development Process Optimisation meeting), and I am part of the Core eXPerience team’s scrum ceremonies. I also have a 121 meeting with my manager - Edit (CPO). So, here’s how my calendar usually looks like with all the weekly and bi-weekly meetings included, luckily not all weeks look as crowded as this :)

No-meeting Thursdays & lunch breaks

One great way to really have time to focus on important work is introducing an all-company agreement not to use Thursdays for meetings, which has been really helpful and productive for everyone. We only have Thursday exceptions for scheduling calls with customers since we knew that everyone that needs to be involved should be available and we don’t need to make people move other meetings.

Blocking your lunch break, is also a way to make sure people will not schedule 5-hour long streaks and get some nice food/coffee refreshment mid-day :D

Final thoughts

The processes, templates, syncs and excellence in detailed execution really bring us to the top of our game, but the most valuable part of our work is probably being a link between the business side of the product and the engineering one, keeping the best interest of our users always in sight.

We are definitely proud of what we have achieved during the past year with great team work across all teams and looking forward to even more great things ahead.

Thanks for reading, more will follow!

While working with Design Systems and Figma’s component libraries, we often have to introduce more structural changes that might affect other files that are using our library’s components. We, the design team at InPlayer, have found a way to introduce changes in the library’s components that won’t affect the used instances of the components in current or older files.

Updating a component from a Library

Currently, if you try to update a component in a Library, that update will be propagated in all of the files where you have used it. You can review it but when working on the file, you’d always want to update your components and use them in the latest state, so you’re usually hit the “Update” button.

If the structure of your layers, their names or the variants have been changed, then the update might cause the current overrides to also get reset to the main component. 

For example, you have added the “Button” component in another more complex component and imported it in your design file where you give it some context by changing the wording. Then, later you decide to add an icon and use the “Icon + Text” button variant instead of just the “Text” one. With the library’s update, the wording of your button’s instance that you overrode to fit to your context, will be reset to the default.

Imagine that you have used this component throughout dozens even hundreds of screens across your files.. even though it’s an action that can be easily reverted (just remove the icon and the text will be set back in place), we definitely would like to introduce updates, but avoid such braking changes. 

Note: I still consider that this is an issue that Figma can easily fix, but there is a way to circle around it for now.

Avoiding breaking changes in a component

By introducing a copy of the original main component or creating a new one with the same structure (layer names, etc), the update will not affect your designs. 

Figma actually uses an ID for each of their main components and its instances, and if you have worked with their API, you’d probably figure it out that a new main component with the same name won’t have any connection to the old one and will be considered a new one despite using the same name. 

In the project file, the instance of the old component will continue to exist without getting an “update” notification. If you try right click and “Go to main component” it will take you to the old one, even though it was excluded from the Library by using “_” or “.” before its name (you still have to publish the change).

The connection will still be there, and even if you delete it, “Go to main component” will ask you to restore the original (which we probably won’t want to do, eventually).

Still, in your designs, even though you won’t get prompted to update the Library, if you want to use the new component, you can mindfully swap the component with the new one introducing the changed component to your current file. 

By surprise, if every layer had used the same naming and structure (and in this case it does, because we created a detached copy), the instance will keep the wording of your current file overrides and will not break anything in your current design file even though it will have all the necessary changes we wanted to include in the first place.

Conclusion

This approach will definitely save you some time (and *khm* nerves), without having to revert the changes or going through all your instances and fixing the wording for all existing design files. The old files will keep the old version of the component (set in stone in history) and the new ones will be easily and mindfully updated when you have the need to do so. 

Let us know if this tip has helped you out! :)

Being a recruiter for UX designers and engineers for about 10 years, I see very common and repeating mistakes that could be easily avoided both in the portfolios and during the interviews. So, I put together a twitter thread that I decided to elaborate a bit in more details:

1. Graphic design is (just) the foundation

But it’s very different from software UI design. Colours, typography and spacing are the basics, but you have to learn how to apply them within the constraints that digital UIs bring. So, if you did branding or packaging graphic designs so far, you will be considered a beginner in UI and if you don’t redo your portfolio to show some UI work, you will probably get rejected for senior UX design roles.

2. Learn the UI components

There are UI components that are pretty common in web and app designs. A lot of design systems are available online so you can go ahead and research them in more details and learn about all variations. The native HTML and custom components are tweak-able but the basic functionality and usage are common patterns you have to follow.

3. Cover the UI stack

The biggest difference with graphic design is that your UI is alive and not set in stone. Think about all possible states of a component or a screen you’re designing — ideal, empty, error, partial, loading.. the user should be always informed what is happening, what they did, was the state saved, etc. As a designer you should think through all of them and plan your designs accordingly.

4. Accessibility shouldn’t be an afterthought

Minimum contrast standards and keyboard navigation through a user flow are a must. Covering screen reader user flows is a big challenge, but don’t leave it out if you work on publicly available websites and apps where you’re not sure who your users are. Design for everyone. 

5. Sync with developers early on

If there has been a decision by the software engineers to use a frontend framework, adapt the designs to it instead of the other way around —  it will save everyone a lot of time. That is if you don’t compete for the Awwwards :) You can kick-start your designs with an existing UI library and build up your designs from there. There are also common patterns per platform (web, iOS, Android…), especially the navigation patterns, that should be followed — don’t re-invent the wheel.

6. Know the difference between UX and UI

They come interchangeably, but if you put “UI/UX” in your title, then have it clear in your mind and know how to explain what do you do from the design process. Care about users; learn the personas & user flows (and/or create them); and talk to those that will actually use your UI and test it early on. Know that UX is more about understanding the problems and iteration on possible solutions, while UI is more about the craft. Business decisions and product design is something that comes with experience, but know the basics of your area of work.

7. Atomic design

You don’t need to know the book by heart, but you have to understand the concept and build your components to scale up. It doesn’t matter if they are called an organism or any other name, but the way you design them should be appropriate to how they will be built in code. Hence, understanding basic coding like semantic HTML and nesting is a very high advantage. That leads us to the tools of building the components…

8. Follow the design tools and their updates

Use styles for colours, typography, effects, etc (still bothering Figma to add spacing/sizing tokens but one can dream :D). Those are analog to variables that will be used throughout the codebase as well and translate well into the design tokens concept. 

For example, auto layout in Figma was not invented to have something more to study about, but to make your life easier when you need to update and tweak your designs (and you will definitely have to do it). These tools are mostly analog to how the developers will code the layout (see: Flexbox).

Learn how to use the grid and how to layout the components to add responsiveness to your designs so you can easily create responsive designs with the same components. Use libraries. Explore prototyping possibilities. Ease up your life.

Don’t get attached to a tool, though. I have designed in code, used Flash, Dreamweaver, Illustrator, Sketch, InVision, Adobe XD and Figma. At the moment Figma is winning with features that are very consistent to coding approaches, but who knows, some new cool tool could come up tomorrow :)

9. Have a good file organisation

File structure, organisation and documentation of your components and processes are key and you should follow them in the portfolio. At some point you will have to work with other designers or developers, or someone will have to take over. Everything should be clear and everyone should be able to find what they need at first glance.

10. Portfolio & CV

Don’t apply without a portfolio. Besides your designs, show your process and thoughts. Sometimes the design looks crappy, but it would still be great if you display you have researched alternatives or you had constraints to follow. Sometimes your past work might be under NDA contract, but you can mock the problem and redesign the UI with different colours and data, or go low-fidelity so you can showcase the concept. 

Make sure you pay attention to details, spelling and wording —  sloppy work in your CV and portfolio will imply you’ll also be sloppy at your daily job. If you’re not sure, send them over to someone and ask them to double check the wording and if everything is clear to them, otherwise, change your narrative. And you really don’t have to use progress bars about your skills or the tools you know — to be precise about your knowledge in percentage, you also have to know what you don’t know, and you probably don’t 😅

Never stop learning!

There’s much more to learn about and explore, mostly around the UX research area and building the right things for the specific users. But for building complex UIs for web applications you have to have the systemic approach of Design Systems into designing & building the UI that common graphic and (marketing) website design principles don’t cover.

We’re in a field where something new comes up every day. Stay up to date by reading books and blog posts, follow other designers on Twitter and Medium (even LinkedIn) and the tools’ updates that usually come with tutorials and explanations. It can be overwhelming at times, so make sure you really have the basics covered.

In the modern world, web applications tend to be more complex and more useful in every field of life.

The front-end applications are the first contact with your customers, and these applications over time, become more and more complex, which means the build time, as well as development time, can dramatically increase. Increased build and development time, often means more expensive bills for building and developing these applications.

Choosing the right build tool is the most important thing in this development toolchain, so the right tools can save you valuable time and money.

We did some research and found that one of the most popular build tools for front-end applications, ViteJS, is the most appropriate build tool for our case.

Here is our journey with migrating our RAR React application to ViteJS

Environment and performances with RAR

First, we want to mention that both RAR and CRA are great, but not as great as ViteJS, especially for the build and development time as well as the application size 😊.

With RAR, the application build time was between 15 and 30 minutes with GitHub Actions, which made every build on CI very painful and slow.

Also, the fast refresh feature was not fast at all.

The migration

Our react application was based on react version 16, and the first step was to upgrade to the latest, version 17.

if you are using react with typescript, do not forget to update and node type to version 17 e.g. "@types/node": "^17.0.21"

The second step was to add a specific ViteJS configuration. According to their documentation, we created ViteJS configuration file.

vite.config.ts

then, we updated the scripts in package.json

and the last step was to create index.html page in the root of the project, for the new setup.

And that’s it. We installed the new dependencies, and run the command yarn dev. The result was, a lot of errors, and the application did not work. After research, we found that the indirect dependency(dependency of our dependency) uses node-specific modules. In our case, the problematic dependency was aws-iot-device-sdk which uses node-specific modules like Buffer, process, etc. The errors and how we fixed them, jump to the next section 😊

First issues with the new setup

A lot of errors occurred in the browser’s console and the application did not work at all 😞

The most common errors were: Buffer or process are not defined. These functions/constants are used by the indirect dependencies, and our application did not work because of them.

The errors look like the image below:

Uncaught ReferenceError: process is not defined

Uncaught ReferenceError: Buffer is not defined

We tried almost everything. Tried to define Buffer and process in the config files and inject from the config file, but ViteJS was a little confused about how to order the injected variables or manually injected polyfilled scripts, so we get another error like Uncaught SyntaxError: Identifier 'Buffer' has already been declared.

After days of investigation, we finally found a working solution. In the next chapter, you can read, how we went over the issues caused by the node-specific modules 🚀

How we went over the issues

First, we installed the Buffer and process as a new dependency.

yarn add Buffer
yarn add process

It adds a new dependency to your package.json. In our case:

Then, it needs to create a new file, e.g. in your src folder with name nodespecific.ts

Your nodespecific.ts file should look like this:

then, you will need to add this file to your index.html

This will work for local development, but for the production build, you will need to install one more ViteJS plugin.

yarn add @rollup/plugin-inject

And the last step is to update vite.config.ts. Now, your ViteJS configuration file would look like this:

Now, you can run yarn dev or yarn build. 🚀

Conclusion

ViteJS is a great tool, it saves time and money. It will be better over time. Migrating from CRA or RAR was definitely worth it.

If you have any questions, feel free to post a comment below

✨ happy coding

Subscribe now