
# Aligning Design and Development in PUMA's Design System

<Label>Primary Goal</Label>
<Text>Improve developer handoff and minimize design churn by maximizing parity between Design System components in Figma and their counterparts in React</Text>

## My Process


  As a Design Engineer I often have full visibility into both the design and engineering processes on projects. This viewpoint is particularly useful in design system work because of the key role that design systems play for both designers and engineers on large scale projects.
  
  I joined the PUMA design system team as the system was starting to achieve maturity, the foundations had been established and core components had mostly been built. As a system grows it becomes easier for small differences in naming conventions and approaches to component structure — often caused by functional limitations between design and engineering tools — to become larger mis-alignments. The lack parity make it more difficult for designers and engineers to communicate and collaborate on features — ultimately limiting the value added by using the design system in the first place.

### Diagnosing the issue

  Despite the solid documentation on the system, the disparities in naming conventions and structure because obvious when I started digging into the design and developed components. It was also clear in talking with both designers and engineers that the differently named parameters and sub-component structures were causing regular miscommunication during handoff. Engineers used Figma to analyze designs, but when it didn't match the reality of the React components they were supposed to be building with — they were left to guess at the designers intention, and often either asked the designer to rework their design to match what was possible, or built out a custom solution — increasing the platform's technical debt.

### Presenting the problem and solution to leadership

  I raised the issue with key stakeholders — including testimonials from team members I had talked with highlighting the problems it was causing. Leadership recognized the severity of the problem, how it was hindering adoption of the design system, and approved a short pause on new features in order to audit all existing Figma components and bring them into parity with our React system. 
  
### Auditing, upgrading, and communicating changes

  An audit and upgrade of nearly 100 Figma components was not small thing, but it proved invaluable to the handoff process. By building Figma components in a manner than sought to optimize their flexibility and reuse for designers I was able to mirror their structure and parameters to their engineered versions much more closely — subtly guiding designers into using components how they were built to be used in code.

  A key part of this upgrade process was also communicating with the design teams using the system. Many of the upgrades to components were breaking changes compared to past versions of the system so collaborating with design users was key to successfully launching the updates.

  Another advantage to opening the lines of communication with the design teams early in the process was that it gave them plenty of time to understand the goal behind the updates — less rework on design proposals and smoother developer handoff. Because they understood the reason behind the changes they were much more willing to help us with testing the update, and highlighting any potential problems so that we could handle any issues collaboratively. This approach meant that the rollout went smoothly and avoided the elevated emotions that can sometimes come from changes to daily process.

## What I Learned

  This project is one that I might never have tackled if I wasn't a Design Engineer. This type of maintenance upgrade is often a tough sell to leadership due to the time investment required, but my ability to look into and compare both the Figma and React components allowed me to largely handle the update without additional engineering support decreasing the overall cost to complete the project. It also highlighted for me the deep value of close collaboration between designers and engineers when it comes to building software. Few teams enable their designers and engineers to have a close enough working relationship that component design structure and code structure achieve the kind of parity that helps a design system provide maximum value. In my opinion the investment it takes to achieve this type of parity in design system components pays for itself quickly as the system is used at scale by design and engineering teams.

  I go into more detail about why I find this way of working valuable and the key things needed to get started in [an article on Nearform's blog](https://commerce.nearform.com/blog/2024/power-of-mirrored-components).

export default ({children}) => <Project>{children}</Project>

Aligning Design and Development at PUMA


# User Research and Rapid Prototyping

<Label>Primary Goal</Label>
<Text>Prototype a viable solution for integrating Figma into existing software — based on user needs and technical feasibility — in less than six weeks.</Text>

## My Process

### Researching User Needs

  The client received requests from users for a "Figma integration" and they sought an answer to what exactly that meant in terms of features and requirements to their users. To gather a holistic picture of what users were looking for I conducted a competitive analysis, user interviews, and existing user data analysis.

  Familiarizing myself with my client's competitors provided me with an initial checklist of possible features for this integration — essentially answering the question by analyzing others' conclusions. Taking that list, I was able to prioritize possible features based on user feedback in interviews and on analysis of existing user data.

  My research resulted in a list of potential features prioritized by importance to users.

### Vetting Technical Feasibility

  Taking a deep dive into Figma's API, and gathering information about the client's current system allowed me to apply a technical level of effort to the features on my user-prioritized list. Resulting in a list that clearly identified which features would provide the client with the most value for the least amount of effort.

### Prototyping A Solution

  Using my research - I created a basic prototype that modeled the highest value feature for the client. The prototype was intentionally simple and platform agnostic, but it demonstrated for the client that the solution I had proposed was technically feasible while providing the engineering team with a baseline approach to expand into a fully-fledged solution.

## What I Learned

  A prototype doesn't have to be a fully functioning app. This project expanded my definition of a "prototype" to include a working sample that proves an idea - even if it is separate from the larger application ecosystem. The limited timeline of this project forced me to focus my prototype solely on proving that my approach was viable. It allowed clear communication of the idea to the client, and it provided enough technical documentation to their engineering team to set them up for success.
  
  In short, the best solution doesn't have to be complicated.

export default ({children}) => <Project>{children}</Project>

User Research and Rapid Prototyping


# Web3 DApp

<Label>Primary Goal</Label>
<Text>Build a design system and rapidly iterate to bring a minimum viable product DApp to market on Ethereum Mainnet.</Text>

## My Process

### Establishing an MVP

  The client handed us a partially built project, so establishing the core features was a key starting place. Leading the discovery, I helped to build consensus amongst the entire team by creating a flow diagram that mapped the most important features of the application. 

  That document allowed us to create a feature list and do the collaborative exercise of connecting those features with the different parts of the application to be sure we had captured all of the necessary features in our backlog.

  From there our team could establish a data structure for the core elements of the DApp — and thus work simultaneously on building out the API, chain integrations, and user interface.

### Building a Design System

  My focus was on establishing the design system that would allow us to rapidly standup the key features of the application and having a working prototype as soon as possible. A design system always begins with global variables and mixin/function utilities. Once those are established, I start building out core components that test out the global variables and help me to make adjustments as the system starts to take shape.

#### Why a Design System?

  Taking the time to build this way is actually slightly slower at the beginning than just throwing together a nice looking layout and building it from scratch, but the value shows through as an application begins to scale. Once core components — text, button, link, layout containers, icons, and form inputs, etc — are built, it becomes possible to start new features with a simple wireframe and produce a functional prototype — no high fidelity mockups required.

#### Component Driven Development

  The pattern of component driven user interfaces partners well with test driven development practices as well as documentation add-ons like [Storybook](https://storybook.js.org/). Essentially, a little bit of extra effort up front improves both the developer and user experiences with the application. An intrinsic part of my skill-set is building out components and tooling that empower other developers who may not have my design sensibilities to build out new interface features with existing components while maintaining consistent interface patterns that lend themselves to excellent user experience.

## What I Learned

  **Next.js and how to migrate a late stage React app to Next.js** 
  
  Shortly before launch, it was discovered that this DApp needed server side rendering capabilities for a particular feature which the client considered essential — a major problem as the beta DApp was deployed on [Vercel](https://vercel.com/). After exploring all other options, we decided to migrate from CRA to Next.js in order to maintain the rest of our stack and use Next.js' built in SSR functionality.

  As the person with the most technical experience on the team, I did the primary migration. I was also brand new to Next.js, so I was learning Next.js while figuring out which of the features built in React would need to be modified to play well with Next.js' modified application structure. Overall the process went smoothly. It took longer than anticipated, but was ultimately successful and allowed us to launch the full product only a few weeks later than originally planned.

  I learned a ton about Next.js and have built several things using it since — including this site!

export default ({children}) => <Project>{children}</Project>

Web3 DApp



# Enterprise Web and iOS App

<Label>Primary Goal</Label>
<Text>Create an expense management platform that integrated with existing data sources and custom workflows.</Text>

## My Process

### User Flows, Data Model Creation, and Technical Vetting

  Despite joining this project after the initial discovery phase, I collaborated closely with the client's UX Designer to create user flows for app features during our sprints. We also collaborated on his designs so that I could vet them for technical feasibility and whether changes would require adjustments to the core data being produced by the the API.

  My preferred workflow involves deciding on the shape of the data required being kicking off a new feature, so that the team can work on the interface, front end, and back end simultaneously — vetting designs up-front is a small thing, but it makes that workflow possible.

### Design System Creation

  Incorporating the client's designer into our sprints meant that design system development and the core feature design took place simultaneously.
  Thankfully, following component driven development patterns enabled us to work in tandem. I could build out the components needed for the feature and establish some basic styles using global styling variables and mixins while my UX Design colleague was making final adjustments. As long as we were communicating well. Receiving the final designs normally just required a few adjustments to finish the feature — allowing us to complete features more quickly than a completely separate design development process.

  #### Key Features of the Design System

   - **Global variables** — setting app globals for color, spacing, and text is important for maintainability and scalability.
   - **Mixins/Functions** — using built-in Sass functionality to create styling utilities that make it easier for either myself or a Front End Developer to update the styling while following the established patterns of the app.
   - **Component Modules** — establishing core components that are utilized everywhere, e.g. Buttons, Links, Form Inputs, etc. Keeps the styling of that component in one primary location, and makes it easy to document variations in Storybook, or other tools.

  #### Converting the Design System for iOS
  
  Alongside the web application we also built an iOS NativeScript application, and I created a custom design system for the app. Ideally the two applications would have shared a system, but because NativeScript does not support the same CSS styling rules as the browsers that was not an option. Instead I created a similar, yet customized version of the web application design system for the iOS application. I followed the same basic principles — Global Variables, Mixins/Functions, and Component Modules, but I modified the styles to utilize more of NativeScript's inherent styling and layout features. This approach lends the best parts of any styling system — reusability and modularity — to the application, while incorporating what NativeScript does best.

## What I Learned

  I learned both Angular and NativeScript working on these applications. I am passionate about learning new things, and while it is always a bit daunting to tackle a new project on technologies I am not completely familiar with, I also enjoy the challenge.

export default ({children}) => <Project>{children}</Project>

Enterprise Web and iOS Application


# E-commerce Redesign and Replatform

<Label>Primary Goal</Label>
<Text>Modernize an enterprise scale e-commerce site by redesigning the user experience and relaunching on a new software platform.</Text>

## My Process

### Internal Discovery and Platform Selection

  The full overhaul of a decade-old e-commerce site is a large undertaking, so extensive discovery was a key part of the process.
  
  #### First, Map What Exists

  Mapping the customer and internal facing site functionality was done collaboratively. I focused on creating user flows for: on-site search, e-commerce checkout, and internal order processing. 

  I created documentation and user flows from existing site data, working with developers on edge cases documented in the code, and from interviews of internal stakeholders.

  #### Second, Choose a Platform

  As a member of the panel selecting a new software platform, I was able to use the documentation and user flows my team created to support an informed software platform choice that maintained our technical stack, integrated with the internal legacy systems, and created a foundation for future upgrades.

### User Tree Testing

  Our existing data around how customers were using our navigation was inconclusive. So I advocated for taking the time to run tree tests on our navigation with remote users via [Optimal Sort from Optimal Workshop](https://www.optimalworkshop.com/optimalsort/). These tests provided the necessary information to make data driven decisions around our navigation. Whenever possible, I prefer to let user behavior inform my UX design choices.

### Creating a Design System

  Creating a design system allowed us to bring the site into alignment with current brand guidelines, and ensure it could be easily maintained in the future. I set up a component system within Sketch that allowed us to focus on reusable components that could be configured throughout the site to create the core functionality that was needed.

  The design system was built in conjunction with page templates and other features so that it could be adjusted and polished across use-cases as we worked to lay out the full functionality of the site.

### Designing Core functionality

  The core features of any e-commerce experience are: navigation/search, product listing pages, product detail pages, and checkout. On this project I focused on on-site search.

#### Search

  The primary goal of search is to make it easy for users to find what they are looking for. That requires fast results, displaying the right amount of relevant information on result listings, and making it easy for users to browse results with appropriate sorting/filtering controls.

  The new platform vastly improved the speed at which results were returned, so my primary focus was on sorting/filtering and result cards.

  ##### Filtering

  Due to the expanded product data — [provided by an earlier project I had done](/work/product-information-redesign) — there was a much greater number of attributes available to filter by. Besides the additional data was also taking into consideration the best way for the user to interact with that type of data — checkbox, range slider, text input, etc. The nature of the product being sold also lends itself well to filters that incorporate graphics to help the user more easily differentiate their options. I incorporated all of those decisions into how the filters ultimately looked, which included designing a custom icon set to be associated with a large number of the filter attributes.

  ##### Result Cards

  Result cards are complicated because the space is minimal, but the decision point is high impact — customers often make a judgement about whether to explore the product further when looking at the result card — so it can be an important place for key messaging. Getting the hierarchy of the elements — photo, title, price, etc — correct is important because the user needs enough information to make a decision, but not so much that they get overwhelmed.

  Finding the balance of information to include on the cards was also not purely a design decision, it also included conversations with internal stakeholders about why certain elements should/should not be included in the cards. Ideally, this type of high impact design decisions are tested using multi-variate testing to gather from user behavior what is truly the best option.

### User Testing the Prototype

  Another key feature of this redesign was running remote user tests on the rough prototype with [UserTesting.com](https://www.usertesting.com/). The tests focused on how easily users could find product and key product information as well as feedback on their impression of interacting with the site. Analyzing the results of these tests largely validated that the decisions we had made were in the correct direction to move the site experience forward for our customers.


## What I Learned

  This project used [Storybook](https://storybook.js.org/) as a place for the initial UI development that happened in conjunction with the design process. The resulting shorter feedback loop made refining the design system significantly easier. It also allowed the design team to be better integrated with the Agile sprints the development team was doing.

  Closely integrating the design and development teams produced better outcomes faster on this project, and has continued to do so on projects I have worked on since. As someone whose skills span both design and development, I always find ways to bring the teams closer together on any project I work on.

export default ({children}) => <Project>{children}</Project>

E-commerce Redesign and Replatform


# Product Information System Redesign

<Label>Primary Goal</Label>
<Text>Prepare to rebuild on-site search and product detail pages by restructuring product data and upgrading the internal Product Information Management (PIM) system.</Text>

## My Process

### Research

With the goal of providing a holistic view of what data we should be collecting about the various types of product sold, I did four things:

#### Documented Existing Data

  Because the existing system did not have any documentation, I began by defining all of the existing data points and mapping them to our product types by the help of the Product Information Team.

#### Interviewed Customers and Stakeholders
  
  I spoke with customers and the website's primary internal users about how they interacted with on-site search filters.

#### Existing Best Practices

  I reviewed existing white papers to make sure we were incorporating known best practices for search experiences and product information.

#### Competitor Review
  I catalogued what attributes competitors in the space were providing for their customers in terms of search filters and product details.
  

### Internal User Testing

  Getting this data model correct was important for saving time and energy in implementation and training, so I took the time before implementation to vet the data model with the primary users — the Product Information Team.

  Walking through various product examples exposed a few places we had missed necessary use cases for some products — allowing us to refactor the data model now instead of refactoring the implementation later.

### Implementation

  Throughout the process I vetted the data shape with our developers to be sure it would be supported by the new platform. As implementation got rolling, that was mostly proven true, but we quickly ran into several blockers in the form of late-discovered internal systems that needed to be supported with the old data model. Through small batch testing we managed to incorporate most of the data changes, but the process was much slower than anticipated.

  In addition to the data model, I designed spreadsheets that integrated with the new system and allowed the Product Information Team to automate the initial data entry for product. These spreadsheets ultimately decreased data entry time by about 70%, freeing up resources to other necessary e-commerce product functions.

## What I Learned

  **Make sure all the right people are included in discovery.** Several of the major challenges in this project related to key technical stakeholders not being included in the early discovery process. Discovery is rarely perfect, but having the right people in the conversation makes a huge difference.


export default ({children}) => <Project>{children}</Project>

Selected Work

Aligning Design and Development at PUMA

User Research and Rapid Prototyping

Web3 DApp

Enterprise Web and iOS Application

E-commerce Redesign and Replatform

Product Information System Redesign