Back to selected work
ELEVATION • DESIGN SYSTEMS
Creating an elevation system.
ROLE
Product Designer
METHOD
VScode
OUTCOME
Guide & CSS Tokens
ADOPTION
All platforms
Summary
Elevation is used to provide visual cues about a components depth from a website’s surface and its distance in relation to other components. ITHAKA had used elevation in certain places across its platforms, but it wasn’t a consistent effect that had a guide design and development could reuse. I wanted to fix all inconsistencies across each of our platforms for us to have a shared and scalable experience. I owned the creation, code, and implementation.
5 platforms
adopted and updated their components
Background
Context
ITHAKA has a wide variety of platform offering different services to different user bases: Students, librarians, researchers, and more, meaning we have to cater to those groups; aspects will inevitably be different. However, one thing that shouldn't change is our design system. Being siloed can result in discrepancies and the more our individual platform use cases expand, the more our needs split.
First steps
Auditing ITHAKA platforms
ITHAKA used elevation in certain places across its platforms, but it wasn't consistent. For example, a card on one platform would have a shadow, but on another, it wouldn't.
I gathered other designers from different platforms to have a discovery session. We took the time to audit the platforms we owned and bucketed components into 2 categories:
"Where elevation is used" and "Where elevation could be used".
This would eventually help me define the use cases and rules for this design system.
Here are some of the elevation discrepancies I recreated from the above audit, pulled from different ITHAKA platforms with different values:
Defining
When & how it should be used
Usage
Elevation will use surface shadows to create a sense of depth and lift, making designs feel more intuitive and engaging. It will guide the users' attention through means of visual layering, while signaling which elements are interactive or have become interactive.
Building elevation into a design system is key to creating a cohesive, standard, and immersive user experience.
Depth, shadows, and light
To communicate a component’s depth from a website’s surface and its distance in relation to other components, we'll need a system that has a consistent equation that can be built upon. I don't want to create anything arbitrary that leaves other designers with no knowledge on how to calculate higher elevation levels.
Calculating and creating
First: Shadow stacking
Stacking shadows is the direction I went forward with. By avoiding solid outlines, the components avoided harsh edges, which was especially helpful when elevation values rose to higher levels. Diffusion allowed the component to stay soft.
The top shadow gives the illusion of a stroke while the bottom shadow tackles the actual shadow.
If you only have the top shadow, the top of the component will blend into the background, and if you only have the bottom shadow the component will be undefined.
Second: Values
Though there is a set guide for us to follow, I needed to make sure that we could easily add levels if need be.
I needed to create a calculation.
To keep elevation levels harmonious, I constructed a 2 step system:
The top shadow should consistently stay at these values no matter the elevation level: X = 0, Blur = 2, Y = 1, Spread = 0
Starting at level 2 is when calculations are used. The bottom shadow should comply with the following system as each level rises: X = 0, Y +2, Blur +2, Spread +1
System visuals
Once I'd audited, calculated, and created the elevation system, I need to create a visual that communicated what levels to use on which component.
By following my guide, uniform usage across ITHAKA was guaranteed to be implemented.
Practices
Best practices
Dos
Use when there is content behind a component and that component has content available to be interacted with.
Alter the Y-axis for directional movement.
Donts
Change the light source.
Use hover elevation if interactive content is visually communicated in another way. Eg.The ability to move content is already visually communicated through the reorder icon.
Apply elevation to components in order to be “visually pleasing”.
In practice
Some examples from the public facing JSTOR and JSTOR Digital Stewardship Services:
Sticky header ($pharos-elevation-0->2)
Predictive search ($pharos-elevation-2)
Modal ($pharos-elevation-5)
Dropdown ($pharos-elevation-3)
Principles
Elevation principles
Consistent
All elevation is used at the appropriate level assigned to that component. Always follow the recommended shadow pairings.
Suitable
Dynamic elevation should only change values when suitable for a component’s behavior.
Practical
Elevation is not solely used for visually enjoyment. It should communicate to users that there is an emphasis or prioritization when it comes to a given component.
Code
Development application
Tokens
I converted all values into CSS, providing tokens for developers to easily apply them to components in our library.
Below is the code I wrote for our tokens and below that are the elevation levels - free to copy and try them out for yourself!
TOKEN · VALUE — CLICK TO COPY
$pharos-elevation-1
0 1px 2px 0 rgba(0,0,0,.13)
COPY
$pharos-elevation-2
0 1px 2px 0 rgba(0,0,0,.13), 0 2px 4px 1px rgba(0,0,0,.14)
COPY
$pharos-elevation-3
0 1px 2px 0 rgba(0,0,0,.13), 0 4px 6px 2px rgba(0,0,0,.14)
COPY
$pharos-elevation-4
0 1px 2px 0 rgba(0,0,0,.13), 0 6px 8px 3px rgba(0,0,0,.14)
COPY
$pharos-elevation-5
0 1px 2px 0 rgba(0,0,0,.13), 0 8px 10px 4px rgba(0,0,0,.14)
COPY
Want to talk more? Contact me!