.png)
Tools & Resources
See what Alkami designers, researchers, and developers use to build our design language.
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. The Alkami UI Kit has everything needed to creates designs and contains all the current components, page templates, patterns and more.
Last updated: September 16, 2024
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.
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.
Example: ∆colorPlatformSuccess
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.
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.