
# 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

User Research and Rapid Prototyping

Web3 DApp

Enterprise Web and iOS Application

E-commerce Redesign and Replatform

Product Information System Redesign