
# FigLog Evolution Tracking Widget

<Label>Primary Goal</Label>
<Text>Creating a simple way for designers to track design decisions within the Figma canvas</Text>

## My Process

### The Problem
    The idea behind [FigLog](https://www.figma.com/community/widget/1293230657540297914) originated when my colleague Ryan Srofe and I were tasked with maintaining and expanding a client’s design system. Despite a thorough handoff process when joining the project, we realized a lot of the context that had informed the original design decisions had been lost. 

### Creating an MVP

    Sensitive to this missing context and familiar with version control history logs, we had the idea of creating a Figma component that we could use to log changes as we started making adjustments to mature the system. Using the component was helpful, but it was also very manual, which started us down the path of what it would take to make logging changes simpler. Ryan described the process in detail in [this blog post](https://nearform.com/digital-community/figma-widget-figlog/), but in short, trying to simplify the change logging process led to creating the minimum viable version of the FigLog widget.


### Upgrading Features and Improving Functionality

    As the widget started gaining users we gathered feedback on features they wanted to see and those became the basis for the Version 2 of Figlog. I took the lead on upgrading the widget for Version 2: optimizing the code for the existing core functionality and building requested features - automatic date stamping, log statuses, editable logs, and linking to additional content.

  
### Building Within the Confines of a Widget

    Adding the needed features to a web or mobile application would be a relatively simple proposition, but a guiding design principle for FigLog was to make it feel as “native” to Figma as possible. Keeping the widget light weight and keeping its functionality on the Figma canvas meant creating a tool only with the Figma provided building blocks. Doing this required a lot of flexibility and creative problem solving.

    <ResponsiveImage src={'images/projects/figlog/creating-a-log.png'} width={1595} height={380} alt='Screen shot of the log editing interface with automated date entry, add link button, and delete log button.' wrapper />

#### For Example:

    Thanks to Figma’s default rendering order, dynamically showing a dropdown menu causes the menu to render beneath the elements lower on the canvas. This issue nearly stopped log types from being implemented, until I decided to consider the issue from a different angle. Displaying the menu horizontally avoided the overlapping issue entirely.

    <ResponsiveImage src={'images/projects/figlog/log-type-dropdown.png'} width={1270} height={195} alt='Screen shot of the active horizontal log type selector' wrapper />


    The text input element for plugins and widgets do not allow for text formatting in the same way that text boxes within Figma do, so linking from within the log text was not an option. Instead, I pivoted to integrating the links via a form and listing them below the log as clickable pill buttons. This had the side benefit of allowing me to integrate regex to match the most common link sources with icons matching the source logo.

    <ResponsiveImage src={'images/projects/figlog/log-with-link.png'} width={1600} height={373} alt='Screen shot of the active horizontal log type selector' wrapper />

    Then there was the struggle of Figma not having a real concept of a “form” so all input elements had to be validated and strung together using JavaScript to get data into the correct format. 

    <ResponsiveImage src={'images/projects/figlog/link-form.png'} width={1522} height={121} alt='Screen shot of the active horizontal log type selector' wrapper />

    Complexities aside, we were able to deploy Version 2 of FigLog within a few months of the initial launch, and have continued to respond to user feedback in Versions 3, and 4. FigLog’s user base is expected to reach 10K before the end of 2025.

## What I Learned

    Working on FigLog was a fun paradigm shift in a couple of ways — first, this is a product where I am both product owner and a core user — something that granted me an unusual amount of design freedom. Secondly, building within Figma has been a fascinating exercise in solving problems with minimal tools. Web and native application tooling has come so far from their simple beginnings (I’m not complaining), but needing to solve a problem with a very limited set of tools pushed my problem solving limits in ways that standard projects sometimes don’t.

    This project also tapped into some of my favorite things about the work I do — getting to build tools that make pieces of people’s lives better, and tackling difficult problems by thinking about the problem from as many different angles as possible — because sometimes we need to question the assumption that something has to be vertical and try making it horizontal instead.


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

FigLog Evolution Tracking Widget


# 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


# Improving Adoption in PUMA’s Design System

<Label>Primary Goal</Label>
<Text>Understand design system usage and support business goals by increasing system adoption.</Text>

## My Process

### Assessing the Current State
  When I joined the PUMA Design System team a significant amount of work on the design system had already been completed. They were past the early phases of defining foundations and deep into the weeds of building out minor components.
  
  After a minimum viable design system is launched, it can be easy to get lost in the middle phases of growing the system as an internal product. In the case of the PUMA design system, the team had solid buy-in from designers. The increasing adoption of design system components within Figma was largely measurable using Figma’s internal tracking tools, but understanding adoption on the engineering side of the equation was much less straightforward.

### Quantifying System Adoption

  One of the challenges with design systems can be quantifying the long term efficiency improvements that they create in order to enable business leadership to advocate for allocating resources toward the system.

  Tracking engineering adoption, when spread across multiple ecosystems can be quite complex. The team’s long term goal was to increase adoption. This meant we needed a way to measure it first. I evaluated the available tooling options to gather metrics, and I seriously considered [Omlet](https://omlet.dev/) — unfortunately at that time their platform wasn’t mature enough to gather the data we needed. So instead I wrote a custom script on top of the react-scanner package that could be run with every sprint to generate numbers tracking component adoption in our core applications. The script generated data around which components were being used and where they were used, and what percentage of app components were either system components or used system components.

### Communicating with Leadership

  It wasn’t a perfect measuring system, but it allowed us to go from having no data to having a benchmark of information within a couple of sprints. After cross checking the information for a few sprints, we were able to start reporting change/trend data to senior leadership every sprint. The adoption data was an accessible progress report that non-technical leadership could relate to, so it majorly strengthened our communication around system work with key business stakeholders. It also helped the systems team show that our work was aligned with business’ long term goals.
  
### Addressing Knowledge Gap Between Engineering and the Systems Team

  A known issue that our adoption data supported was that there was a lack of understanding about the system components and capabilities amongst the engineering teams building PUMA’s applications. This can be a tricky problem to solve due to design system teams being separate from the engineering organization. Ideally system awareness can be improved by creating stronger collaborative relationships between systems teams and engineering, but in PUMA’s case the constantly shifting nature of their engineering organization made this unfeasible. So instead we tackled the problem by building up documentation where the engineers naturally looked for it — [enter Storybook playgrounds](https://uds-storybook.production.cybercat.puma.com/).

  Storybook launched docs pages in their newest version around this time, and it was clear that while upgrading our 100+ component storybook instance wasn’t going to be a lot of work, there was also a clear ROI to being able to use all of our existing stories as the playground style documentation the engineering teams had told us they were looking for.

  Upgrading our Storybook version and adding more real-world integration examples for improved documentation required rewriting about a third of the 100+ component stories and most of the context files to keep everything working. I followed that with an audit to make sure that all of the component parameters were noted for documentation and available in the component playgrounds.

  Giving the engineering teams access to this resource significantly improved awareness of system components and capabilities within engineering teams, which quickly turned into a steady increase in system adoption within new features and fixes.

## What I Learned

  A lot of focus is put on the initial launch of a design system: getting the foundations right and making sure to include the right set of components, but once you get the system launched it’s long term success isn’t only up to the capabilities of the system. Without regular communication of system objectives to business leaders, ensuring that the system is supporting larger business goals, and making sure that both design and engineering teams are integrated into the systems processes a design system won’t be able to thrive as the internal product acceleration tool it is intended to be.

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

Growing PUMA's Design System


# 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