Around a year ago, Layerise laid its first building blocks towards building a platform that empowers brands to quickly create and release product centric and end-customer optimised Product Assistants. We've spent every hour available towards that goal, and over the last year we've grown from being a platform that focuses on content delivery to a post-sale powerhouse. This rapid service and product evolution, where the design choices of the past are challenged by our current growth and speed, eventually means that our branding needs to adapt and cast a new and clear path forward throughout our next phase of business. 

## The problem
By the end of 2019 we reached a point where our visual identity didn't match our product evolution or our increasingly greater understanding of our brand values. Futhermore, on the pratical internal operations side, we lacked a unified design compass that would ensure consistency across designers, products, and channels. 

To incoporate our product maturity and design indentity expectation, we went back to the drawing board to create a holistic, consistent, and scalable design language to use within all of our products and in our marketing and sales efforts.

## The process
While Layerise already had an complex branding identity, we never really felt it managed to fully fullfill our values. We concluded that it lacked roots pointing towards our DNA. We wanted something that clearly, yet in a sophesticated maner represented who we are and what we do. 

Redefining coorporate identity, is not particularly straight forward, yet with deep understanding of our DNA, goals and values it easier to articulate opinions and purpose. To kickstart the process we conducted brand personality workshops to define the design identity realm which we want to reach. 

From the brand personality workshops a clearer picture was defined and we now had a formular to construct our new identity. In addition, to broaden our field of view and to conduct the branding excersize with the lens of our product we decided to specify our product goals in a design articulate fashion and include them in the discussions. Our product goals in product design terms: 
- Instantaneous
- Iterative
- Personal
- Re-invented

With the initial preeliminary work behind us and where the design aim point became clear, we decided to approach the logo craftmanship from a zero state, as if we were designing a logo from scratch. The whole idea behind the Layerise brand name is to control any "layer" of customer product engagement. In other words, we have always  considered Layerise's position as being the powerfull and experience rich intersection between a simple product and a full-fledge IoT product. The idea behind controling an layer means for us to move the product from a simple to medium complex product into something that have the same capabilites as a full-fledge IoT solution. For us an "layer" represents the ultimate understanding of what a customer goes through and engages with during the different steps in the customer to product life-cycle.   

![brand personality](//images.ctfassets.net/scrf7o05zai3/5PurNcB2AJ4zh27YLenqNA/c84e9f116379ccddf8494146778e1e7f/brand_personality.jpg)

By combining our personality workshop outcome with our goal and our "layer" lens we now have a great formular to defining the identity. It had to be masculine, simple, bright, slightly friendly and playful and be perceived disruptive. Furthermore it has to feel instantaneous, personal and modern. Lastly it needs to take "layers" into account.  

## Shaping things up
Right from the beginning we liked the idea around using a lightning bolt since it can visually bring: Instananeous and disruptive. And the lightning bolt also brings personality as it is often represented or manifested by the visual inclusion of the shape of the letter L. 

Adding a shadow between the L shape and the bottom line we could highlight the "L" and also bring the visual encouragement of "layers". 
![process updated](//images.ctfassets.net/scrf7o05zai3/1k93m7WUHdPhGUz3zIvHpr/47cf909689b09eb4ca1172bc769cc2ca/process_updated.png)

Futhermore, by playing with angles, colors, border-radius and placement we we're able to incorporate the last bits of our formular: Bright, slightly friendly and playful.
![rebrand thumbnail](//images.ctfassets.net/scrf7o05zai3/5uLTwoCYsXmrFhnzv449Mh/ca7df666dfccb33ab57827058a99d92c/rebrand_thumbnail.png)


## What's next
Our rebrand has been an incredible journey so far, and we're not finished. The foundation is set and within the next months we'll open up for our design system called Memphis to the public. 

We still have more work to do and problems to solve, and we’re thrilled to be able to share our journey with you.

Evolving the Layerise Identity

In Part 1, we dug into how we began dreaming of a new and different design process at Layerise. How we feel the current process was too cumbersome. If you haven't already, please read [part 1](https://www.layerise.com/resources/blog/post/reshaping-the-design-process-with-code-part-1 "Part 1") before continuing. 

As we concluded in part 1, our goal was to move from a rigid waterfall process to a more fluid and team-wide process. To achieve this, we added some milestones on how to accomplish this:

- One source of truth. No more requests for newest version or work with an outdated design package version.
- Setting up version control (Semver). Help the team get familiarised with the changelog and provide complete autonomy over the upgrade process.
- Quick prototyping. Promote quick prototyping is essential and should be possible both through code and visual editors. 
- Dedicated playground. Have one place to showcase, document, and test the design system. 

### One source of truth
This is something every designer, product manager, and developer has experienced. It is not unusual to see memes and jokes about design files called final1.psd, final2.psd, thisisthefinal.psd. 
As we talked about in part one, there is no such thing as a final design. Design is iterative; hence having a file representing a design version isn't a good idea.

We looked into the developer tooling and solution landscape to seek out a solution. We were impressed by how open source and package registries allowed for a more open, shared and interactive truth without the loose of control or degradation of the truth. 

However, going down this route meant a quite big mindset change. Moving away from only visual editors into a programming editor is a big switch. Nonetheless, by utilizing a package registry, we can publish and update our *one source of truth* and allow the individual user the right amount of granular control by targeting specific versions.  Furthermore, this allows for a much closer relationship with our developers since they can create a design issue or make a pull request which is in line with how they work.  

### Version control
Many designers have hopefully been introduced to some version control, though usually, it's only the major version, like 1.0, 2.0, etc. In most cases, this is because design used to be done in a more vacuum-based process, where only UX, Product Managers, and Project Managers participated, and the end goal was a huge chunk of views/screens that needed to be updated and delivered. 

This needed to change, as having an one source of truth powered by a team-broad always-active design process, the number of major versions would naturally inflate. At the same time, the need for minor and patch updates are needed to allow for a more iterative process. Moreover, with an increase of version roll-out frequency, it is good practice that the participant of the design system understands what's been updated in each version. So whenever a major or minor version is bumped, looking into the changelog is required. On the other hand, with patch version bumps it is recommended to read up on changelogs as patch updates are pushed accessibility issues, bugs, and small visual tweaks. The official guidelines for Semver are defined as:

- (1.0.0) MAJOR version when you make incompatible API changes,
- (0.1.0) MINOR version when you add functionality in a backwards-compatible manner, and
- (0.0.1) PATCH version when you make backwards-compatible bug fixes.

### Quick prototyping
While having one source of truth stored as code packages is suitable for control and sharing, the need for a quick prototyping ability is still very essential in the design process. The need for scaffolding many different variations and flows for the user experience exist and is in many ways where the design team's most crucial task is. Yet, these prototyping methods are spread across many different levels of fidelity. 

The lowest level of fidelity is pen and paper or drawing on a whiteboard. This level allows the whole team to easily participate and is usually more of getting a common idea of what's needed, like a rough scoping. Depending on your teams' size, there can be multiple levels of fidelity after the first one, like wireframes. 

At Layerise, we still have the wireframing step, but it might be a bit different than other teams. Our wireframe step is merged with the design handoff step since we're have created a continuous integration with our design tools. If your visual editor of choice is Framer X, you can grab the newest design packages through our shared store, which auto-updates on every new version. Using Sketch or Figma? Then you can download the latest version of each design component through our design system platform (We'll dig into this further in the next paragraph). By having a continuous integration, we allow quick prototyping in visual editors with the newest design version available. 

### The design platform
In a traditional design process, the design usually lives in files. Though, this isn't the case with our setup. Since our interface and components live as code we needed a different solution. We're using [Storybook](https://storybook.js.org/ "Storybook") which allows us to document, test and design our design system. Storybook has add-ons built-in which in return allow us to test with real data, test for accessibility issues and responsiveness. 

With the way we use Storybook to handle our design library, the individual Layerise team member can learn about how to use each component, in which context and what tweaks that are available. Moreover, since our design now lives in Storybook, members of our team have the newest design at hand anywhere. In essence, the whole team can now instantly get the newest design whether its a component or a color tweak. They can furthermore read the changelog and get notified for new changes. 

Our new design process has been under development for the last year, and we're still tweaking the process to come closer to our goal of having one source of truth while the whole team can participate. We're very close and look forward to letting you get a deeper look into what the daily workflow looks like in part 3. 

Reshaping the design process with code – Part 2

As a part of several posts on how we are reshaping the design process with code, we will begin with an introduction to how it all began.


At Layerise, we are on a mission to ensure that everyone in the team can and is empowered to design. Design should not be produced in a vacuum and it should be a constant iterative process without an end.
— In fact, there is no such thing as a perfect design since the demand for new experience, new technology and digital standards keep evolving.

To comply with the need for fluid and team broad design methods, we have decided to create a new design process from the ground up. But how do you bring together the whole team to prototype and participate in the design process?

### The end is the beginning
To understand how we design we conducted an internal exercise, an exercise based on presumptions. We needed to understand what design is and how we make design. Here are some of the interesting presumptions the team came up with: 


1. Designers don't code. 
2. There too many steps from idea to delivery.
3. Responsive design is cumbersome.
4. UX can't be accurately tracked.
5. Too much software is needed in the process.


This is just a few of many interesting presumptions. Next step was to dive into these presumptions and try to understand them. 

One presumption kept being brought up. Designers don't code. A never ending question in the design community and among scholars. But in our case it became a very interesting topic, as we all had challenges with not being able to implement our own design. Emulating the design implementation in a graphical editor just seems to be a slow and tedious process and the design implementation was always impacted by the tools used, the reviews and resources. 


Code seemed to be the goal, but an untouchable goal. When design was delivered the process stopped and a new sprint began. The only iterative process was when that particular area/feature had to be changed. So we began to play with the idea that we could code. What did that mean for the design process? 

1. We will be able to do interactive design.
2. We could deliver responsive components.
3. We could work with applicable animation and interaction. 
4. We could setup tracking and measurements per component.
5. We could have one source of truth from design to implementation.
6. We could limit the amount of steps. No more handoff!
7. We could invite more team members to participate and leave design feedback.

While this sure seems like a dream process we where still interested in understanding why so few designers had jumped into coding. We invited some of our developers to participate in the discussion. The answer was as you probably anticipated, starting to learn code felt overwelming.

However, a recent technology and DX (developer experience) leap has allowed designers to jump into code easier than ever. 
> Frameworks like React and ideas like CSS-in-JS have many concepts we know from the design world. Components and props are similar to Sketch's symbols and overrides. 


That didn't sound that scary, we were intrigued by this. 
In the next several posts we will dive into how we went from a rigid waterfall design process to a fluid iterative process. How we managed to become multi-disciplinary and what it means for the design team and the design output. 







Blog

Have a question?

Trusted by companies like