Spruce Labs's mission is to help brick and mortar retailers thrive by enabling them to create great experiences. Founded in 2016, the team created Sprucebot (or Spruce for short) at Spruce Boutique in Denver. From day one, Spruce has found success by combining technology with a human-centered approach to experience management.

As Spruce’s principal designer, I led the design team's strategy and execution. This included product and visual design, illustration, and a bit of frontend web development.

For years, Spruce had evolved without any real design direction. We had created a small and simple library of components early on, but it hadn't changed in several years. As a result, component availability became the driver of experience design. This created an experience that felt wonky and awkward. On top of that, there was internal confusion on the team due to lack of a shared language around the product.

My goal with Heartwood was to create a shared design language to help our team improve Spruce. I decided early on that this would be more than a component library. We needed a tool, or a set of tools, that would scale with the product.

There were two key considerations at this phase. First, we wanted to enable designers to influence the product with minimal risk. Second, we wanted to avoid slowing down the engineering team's workflow.

Using the architecture as a map, the next step was to define shared visual styles. We divided our styles into six main categories: color, typography, spacing, iconography, layer, and motion.

We began by focusing on how we could apply the principle of Humanity to our color palette. Citing the Curb Cut Effect, we elected to make accessibility a focal point (WCAG AA to be exact). This led us to change our "primary" color group from a hard to read green to a much punchier blue.

Next we focused on applying Physicality to our colors. In particular, we noticed that the use of pure grey felt too computer-y. Nothing in the physical world is 100% neutral grey. To make the product look more natural, we saturated our greyscale. The result is a greyscale that feels more like ink or stone.

We began our type exploration by searching for a super family with the right features. It was important to pick a family that included a sans and a monospaced typeface. Having both would ensure a high level of flexibility while maintaining cohesiveness. We’d consider a matching serif face a bonus, but not necessary.

We ended up choosing the Source family. These faces had the widest language support and largest set of OpenType features of anything we looked at. Even some of the paid options we considered had fewer features.

I developed an extensive type scale based on the formula X₂=X₁+{INT[(n-2)/4]+1}×2. This creates integer font sizes which are as easy to work with in code as they are in design. Using a formula enabled us to generate far more sizes than we would need for the time being. As new challenges emerge the formula provides a starting point to add new sizes. We narrowed down the initial set to a few styles for immediate use.

The component design phase began with the humble goal of parity. It was important to make sure we didn't forget to update any existing components. This would let us phase Heartwood into production without breaking anything. To ease the transition, we did a thorough audit of the existing codebase. From this audit, we redesigned each component to use our new shared styles.

The previous round of component design was lacking in detail. This caused a problem for the design team. To see a component in detail, one would have to look at production, which was often unstable. This situation meant the design team was often blocked from making progress. To solve this problem, we added in-depth details to our design documentation.

Next we focused on new components that would improve the product experience. We found low hanging fruit in cases like the nonexistence of a checkbox component. In other cases, the solutions we were after required more discovery.

One of the biggest pain points we kept hearing from users was that they had to jump around a lot to do their jobs. This felt unnatural, awkward, and frustrating — the antithesis of what Spruce should be. Even if a user knew where everything was, there was a lot of opportunity for improvement. We asked ourselves what role Heartwood components could play in solving this problem.

To figure out which components we needed, we did some competitive analysis. The all-around best solution we found was the concept of a card-based interface. This would solve a couple of big problems. First, we could serve up custom tailored content to specific users. Second, we could use cards to shift the product from task-oriented to people-oriented. This people-centric approach felt more in line with Heartwood's
design principles.

We spent a week or so brainstorming about cards. We focused on what we could use them for, where they would live, and what types of content they'd need to support.

We landed on a few variations that each tied to at least one use case. These variations informed the design of the card components.

We opted to move into code before our component designs were 100% complete. The idea behind this was to kick the tires on our system architecture before getting too far. We also found that for certain components, it was faster to make changes in code.

Spruce is an experience engine. We couldn’t call Heartwood camera-ready without using it to design some experiences.

To begin, we redesigned the global onboarding experience. We identified a couple of core problems with the current flow:

1. It wasn't easy for a new user to add or confirm their personal info.

2. The onboarding experience lacked personality and failed to build rapport with new users.

3. We duplicated effort by having different onboarding experiences on web and iOS.

The new card component was a perfect candidate for the task at hand. We had already considered an onboarding card as one of its use cases. The advantage of having some of the simple design decisions already made was that we were able to focus on the trickier parts of the problem.

For example, we can't be 100% sure what information we already have when someone signs up. If a new user signs up from an invite, the person who invited them may have already added their name or photo. On the other hand, a phone number is the only requirement for an invitation, and a user could be signing up on their own.

Starting with the card component also freed up some time to focus on illustrations. These helped lend the experience some personality.

A good appointment booking experience is mission critical for service-based businesses. Spruce's old booking flow worked well for customers, but not for employees. It turned out that one size did not fit all after all. To remedy this, we created a booking flow tailored to employees.

The main consideration for employee booking was to start with a calendar view. On large enough screens, we opted to keep the calendar visible. Desk staff and receptionists tend to use large screens and like to see the whole team's schedule. This view makes it easy for an employee to find an available time and provider.

We found that service providers tend to book their own appointments on their phones. This presented a challenge. We had to make sure that no interaction relied entirely on the calendar being visible. To solve this, we introduced some new components. Some of these turned out to solve problems outside of booking.

Customer booking stayed as it was for the most part. The key change was how a user selects a service to book. The previous iteration had two separate steps for service and provider selection. The new flow makes provider selection a subtask within service selection. This turned out to be more intuitive to customers, and was a performance gain for the app.

The other crucial change to customer booking was to make personal info the last step. This “lazy” booking makes it possible for potential customers to browse without committing. Our theory was that it would also result in a higher rate of successful bookings.

Heartwood began with a focus on the core Spruce product. As we moved forward, there was some divergence between product and brand design. We decided to use Heartwood's core principles to refresh the Spruce visual identity. Our goal was to make the end-to-end experience more cohesive.

The old logo always felt a bit off, for reasons the team found hard to vocalize. Looking at it through the lens of Heartwood's Humanity principle made it clear. The logo was frowning. The solution was to make it smile.

Our new color palette was a bit spare when it came to expressiveness. We devised an approach that would focus on how we create contrast, rather than on specific colors. This enabled our creative team to try lots of ideas and push the envelope. At the same time, we had enough parameters to avoid visual chaos.

Our default avatars presented an opportunity to bridge the brand and product experience. We had been using one default for every new user, which was easy to put in place, but caused some problems. Using one default for everyone made it hard to differentiate between new users. To solve this problem, we decided to create a set of placeholder avatars. We gave ourselves some parameters to work within:

• Avatars have to work on light and dark backgrounds

• Avatars should be inclusive and make users feel welcome

• There shouldn't be a reason that someone would want to pick a specific avatar

The first round of exploration used rough line work and some textured backgrounds. This approach created a decent set of avatars, but felt a bit risky. The line work approach seemed like it could become gendered as the set grows.

The next round went more abstract and punched up the background textures. The big grins on these felt a bit cheesy and the set was
too homogenous.

The third round used a more photographic approach. We toned down the smiles on these and found that we could generate new ones quickly as an added bonus.

We auditioned this round in the interface and decided to go with it. This approach checked all the right boxes and we felt confident that we could add to it in the future.

I left the team at Spruce Labs with some free ideas of how to grow and evolve Heartwood in the future.

The biggest remaining gap was theming. While we had laid the groundwork for it, there wasn’t any real documentation or strategy. We decided to create “day” and “night” modes to kick the tires on one potential approach. The main lift was to define semantic colors, which we could swap out to switch between modes.

Explorations in theming also led to the development of Heartwood Tokens. We broke these out into a separate project and I created a static website to share with the team. Giving tokens their own home has the added benefit of making Heartwood more scalable. This opened the door to Heartwood evolving into a more robust set of tools with a cohesive foundation.

Heartwood has already gone a long way to make Spruce useful, usable, and beautiful. By providing a shared language, it has equipped the team at Spruce Labs to continue evolving their core product. Heartwood will continue to play a role in defining the future of brick and mortar retail.