See what Alkami designers, researchers, and developers use to build our design language.
Designing for screens at Alkami is done in Figma, and is centrally managed via Figma Libraries. There are two UI kits: one for the Alkami retail experience, and one for the Alkami admin experience. Both kits are available today for internal Alkami designers, and will be available soon for SDK customers and 3rd party vendors designing and building experiences on The Alkami Platform.
Glossary coming soon!
Speaking a shared language is important. Designers and engineers use special language when collaborating on building the next generation online banking experience. Get up to speed and share the understanding of these terms quickly.
The UX Research Process has been defined and documented. Following a simple 6-step process, any designer, engineer, product manager, or stakeholder can quickly understand the process and get started with a test or study.
UserTesting is the primary tool we use to conduct user research and user testing of digital experiences. Every product designer at Alkami is expected to conduct at least 12 research studies each year. Insights obtained through these efforts enable us to make informed decisions based on data, actual user sentiment, and a deep understanding of our product usability.
Storybook is a tool for developing UI components that can be displayed and manipulated using a series of knobs and data inputs. The output of which engineers can use in projects without worrying about maintaining the original source code.
The Storybook environment for our Iris Vue components is for internal Alkami employees only at the moment; although we have plans to make this public soon.
Slughorn is the tool used to manage all the iconography and Lottie animations used on The Alkami Platform.
The base icon is Google's Icon set, but have been modified slightly to fit our spacing framework. There is plans to redesign a completely custom (and themable) set of icons in the near future.
All of the Lottie animations in Slughorn take full advantage of our set of themable design tokens, and will utilize the FI branded color ramps.
Designing a scalable system across multiple code bases and languages can be a challenge, especially if each team names variables a little differently. With design tokens, designers can create a systematic way to approach using variables and engineers can convert the tokens for use on whatever code base or language they are using.
Ultimately a design token is a key-value pair used in code and design that stands for a repeatable styling decision at the atomic level. A token is made up of a property name (key) and the property value — for example: guidance color = blue. Guidance color is the property, and blue is the value.
Names for properties should use aliases that are not explicitly interpreted, but are scalable regardless of how things will change in the future. For example, naming a property “platform-red” doesn’t allow for any value other than red. Instead name a property with an alias that describes what the property could be used for. Example: “platform-error = red”. This way if we decide to change the color from red to orange in the future the name of the property can stay the same.
To make the design tokens easily readable and to align with the style engineering is already using, name the tokens using the camel-case approach, using the following pattern:
[atomic type] + [Token Level] + [Token Description]
Atomic type represents the decision made at the atomic level, such as decisions around type, color, elevation, size and shape.
Token level represents what level of override the token represents, such as platform, branded, or user.
Token description is a way to describe the token in as little words as possible while still making it easy to read and understand what the token does.
Design tokens represent a repeatable design decision, and can be grouped into 5 major categories: color, elevation, motion, shape, spacing, and type. These categories represent the types of decisions that designers make consistently throughout the experience.
As the largest set of design tokens, color tokens are broken down into 3 levels: platform, branded, and user.
The platform level color tokens represent colors that have a default value, and will never be themed or altered by the FI or users.
The brand level color tokens represent colors that are used throughout the experience in moments of guidance and affordance. These colors are based on the brands two most prominent branded colors (set during the theming process within Theme Builder, or manually here) and the bulk of which are programmatically generated into color ramps ranging from lighter tones to darker tones. (See color framework for more details).
Since brand colors vary wildly in tone, hue, luminosity, etc. color ramps provide a way for us to reliably ensure a high enough color contrast to be accessible. Levels in the color ramp in theory produce the same levels of luminosity for each branded ramp, and therefore can be confidently used throughout the experience.
Because of this, avoid using the base branded tokens since these colors are untreated and cannot be relied on to ensure accessibility standards are met.
As of this writing, there aren’t any user color tokens — but we have plans to introduce them soon.
Elevation tokens ensure a consistent use of shadows throughout the experience. Surfaces throughout The Alkami Platform are defined and serve specific purposes, but only the Raised and Overlay surfaces should utilize treatments with elevation tokens. By default, platform elevation tokens are used on all raised surfaces; however, if a raised surface is treated with the Affordance Base color, using the branded elevation tokens creates a soft branded shadow color. See button component as an example.
Shape tokens ensure a consistent brandable treatment of an elements border radius throughout the experience. Shape is a decision made during the theming process and consists of three component size categories: small, medium, and large. These component categories are used in the shape token description.
Shape tokens can be applied to the entire container or each corner independently.
Small components are those in which the border radius can form a completely rounded edge without causing visibility issues to the elements within.
Medium components are those in which the border radius, if forming a completely rounded edge, would begin to cramp the elements within.
Large components are those in which the border radius, if forming a completely rounded edge, would drastically reduce the amount of space within the container for other elements.
Spacing tokens ensure consistent visual rhythm and branded spacing within components and between visual groupings of content. Although the word “spacing” is used as the atomic type name, these tokens can also be used for size declarations as well.
Type tokens ensure a consistent line height, weight, font family, and font size throughout the experience while also providing a way for certain levels of type to receive branded treatments.