Even though this new iteration of the design system has a new name, it is still a part of an established brand that needs to be respected. Many ideas from the original system remain, such as the general page structure and the application of the brand color to navigation and controls. However, several styles were adjusted to enhance the content's presentation:
Let's take the buttons. Good ol',
ever present buttons…
For instance, if you don't know what would be considered 'brand appropriate,' you're not going to be able to make that judgement call until that gets defined. So you either have to learn or define before you can be confident.
Design thinking is a process. It often isn't pretty. Sometimes the solutions change, sometimes the constraints shift. In the beginning of this, the constraints changed often as the vision developed. Then, as that vision solidified, it was the solutions that needed to conform instead.
At the start everything is just an idea. The significance of each individual piece is undefined. That makes it difficult to discern whether an iteration is, first, valid, and second, sound.
In the word's of Bruce Lee, "Be water, my friend."
These were the original SYNC buttons. Big, but that's not inherently bad. However, in the context of the rest of the UI they felt kind of rudimentary.
I believe a good system thinker is somebody who can anticipate what the impact of a change could be, but also isn't adverse to change for fear of that impact. Systems are constantly changing and the better planned and structured it is, the better it's going to handle changes in sentiments and constraints.
Once the simple border radius change had run its course (to get the interface to a harmonious state), the UI no longer communicated key aspects of the brand and, thus, proved not to be a valid solution.
These were the buttons that were settled on. The differences from the originals are subtle, but still have an impact: Less padding to decrease the footprint, bold font, sentense-cased, fill gradient saturation increased, and maintained fill on secondary to ensure accessibility on various backgrounds.
Because what happens when you introduce a new style like this? If you don't change any other element, they look out of place (unless you push it to a point where it appears intentional).
We tried super rounded buttons.
People responded well to them in isolation, but the moment they hit the rest of the environment it became obvious that these were 'not Extron.'
You ask a series of Yes-No questions and your decisions are made for you. The difficulties crop up when you either don't have a definition to correctly judge your answer, or when you start hitting valid answers that can span a spectrum.
Considerations and Outcomes
CAUTION: DETAILED BREAKDOWN OF AN INDIVIDUAL'S (my) THOUGHT-PROCESS AHEAD.
Proceed at your own risk or skip ahead to the next heading.
Identitied concepts listed out with font weights reflecting how prevalent they were in the moodboards.
does it exist in the system?
would it add value if it did?
yes
yes
yes
make it
is the design brand appropriate?
does it need to be accessible?
does it align with our values?
does it conflict with existing styles?
should it adjust existing styles?
should it adjust?
is it?
did you use it?
“Any particular
reason why not?”
yes
yes
yes
does it need improving?
no
no
yes
yes
yes
no
no
no
no
no
no
no
no
Fuse (Design System)
Roles and Responsibilities
Roles and Responsibilities
initiative lead (Directly Responsible Individual)
visual development
system architecture
Establishing Direction
Establishing Direction
The first phase of refining the system involved taking note of which aspects were still appropriate for our products and discovering the attributes we deemed important to explore further in subsequent iterations.
Contributing designers created moodboards that were shared within the group to discuss any concepts or treatments that resonated with them. The ideas that were most prevalent and held more relevant significance to our products were selected as the initial focal points for our explorations.
Adoption of a tool, or a concept, is heavily impacted by the level of confidence one has in it. When an idea, or an identity, can be tracked through a process, or across an interface, it helps in establishing that confidence.
Along with the ideas that revealed themselves through the team activity (crafting space better, clearer heirarchies, more visual interest), there were a few objectives I asserted to bring the system up to modern sensibilities. These included:
Identitied concepts listed out with font weights reflecting how prevalent they were in the moodboards.
greater consistency
more maintainable
cross-platform sensative
accessible
better affordances
Defining Styles
Without an established, well-defined identity, the SYNC design system suffered from style bloat as contributors committed their solutions with limited awareness of the full system.
Conducting a style audit across the library's components revealed 77 declared type styles; a mix of color strategies including declared variables, detached hex values, or adjusted opacities; along with arbitrary spacing values; and inconsistent state treatments. These highlighted a few areas for improvement.
The lack of consistancy had a direct impact on the system's code base, as the use of mixins and variables was limited by individual elements needing unique sets of properties. Being able to approach the system in a holistic manner made sure styles were significant and appropriately shared across components. This would help to promote a better sense of unity and facilitate alignment between the code repositorty and design library.
In a system, no element is ever in isolation. Thus, it's not a matter of where to start, but simply to start and keep everything in mind.
So, if you try a change, you need to make sure it propagates throughout to check its impact on the rest of the system. Instead of starting with a single atomic component we worked off product screens as starting points.
We started with this:
And got to here:
Even though this new iteration of the design system has a new name, it is still a part of an established brand that needs to be respected. Many ideas from the original system remain, such as the general page structure and the application of the brand color to navigation and controls. However, several styles were adjusted to enhance the content's presentation:
input labels moved outside of the formfield
both the input label and input data font-size increased
font-size normalized across the board
dropshadows removed, with space being defined by relative positioning, whitespace, or subtle borders
additional rules around button usage were introduced
AA accessibility standards met
component clarity improved (e.g., segmented button)
navigation moved toward center of page to reduce concentration in top-left corner of the window
Along with many other subtle changes that, when applied to other products, render like:
SYNC had a dark theme, but how colors were applied was entirely unique to itself. Fuse had theming in mind from the start in order to make the style architecture easier with 1-to-1 color applications. Switch themes with a single class, not a full strategy change! x_x
From Sketch + Abstract to Figma
In the midst of this development, the team migrated our system to the Figma platform. Our change in approach to styling paired incredibly well with Figma's features. Additionally, the more robust component properties allowed our previous library of 1,000+ floating symbols to be more efficient, shrinking the component list to just 20% of the original.
In addition:
type styles went from 77 to 24
colors were better defined through variables
paddings were built into components and spacing intervals standardized
similar states across components were normalized (e.g., going from 13 different selected-states to 6)
more variables and mixins were created for our SCSS documents with naming shared across both spaces
Since the start of this initiative, product teams have shown greater enthusiasm in adopting the design system and contributing to the component codebase.
It also helps if it looks good too. Not always the most important part… but it doesn't hurt. XD
CAUTION: DETAILED BREAKDOWN OF AN INDIVIDUAL'S (my) THOUGHT-PROCESS AHEAD.
Proceed at your own risk or skip ahead to the next heading.
Considerations and Outcomes
Still here? Let's talk shop…
You've been asked to take an existing visual language, revamp it, elevate it based on the values set out, while still maintaining the brand's identity and having minimal impact on engineering and consuming development teams…
How do you approach that? What guide's that process?
In the word's of Bruce Lee, "Be water, my friend."
At the start everything is just an idea. The significance of each individual piece is undefined. That makes it difficult to discern whether an iteration is, first, valid, and second, sound.
So, you start to assign some significance to the constraints. Sometimes they're declared for you, other times you have to establish something as best you can simply so you can move. Deal breakers up front, guiding constraints later on.
Example.
Example.
!
!
does it exist in the system?
would it add value if it did?
yes
yes
yes
yes
yes
make it
is the design brand appropriate?
does it need to be accessible?
does it align with our values?
does it conflict with existing styles?
should it adjust existing styles?
should it adjust?
is it?
did you use it?
“Any particular reason
why not?”
“Any particular reason
why not?”
yes
does it need improving?
no
no
no
yes
yes
yes
no
no
No
no
no
no
no
This could keep going for a while, but the idea is there.
You ask a series of Yes-No questions and your decisions are made for you. The difficulties crop up when you either don't have a definition to correctly judge your answer, or when you start hitting valid answers that can span a spectrum.
For instance, if you don't know what would be considered 'brand appropriate,' you're not going to be able to make that judgement call until that gets defined.
So you either have to learn or define before you can be confident.
Design thinking is a process. It often isn't pretty. Sometimes the solutions change, sometimes the constraints shift. In the beginning of this, the constraints changed often as the vision developed. Then, as that vision solidified, it was the solutions that needed to conform instead.
Let's take the buttons. Good ol', ever present buttons…
BUTTON
BUTTON
Button
Button
We tried super rounded buttons.
People responded well to them in isolation, but the moment they hit the rest of the environment it became obvious that these were 'not Extron.'
BUTTON
BUTTON
Because what happens when you introduce a new style like this? If you don't change any other element, they look out of place (unless you push it to a point where it appears intentional).
These were the buttons that were settled on. The differences from the originals are subtle, but still have an impact: Less padding to decrease the footprint, bold font, sentense-cased, fill gradient saturation increased, and maintained fill on secondary to ensure accessibility on various backgrounds.
In order to restore unity across the space, these styles then have to influence or have reference to other elements. The button might inform the navigation elements. The navigation elements might inform other view-control elements in order to have consistent styling significance. On it goes.
Once the simple border radius change had run its course (to get the interface to a harmonious state), the UI no longer communicated key aspects of the brand and, thus, proved not to be a valid solution.
I believe a good system thinker is somebody who can anticipate what the impact of a change could be, but also isn't adverse to change for fear of that impact. Systems are constantly changing and the better planned and structured it is, the better it's going to handle changes in sentiments and constraints.
These were the original SYNC buttons.
Big, but that's not inherently bad. However, in the context of the rest of the UI they felt kind of rudimentary.
These were the original SYNC buttons. Big, but that's not inherently bad. However, in the context of the rest of the UI they felt kind of rudimentary.
Anyway!
Anyway!
Anyway!
How do you approach that?
What guide's that process?
In the word's of Bruce Lee, "Be water, my friend."
At the start everything is just an idea. The significance of each individual piece is undefined. That makes it difficult to discern whether an iteration is, first, valid, and second, sound.
So, you start to assign some significance to the constraints. Sometimes they're declared for you, other times you have to establish something as best you can simply so you can move. Deal breakers up front, guiding constraints later on.
For instance, if you don't know what would be considered 'brand appropriate,' you're not going to be able to make that judgement call until that gets defined.So you either have to learn or define before you can be confident.
Let's take the buttons. Good ol',
ever present buttons…
Even though this new iteration of the design system has a new name, it is still a part of an established brand that needs to be respected. Many ideas from the original system remain, such as the general page structure and the application of the brand color to navigation and controls. However, several styles were adjusted to enhance the content's presentation:
Considerations and Outcomes
Extron's initial design system, SYNC, suffered from inconsistent enhancements and implementations across Extron's software product offerings. Built on common frameworks, guided by generic values, and driven by immediate product needs, it developed an incoherent identity. An aging aesthetic and a lack of organizational adoption warranted a refactor and a refresh of the system.
The value of a design system is proportionate to the level of effort devoted to it, compared against the amount of adoption it inspires within the organization.
Extron's initial design system, SYNC, suffered from inconsistent enhancements and implementations across Extron's software product offerings. Built on common frameworks, guided by generic values, and driven by immediate product needs, it developed an incoherent identity. An aging aesthetic and a lack of organizational adoption warranted a refactor and a refresh of the system.
The value of a design system is proportionate to the level of effort devoted to it, compared against the amount of adoption it inspires within the organization.
The first phase of refining the system involved taking note of which aspects were still appropriate for our products and discovering the attributes we deemed important to explore further in subsequent iterations.
Contributing designers created moodboards that were shared within the group to discuss any concepts or treatments that resonated with them. The ideas that were most prevalent and held more relevant significance to our products were selected as the initial focal points for our explorations.
Along with the ideas that revealed themselves through the team activity (crafting space better, clearer heirarchies, more visual interest), there were a few objectives I asserted to bring the system up to modern sensibilities. These included:
greater consistency
more maintainable
cross-platform sensative
accessible
better affordances
Defining Styles
Without an established, well-defined identity, the SYNC design system suffered from style bloat as contributors committed their solutions with limited awareness of the full system.
Conducting a style audit across the library's components revealed 77 declared type styles; a mix of color strategies including declared variables, detached hex values, or adjusted opacities; along with arbitrary spacing values; and inconsistent state treatments. These highlighted a few areas for improvement.
The lack of consistancy had a direct impact on the system's code base, as the use of mixins and variables was limited by individual elements needing unique sets of properties. Being able to approach the system in a holistic manner made sure styles were significant and appropriately shared across components. This would help to promote a better sense of unity and facilitate alignment between the code repositorty and design library.
In a system, no element is ever in isolation. Thus, it's not a matter of where to start, but simply to start and keep everything in mind.
So, if you try a change, you need to make sure it propagates throughout to check its impact on the rest of the system. Instead of starting with a single atomic component we worked off product screens as starting points.
We started with this:
And got to here:
Still here? Let's talk shop…
You've been asked to take an existing visual language, revamp it, elevate it based on the values set out, while still maintaining the brand's identity and having minimal impact on engineering and consuming development teams…
How do you approach that?
What guide's that process?
So, you start to assign some significance to the constraints. Sometimes they're declared for you, other times you have to establish something as best you can simply so you can move. Deal breakers up front, guiding constraints later on.
This could keep going for a while, but the idea is there.
BUTTON
BUTTON
In order to restore unity across the space, these styles then have to influence or have reference to other elements. The button might inform the navigation elements. The navigation elements might inform other view-control elements in order to have consistent styling significance. On it goes.
SYNC had a dark theme, but how colors were applied was entirely unique to itself. Fuse had theming in mind from the start in order to make the style architecture easier with 1-to-1 color applications. Switch themes with a single class, not a full strategy change! x_x
From Sketch + Abstract to Figma
In the midst of this development, the team migrated our system to the Figma platform. Our change in approach to styling paired incredibly well with Figma's features. Additionally, the more robust component properties allowed our previous library of 1,000+ floating symbols to be more efficient, shrinking the component list to just 20% of the original.
In addition:
type styles went from 77 to 24
colors were better defined
through variablespaddings were built into components and spacing intervals standardized
similar states across components were normalized (e.g., going from 13 different selected-states to 6)
more variables and mixins were created for our SCSS documents with naming shared across both spaces
Since the start of this initiative, product teams have shown greater enthusiasm in adopting the design system and contributing to the component codebase.
Adoption of a tool, or a concept, is heavily impacted by the level of confidence one has in it. When an idea, or an identity, can be tracked through a process, or across an interface, it helps in establishing that confidence.
It also helps if it looks good too. Not always the most important part… but it doesn't hurt. XD
initiative lead (Directly Responsible Individual)
visual development
system architecture
Design thinking is a process. It often isn't pretty. Sometimes the solutions change, sometimes the constraints shift. In the beginning of this, the constraints changed often as the vision developed. Then, as that vision solidified, it was the solutions that needed to conform instead.
input labels moved outside of the formfield
both the input label and input data font-size increased
font-size normalized across the board
dropshadows removed, with space being defined by relative positioning, whitespace, or subtle borders
additional rules around button usage were introduced
AA accessibility standards met
component clarity improved (e.g., segmented button)
navigation moved toward center of page to reduce concentration in top-left corner of the window
Along with many other subtle changes that, when applied to other products, render like:
From Sketch + Abstract to Figma