Gamma Design Ideaology For Various Apps

MY ROLE

Lead Designer – Researcher – visual Designer

Team Members

Amir shabanloo – Aida Falsafi

ABOUT

Apsy uniquely combines human creativity with AI efficiency to build elegant custom apps. The main product Gamma (called apsy now) uses a chatbot to help unprofessional users build there own apps. the product should use a massive design system to support building Elements of different categories.

DESCRIPTION

Inspired by brad frosts Atomic design methodology we had to build a system which could support building different app models.
Although we have another challenge; the final Idea was to give users of an app builder website the ability to choose and integrate there own screens to make their desired models.

there are two questions :

How the user interacts with the elements of the design system ?
How should we make a system of elements that can be applied in order to make different apps ?

This case study is more about the second question.

PROBLEM

so many categories of apps!
If you want to make different apps for different needs you have to study them.
we knew this was a matter of time. for business reasons we started making the elements as fast as we could and that was why we probably missed some research which had led to these problems:

1 . User has access to add anything to a screen which ends up in :

a. Building things that don’t work.( because every screen needs backend support)
b. Hard time building a screen.

2 . Too many variations’ configs and names
which is bringing cognitive load for user
and taking a lot of time to develop. this also comes from not knowing elements identity.

Users tests

MAIN GOALS

Persona

Nothing is more important than knowing who will use such a product. we knew that our user is not specialized in design, apps websites and other things. now this was important since most app builders and specially our competitors needed patient users.

what I share is just a sample of our persona as we went through the process we updated it a couple of times. what was important was to keep talking about it. I Like the persona template in figma which allows you to describe your persona with some ranges. this made us entertained !

In order to achieve what we had in mind we went into the following steps:

1. Core Components

So this was not a “from scratch” situation. we already had started building but we needed to know all popular screens
used in different apps and try to make them with core components and notify their patterns.

I have to add that the managers decided to put focus on the app version in the first steps so we approached into building with a mobile size focus but by predicting future sizes that needed to be added.

The Core of our system is made from the fundamental components, colors, text styles, icons and more. To ensure scalability for various products, we added multiple visual variations of each component, providing flexibility for the design team to choose the appropriate style for a specific product. Consistency is critical for all apps, and the Core plays a vital role in maintaining a unified design language across them.

* there are also four themes for all components.

2. The Hierarchy

Making the hierarchy was crucial not just for knowing the relationships between components but also for knowing how customizable they should be by the user. first we have to clarify some words:

NOTE: descriptions here are provided in team you may have heard or used them in different shapes

What is a Feature?

a feature is an ability available for an already chosen element or screen
A feature is either like a comment option on a social card or a rating option in an element
they don’t really have limitations for how they are built.
so they may be introduced to users as an icon ‘a screen or anything else.

What is " Customizing" ?

Customizing or configuring is the ability we give to users inside the app builder website in order to make their own preferred app using screens or what ever we make available for them. for example a user can decide if they want a favorite option in their app or not.

What is an Element ?

The user sees no difference between a feature and an element.

an element is what we describe for users as pieces or features that form their app . so for the user this can be ether a button or a screen. they don’t need to know more. they might also need to know that each element may have variations because of their app category or just for style.

so an element may have many features or screens

Hierarchy and the accessibility for users:

1.Components:

To start we had the base layers
this would be colors, fonts spacings, Icons, buttons, inputs & more..
based on the atomic methodology these can be referred to Molecules & Atoms.
but we have to know them exactly so these are important examples:

Navigation bar – Cards – Modals – input – button

The only components users can change directly on request whith no Limits are Design tokens: colors, text, images (place holder), navbar Icon
A component may have other components inside.(see example)
Components may not shape any features
They are always no bigger then a screen

2. Elements:

Elements are made by components and no other element
for example favorite element when used beside event element
do not shape another element they are called flows in that case.
A screen that a user can configure as a feature and is usable beside other
screens can not be counted as an element.
this screen will belong to an element itself.

Elements have features inside
They may include one or many screens
We support most user request on elements
Screens which change or add depending on each other belong to same element. for example profile/edit profile
Two elements may have mutual screens

Features that a user can choose should always be presented to them on the config interface.

“>A user can’t ask for any components that are not features they can only ask for features or elements

Example:

I can never ask for a button or an input I can only say what I want and gamma may suggest me a variation of a screen which has an input and button So keywords and variations have an important role.

“>How are elements separated ?

They have a core screen. other screens or features are attached to that core
Example: profile and edit profile are the same element. profile is the core edit is always attached to ityou can’t have the core screen and not face other screens or features related. example: I can’t have the chat screen but not want the report screen attached to it or I can’t have setting and not configure the support option.
The features usually can not be added to other elements. (there are exceptions)
They usually have a unique configuration which is shown/asked to the user back to back
They usually can be used on other flows/packages by development. (except for most of home elements )

3. Flow (Packages)

Flows are made of at least two elements

Example: The dating flow has the dating home, dating profile and filter elements

An app or a user need can be completed with only one flow
It’s important to know that flows are dependent to there elements and thats how they are defined
if you bring an element out of its flow it would not work or seem to be missing something important for example dating flow should have a profile element in order to work
Every category has it’s own flow

4. <span data-buffer="">App Model(scenario)

A complete app
there only difference from flows is that an app may include more then one flow or independent elements
for example if I want a favorite element in an e commerce flow it can be attached to the flow and that would shape an app using a flow and an independent element.

a base model is always chosen by gamma the user can change features of the suggested model or ask for something which will change the flow or elements automatically

These are two screens belonging to the event flow. they have been chosen for the user based on the words they said in ideation. this element has different features & components.
User can’t add any components to these elements but can change it’s features in config.

“>This is a component inside these elements.
in the configs user can choose these features:

Rating
Favorite

But the user can’t add any other cards
cards will change only when user asks for another element
the user might not know there request is called “element”
they just give there need and we find there need in chat

3. Making Guidelines

Although this part is not Completed yet but we need guidelines to ensure that all team members understand how to use the system and contribute to its ongoing development and improvement. this includes best practices, naming conventions, and documentation. The team will work on refining the design system over time. we have a design member assigned to collect new component requests and reports of component bugs.
‍

Result

After applying most of these rules and instructions building and using them for teams became much easier and also finding bugs has become much faster in development.

“>Also configurations for users on the gamma interface has become much more user friendly and tests are showing about %20 more success and with less lefts.

“>Right now we have +600 Components and we have built more then 25 models with the system. design systems are living aspects of every big product and need to adapt and grow in teams so reviewing them is an every day task.