Design System

The Design System created from screech for the mobile platform
Learning about UI components
I was often confused about using different UI components in various contexts. However, this confusion ultimately improved my UI design skills. Here’s what I learned from building my Design System: - Selecting the right UI component for each use case. - Tweaking traditional UI components to match specific needs, enhance user interaction, and optimize screen space. I’m not a strict follower of Material Design or Human Interface Guidelines. Nowadays, companies aim to create their own design languages. As long as a design is accessible and fits the user’s interaction style, I’m happy with it.
Challenge
When I was building the Design System, I realized the power of the Atomic design approach.
Solve.Care is fully customizable at scale. Thanks to Atomic design principles! I can just change the colors and font style, and these properties get reflected across all the components out there. Of course, component-level changes related to color or names can be changed in bulk using,
Selection colors feature of Figma
Bulk rename layers feature is also available in Figma
No items found.
Team composition
No items found.
Advantages of Figma

Figma’s Auto-Layout convinced me to switch completely to Figma. Here are some things I like in Figma:
Usable components and styles
Swapping between two things instantly
Constraints
Frames
Variants. Also, I set up a simple cover page for the file. In Figma, this enables a thumbnail preview of all the components and helps with the brows ability of files. The cover page includes the file name and what phase it’s in design, development, or release. The status can be easily updated when the file progresses.

Inventory, Use Cases, and Requests
Components usage

This page contains examples of the numerous ways that a component shows up in a company’s digital product. In the case of a text field component, for instance, the inventory page would show how the text field looks on abb.com compared to how it appears on an iPhone compared to how it shows up on an Android device.
This page should also show the ways the component is being used incorrectly.

Tests and Data

The test results data page aggregates all the data related to testing a component, including the feedback from users and stakeholders. This kind of history can save significant time by making sure that designers don’t try it again.
Scope
The page lays out a component’s scope so designers can bring a design to fruition. Creating the scope should be a collaborative process with the product owners, developers, and designers.

Style Rules

Was created the style rules page, a kind of catch-all for elements that, are not visible in the design. For example, how will the component render when you scroll down the page? It’s also where the design system team keeps track of unresolved questions or issues.

Collaboration Is Key

The role of a design system designer is multifaceted. Designing a design system involves so many roles.
It’s an enormous undertaking and not necessarily the right move for all companies. Startups, for instance, might do better, to begin with, an out-of-the-box system such as Google Material Design or the IBM Carbon Design System, rather than dedicating extensive resources to creating one. Still, the time might come when that won’t suffice.
Building a design system takes work and dedication; it also takes collaboration. Involving all stakeholders in the development system throughout the process was a priority. It was really iterative work with my whole team. It was all about listening to them and we took the time to learn and test it thoroughly and develop this structure.
Having a structure that includes extensive documentation, including history and best practices, is at the core of the Figma design system.

No items found.
Feel free to reach out! Let's collaborate to create something exceptional.