Author: andrenicodemus

Categories
Cylindo Work

Cylindo UI @ Chaos

Cylindo UI. Design System.

The project

When I joined Cylindo – now Chaos – in late 2021, the company grew rapidly, with the product development teams also quickly expanding.

Up to that point, not much work was put into standardizing components from a design perspective or building reusable components within the platform’s codebase.

This has been a huge project, and much work still needs to be done to mature the Cylindo UI Design System further. So buckle up and let’s talk about Design Systems 😊

My role

Cylindo UI is my pet project. It was created from my push to create standards that would reduce repetitive work, speed up and give freedom to the creative process, improve collaboration between designers and developers, and increase consistency across the platform. Still, it is ultimately an informal project – maintained and developed mostly by team members who are passionate about the intersection between design and software development.

With this in mind, I have 2 main roles in Cylindo UI:

  • Facilitating collaboration to the project and getting people’s interest in collaborating. That includes structuring and leading the efforts related to the project (as its de facto Product Manager) and championing the Design System and its benefits to our teams and the end-users of our applications
  • As the most experienced designer on the team and a frontend development enthusiast, I have been doing most of the actual design and, more and more, getting involved in the coding front.

Timeline

2022: Kick-off assessment, “design kit” cleanup and restructuring, creation of all basic styles and components in Figma, initial design/code alignment, color tokens.
2023: Creation of the cylindo-ui repository. Setting up an informal forum, project tracking in GitHub (now migrating to Jira), and bi-weekly sync for designers and developers. Further alignment between designs and codebase.
2024: Buy-in among the engineering team, multiple new components, and contributions from design and engineering team members.
2025 and future: Improved documentation, specialized components, patterns, templates, and versioning.

Background

Chaos Cylindo is a SaaS that enables retailers and manufacturers to produce 3D visualizations of their product libraries on a large scale. The company started with a single product offering, a configurable 360º viewer.

When I joined the company in November 2021, its CMS application consisted mainly of its super-specific project management tool. This tool connects companies that want their products produced in 3D with design studios that will model these products and the materials (textures) they will be rendered with.

At that point, the company was growing quickly and working on expanding its product offering to customers. We were then less than 20 people developing that product, including Product Managers, UX Designers, and Software Engineers, divided into 2 product teams and 1 backend/pipeline team.

In less than 1 year the product team had grown to close to 30 people, we were working on a couple of major products targeted directly at our users which would allow them to create imagery with their existing 3D models and easily distribute that content through their e-commerce platforms.

Given the growing number of products and tools within the platform, the fact that multiple teams would be developing those products separately, and the potential for increased inconsistency across the board, I identified the actual need for a Design System and proactively decided to focus on creating one to benefit the product in general and my colleagues more specifically.


That was the state of Cylindo’s “Design System” back in November 2021.

Kicking-off the project

The first step I took was to trace a strategy – the ultimate goal was to have a fully functional Design System, a single source of truth for all products and tools in the platform. To get to that point, I needed to:

  • Assess the state of the existing UI kit
  • Define the foundations of a Design System (typographic styles, color palettes, spacings, elevations, iconography)
  • Restructure the UI kit file and split it into the necessary Figma libraries
  • In the Figma libraries, create styles for typography, colors, and elevations – categorize the icons in the library and convert those to components
  • Convert the UI elements in a good state into Figma components
  • Create Figma components for the missing UI elements most commonly used in the platform

Getting that initial load of reusable styles & components was an important first step and allowed the UX team to create designs more easily and with much-improved consistency.

The new components

As a Project Management / CMS application, the first components to be rebuilt were the usual suspects: buttons, inputs, tabs, checkboxes, radio buttons, tags, dialogs, tooltips, etc.

This is a sneak peek at how the new components were set up, using the Input field component as an example.


The newly built components included improved handling of states and interactions.

These components were also highly configurable, reducing the need for detaching.

Getting developers involved

Now one thing is building a beautiful library of components in Figma for designers to use, and a very different challenge is recruiting developers to join the effort of building a true Design System, especially when most of them are much more comfortable with backend work and used to doing things “the old way”. The result was slow progress for months.

I was lucky enough that in mid 2022 my Design System champion, Mikkel, joined our engineering team. He brought the energy and technical knowledge necessary to evolve the system and naturally took the lead from a development perspective.

Mikkel worked very hard on developing those basic components in line with the designs, and on super tedious tasks of applying these new components across the platform. Those new components were being documented in Storybook and more developers started using them.

All that work put us in a position where we could introduce broader changes with much more ease. And so we did later that year when the team organized a hackathon…

Color tokens and a dark theme

With most UI elements converted into standard components, we worked on a dark theme for the CMS application. To make that work, Mikkel and I introduced color tokens, applied both light-theme and dark-theme values to each token, and replaced all direct color references with the tokens.


First, I picked one of the most complex pages in the application and defined what it should look like in dark-theme.

Cylindo UI has 2 levels of color tokens: Primitive color tokens and Semantic color tokens.

Primitive color tokens simply assign names to individual colors on our color palette. E.g.: teal-100, red-400, slate-grey-200

Semantic color tokens, as the name says, are variables with added meaning and intention. Those are key to scaling the design system consistently.


A small snippet of Cylindo UI’s primitive and semantic color tokens.

Bi-weekly syncs, color tokens in Figma, more components, support for responsive designs…

As the work on the Design System gained traction among designers and developers, I worked on several important initiatives.

  • Process and communication – Introducing a bi-weekly meeting to plan the work, decide priorities, and discuss the development of individual components. Creation of the #design-system channel in Slack to raise agenda points for the bi-weekly syncs, announce updates, hold async discussions, and more.
  • Support for color tokens in Figma – With the release of variables in Figma, the design components could finally be updated to use color tokens. That simplified the handover of components to developers and enabled the preview of all designs in the dark theme!
  • More components and more specialized – New components such as the Card, Segmented control, and Toast were added. We also built more complex and tailored components like the Slider input, File uploader, Empty state, and Code snippet.
  • Responsive approach – With the increased focus on the end user, more work was put into making all components and new pages fully responsive and incrementally adapting the most relevant pages/flows to work on small screens. Support for pre-defined breakpoints (small, medium, large, x-large) was also added.

Color tokens (variables) in Figma and light/dark theme preview of 3 components.

This fully adaptable analytics page was made possible by building responsive components and setting breakpoints.

Moving Cylindo UI to a separate repository

For a long time, the components library was an integral part of Cylindo’s main application repository. As the product grew and new repos were created to maintain separate tools connected to the platform, it became imperative to move the components into a separate library. The library would be imported by those multiple applications.

In late 2023 the cylindo-ui repository was created. As of February 2025, the library contained over 80 components. It had more than 430 releases, and code from 17 contributors (including myself!).

Work materialized

With the Alert box as an example, here we can see the different points of view of a Cylindo UI component.


UI components are designed and prototyped using Figma.

In cylindo-ui, they are built as styled components in Typescript.

Storybook is the visual representation of cylindo-ui. It’s where both UX designers and developers can browse for existing components.

Finally, Chaos Cylindo CMS is the main host application making use of Cylindo UI and where end-users will interact with the components build through the Design System.

Cylindo UI now and the future

The Design System is constantly in progress and at this point has matured greatly, being used by 4 designers and a growing software development team. It is imported by 3 applications, which solidifies it as a key part of the product development in Chaos Cylindo.

Keeping to the theme of constant progress, some of the points for improvement include:

  • Documentation – Both the design and technical documentation can be further developed. From a design perspective, the most important updates are on interaction details and the do’s and don’ts. On the technical side, better implementation guides should be added to most components.
  • Even more specialized components – Most of the existing components & patterns in Cylindo UI have been designed and developed focused on the Project Management / CMS aspect of the platform. As more specialized content creation and editing tools such as Cylindo Studio are developed, the Design System needs to evolve to support their unique requirements.
Categories
Tradeshift Work

Sellers’ Dashboard @ Tradeshift

The project

After years of working heavily on delivering features and improving the experience on various points of the procurement process to its enterprise customers and connecting them to their supply chain, it was set a goal at Tradeshift to focus on the other end of such connections, the sellers.

The seller’s experience in Tradeshift lacked a starting point, something that is a standard in similar web platforms. Our sellers needed a dashboard where they could easily get started, familiarize themselves with the platform, have clear access to the most relevant information in their accounts, trigger key actions, and find themselves around.

My role

As the UX/UI Designer, I was responsible for defining the user segments that this dashboard was going to be introduced to, understanding their user journeys and each segment’s specific needs, building the journey maps, prioritizing feature releases with the PM, testing prototypes with users, and building the final layouts and syncing with frontend developers to get the designs developed as defined.

Duration

This project was started in January 2019 and the MVP was released in December 2019.

Background

Tradeshift is a cloud-based business-to-business network and platform for supply chain payments. As a network, buying companies that purchase Tradeshift’s solutions create their company and user accounts and invite their sellers to join the platform. This is done through onboarding campaigns, where sellers receive email invitations from their buyers to go through the account creation process in Tradeshift, intending to exchange documents, product catalogs, and more.

The previous user experience for sellers was disjointed, confusing, and lacking direction. Sellers created their accounts and found themselves on the platform with little guidance about what they should do, how to achieve the goals they needed to achieve, and solve the tasks they joined the platform to solve. The platform contains an enormous and ever-growing number of apps and functionalities, all of which are given the same weight to any given user and increase the confusion and lack of focus.

Understanding the problem

The first thing that needed to be done was to understand who were these sellers using Tradeshift’s platform.

Combining research studies conducted by the UX research team with knowledge spread around the company – with various Product Managers, customer-facing teams, and designers involved in the various products that Tradeshift develops, I’ve put together some basic scenarios for the multiple kinds of operations sellers could perform on the platform.

*BSD stands for Buyer Sourced Data

For each of these scenarios, I’ve worked with the relevant stakeholders to identify the users’ journeys, apps used in the platform, onboarding needs, most relevant data, and common actions.

The first concept, journeys & steps

The first idea that was explored was to tie down the sellers’ initial onboarding needs in a guided experience, right after their account creation.

This led to the creation of a document with the main actions these sellers should take to get started with the products they need to use.

For all the scenarios, I also designed a user-journey flow, with which later discussions could be held with the stakeholders.

High-level seller onboarding flow for the Marketplace scenario

Simplify the onboarding, focus on operations

Tradeshift’s platform was heavily built after its corporate customers’ specific needs. There is a huge effort by professional services teams to make for the documents traded to be handled correctly within the procurement systems these companies have in place, and campaigns for onboarding their suppliers. This means that though we tried to push for consistent and simple actions for the sellers to connect with their buyers and start sending/receiving documents, there was a technical barrier to this plug-and-play approach we first envisioned. The idea was put aside at that time.

That led to the decision to focus on the suppliers already using the platform and those being onboarded through campaigns.

The journeys and steps gave place to a simple dashboard introduction modal, a reminder to add missing information, and a modular operational dashboard.

Main widgets – UI documentation

Here is part of the UI documentation shared with frontend developers.

Dashboard release

The new dashboard was introduced both to new sellers joining the platform and those already using it. We used this opportunity to nudge sellers to enrich their Company profile.


Intro modal – highlighting the benefits sellers will get from the new dashboard

Intermediate screen – request for sellers to complete their company’s profile information

Complete company profile

The initial state of the seller’s dashboard. Here the seller would have quick access to the most recent documents, notifications, and quick actions. access to their company profile (and user management), highlights from Tradeshift’s knowledge base, and personalized training material available to that user.

Populated dashboard

Follow up – Dashboard conversion and new widgets

An important aspect of this dashboard release was to introduce the use of metrics to check its adoption rate by existing sellers, validate the hypothesis that a simplified onboarding process would increase the conversion rate of new sellers, and whether or not providing easier access to their documents would increase these documents’ processing time.

The modular nature of the dashboard, together with the newly introduced metrics, also allowed quick testing of new widgets that could speed up other processes that sellers could perform in the platform.

I left Tradeshift right after the release of the Seller’s Dashboard release, though. So I didn’t get the chance to view this data.

If you want to check if Tradeshift can improve your company’s procurement processes and see the Seller’s Dashboard live, you can do so at go.tradeshift.com

Categories
Work

Performance email @ Admatic

The project

The idea of proactive communication through periodic performance reports came up in a moment when Admatic had a strategy of automating processes both internal and for end-users. The technology team was migrating the application from a monolith to microservices and creating APIs to achieve these goals. It brought the opportunity to create a new service for providing email communication to the customers with information about the conversion of their integrations with multiple channels.

My role

As the UX/Product Designer, I was responsible for defining the information that would be provided to the clients alongside the support and technology agents, structure the presentation of this data, generate the layouts and define the KRs and how to validate them.

Duration

This was a quick project that took place between October and November 2016.

Gathering the information

After a meeting by product, technology and support agents to define which data would be presented to the end-users, the backend dev team planned the strategy to gather this data and serve it to the frontend via API.

Sketching

Together with the team, I went through a sketch session in which a wireframe that would guide the final designs was produced.

Agreed information to be included in the report
  • Header with customer’s company name + branding
  • Data extracted from the previous 30 days
  • Main performance indicators (Clicks – Cost – Revenue) for the period & comparison with the same period in the previous year
  • Average ROI for all integrations
  • No conversion – Main products generating cost but not converting
  • Main integrations – Same data on products not converting, broken down by the customer’s main integrations
  • CTAs take the customer to the Admatic, filtered by context – General or by integration

Iconography

Quick studies made following the design guidelines I have set in agreement with the managers for creating a more relatable and friendly communication with the customers.

Cliques (number of clicks on the ads for all channels)
Custo (total cost of the campaign)
Receita (total revenue in the period)

Final layout

The email’s layout was finished following the wireframes previously produced, with some fine adjustments, again for getting a more relatable communication.

  • Dynamic textual summary of the data presented in each section of the report
  • Link to the platform’s knowledge base with curated content related to performance improvements and automation of campaigns
Categories
Estante Virtual Work

Book Collections @ Estante Virtual

The project

This project’s kickoff was the joining of a marketing strategy opportunity and the need to attenuate a usability and business model struggle identified within our personas. On one hand, the upcoming college semester presented a nice opportunity to introduce a feature that enables teachers, students, and institutions to create collections – also known as listas in Portuguese – of required books. On the other hand, book lovers and buyers would now be able to create as many collections as they want pinning the actual book and not a specific copy of it. 

My role

As the UX/Product Designer, I was responsible for defining the information that would be provided to the clients alongside the support and technology agents, structuring the presentation of this data, generating the layouts, and defining the KRs and how to validate them.

Duration

This project took place between May and July 2017.

The sketches

After the background research and benchmarking, a quick process including people from product, design, and development led to the definition of prioritized features and very simple wireframes.


Simple wireframes showing the main features and their release priority (releases 1 and 2) 

Prototyping

The user flow prototypes were created directly on Sketch App, using InVison’s Craft plugin.

MVP features

Excerpts from the mobile prototype. All the interactions were recorded directly on InVision’s viewer. 

Adding a book to a collection
Viewing all collections from a user
Opening a collection

Second release features

Excerpts from the mobile prototype. All the interactions were recorded directly on InVision’s viewer. 

Editing or removing a collection
Creating a new collection from the collections index

Responsive design details

One of the project’s requirements was that all the features fully work on mobile and desktop devices. So the layouts were designed to adjust nicely to various screen resolutions.

Recording from the actual product after implementation.

Release and tweaking

After a public release with low investment in advertising, we noticed that users’ adoption and usage of the functionality were not optimal. Many users accessed their collections index (Minhas listas), but only a few opened the collections themselves. Besides that, a low number of books were added to the lists.

Based on that information, we decided to focus on implementing specific improvements. These included adding an on-page step-by-step guide for new users and incorporating a call-to-action button that directs users to create their own collection page. The call-to-action button was placed on the footers of other users’ collections.