Wingspan

Case Study 1

Financial services: Seed stage design system

I leveraged a lean design system that quickly brought cohesion to a financial services platform and the EPD team that built it. This project became the company’s foundation for more strategic (and less expensive) product development. 

Context

I came to Wingspan, a finance app for contract workers and freelancers, as the founding designer. When I arrived, the state of the product, like many early stage ideas, was a disjointed proof of concept that had secured a seed funding round, but was not yet finding product-market-fit. With the funding runway set, I was tasked with imparting a strategic, user-centered approach to bring Wingspan to the status of “all-in-one platform”. The main measure of success was to support the business’s goal of user growth.

Roles

I led design and project management and we had one engineering lead, and two developers.

Key dates

Initial socialization to business: May 2020
Begin focused design process: January 2021
Migrate existing components: April 2021

Problem

  1. Products at various stages of incompleteness. Priorities were hard to confidently define and pieces were tackled partially and inefficiently.
  2. Not yet all-in-one. There wasn’t a feeling of unification across the products, so Wingspan’s value proposition was not yet coming across to users.
  3. No product culture. The engineering culture was unharmonious and inexperienced regarding an iterative, user-centered approach.

Hypothesis

I audited the app and evaluated the full feature set from a systems perspective. My hypothesis was that introducing a lean design system would:

  1. Focus designs to reach feature completeness. Constraints would guide us to graceful and consistent polish across the entire platform.
  2. Obviate time spent on usability issues and bugs. Both user experience and engineering output and morale would significantly improve in quality.
  3. Define a better product development culture. This was the first project that required communication and collaboration between engineering, product, and design. I used it as a tool for learning how we could work together happily and efficiently.

How might we use a design system (instead of feature development) to unify multiple products into an all-in-one platform experience?

Prioritizing a design system over feature development

My goal was for a component library to be built in-step with the design system right from the beginning. My resolve was strong to break free of the common early stage pattern of building out a design system only for it to rot in Figma as engineering prioritized more “direct” and “immediate” goals. I advocated my vision to the team.

Long term perspective

Make feature development less expensive. By virtue of implementing it, applying the design system to the platform would improve usability, raising the overall quality of user experience across the board. With that generic improvement clearing a lot of UX noise, the lowest performing product could be more clearly assessed from a feature deficiency perspective. Development priorities would be more confident and strategic, wasted work would be mitigated.

Bundling within a project

Get the ball rolling with a quick win. I had had success in the past first applying a design system to a small contained project and I did it again here. Bounding the design system within a less overwhelming space allures engineers with a quick win. The feature got built, the design system kinks got worked out, then migration to the rest of the product becomes more exciting for all.

Planning the design system

Grid overview

Grid documentation

Auditing for a baseline

I took stock of existing usability issues with my own heuristic evaluation and feedback from users and user-facing teammates. A newly discovered trend was that our users were defaulting to mobile, even for long sessions of administrative tasks. Addressing visual inconsistencies from feature to feature was the lowest hanging fruit to quicken adoption and improve repeat session experience.

Establishing lean priorities

I created a scope for the very initial design system that struck a good balance. It was simple enough to create a sense of uniformity and expected convention across all major user flows.

The lean design system had only the following foundations and components:

  1. Grid
  2. Layout (navigation, page header)
  3. Typography
  4. Color
  5. Buttons
  6. Table

Some foundations: color, typography, spacing

Button and link documentation, Figma components

Form components

Introducing a review process

This was a brand new approach for leadership, so there were many stages of review for everyone to feel confident in pursuing this strategy. Design critiques, technical engineering evaluation, pre-launch usability testing, and in-prod usage evaluation were all techniques employed to make shipment a success.

A baseline education plus new tools and processes made the EPD team stronger

Implementation and migration

Fail: The new table in the "File Vault" project was not properly componentized for repeat application

Failed first attempt 

The engineering team had no prior familiarity with design systems or component libraries and the “bundling within a project” hypothesis failed to yield a component library. As the founding and only designer, I moved onto a different project post hand-off and my secondary contribution was insufficient for meeting the design system goal. My disappointment aside, this attempt served to solidify team buy-in for a more dedicated second attempt.

Updated table component

Sandbox: A multi-variant card component for ambiguous future needs

Eager implementation

A new engineering team was tasked with focusing on the design system without the noise of any additional goals.  My review process within engineering implementation became much heavier and helped yield the outcomes I had initially set.

The biggest challenge was that once we hit our groove, there was a push for me to design “all the components we will ever need”. It took extra effort to explain that without a defined understanding of the future use cases, this was a futile act. We were able to stop that scope creep before burdening engineering. 

Migration

I created an interface inventory with annotated screenshots so that 100% of upgradable components were handled. With this artifact, necessary rework to base components and new component instances was straightforward. The resulting consistency was an immediate happiness boost vocalized by users and the team. The rest of the engineers felt a new level of pride in their work - we had reached a point where the backend had connected harmoniously with the frontend. This satisfaction promoted greater care and quicker resolution of usability issues moving forward.  

Full scope of lean design system

Reflection

Lessons learned

My biggest takeaway from this project was to not hesitate to lead, even if technical areas are usually led by engineering. General engineering leadership does not smoothly translate to good execution if there is a lack of experience. My expertise, if pushed stronger from the beginning, would have gotten us to our destination sooner.

I also deepened my understanding of the lack of understanding of design systems in startup culture. The disconnect between a design system and its use in Figma with coded componentization is more profound than I had realized. I can now provide a more thorough initial education for inexperienced parties.

What’s next

Planning and execution was much more streamlined since we had come to a shared understanding of how to talk about components within a system. A few lingering complex custom flows could be reimagined and simplified to fit into our new design system. It also set us up for feature development required for our pivot from B2C to B2B2C. 

The biggest business impact was simply that this project connected our product to the story we were trying to tell via marketing. Upon login and at first glance on each module of the platform, the value proposition and potential of Wingspan was now clear. B2C acquisition and adoption was much more hands-free. We were powerfully poised for fundraising.

Atrium

Case Study 2

Legal: 0 to 1 project management for company pivot

I led the design of a brand new legal project management solution that enabled confident communication between legal teams, their clients, and third party contributors. This project became the new nucleus of both the product and the company’s business structure.

Context

I came to Atrium, a tech-enabled legal solution for startup founders, as designer #2 and later led design through a significant restructuring before a surprise dissolution (</3). At the time of this project, startup founders were attracted to Atrium because we marketed ourselves as “tech-enabled”, but we fell short of that in reality. The technical efficiencies that could make our legal team and clients happier and more productive weren’t making a critical impact for the business.

Roles

I led the design and research of this project from the discovery phase through the rest of its lifecycle. I collaborated closest with our head product manager. Our full team also included our engineering manager, a frontend engineer, and two additional engineers.

Key dates

Discovery research: Feb 2019
Prototype: March 19, 2019
First sprint: March 29, 2019
MVP (beta program): April 23, 2019
GA: August 21, 2019

Problem

  1. Unseen value proposition. Atrium’s competitive edge was not a visible, first-hand experience for our clients. Our existing technology was mostly hidden, disparate, pinpoint solutions for our internal legal team.
  2. Stunted company growth. Growing the headcount of the legal team was not sustainable, but the product wasn’t providing enough support or efficiency to increase client load.
  3. No core product vision. My product manager and I were tasked with figuring out the point of entry to make “tech enabled law firm” a reality. A platform was the obvious SaaS framework, but the foundation of the platform was not yet known.

Pre-discovery hypothesis

The hypothesis of the business at that time was that by leveraging tech, we’d create efficiencies for our legal team, enabling us to service more clients without growing headcount.

Legal work user flow

Discovery process

How might we build a platform to enable greater efficiency for our legal team?

Understanding the current state of legal work

I led the user research phase, personally conducting all internal research. The product manager helped with external interviews and synthesis. Contextual inquiries, interviews, and card sorting were the most successful methodologies.

The user flow diagram I created from this work was not just a foundational resource for this project, it became an asset for guiding product and process strategy in other areas of the business.

For Atrium's GC, project management = Post-its

Early insights

  • Inefficient and inconsistent workflows
  • Expectation setting avoidance
  • Emotion-based prioritization

The general consensus: Atrium attorneys and their teams lack the project management skill set to enable standardization and increased efficiency in legal service delivery.

Crazy Eights exercise with Atrium legal pods

Prototyping phase

How might we prevent dropped balls in the delivery of legal services?

Early questions/assumptions

  • How do we prescribe a universal legal workflow so that a standard exists to maximize efficiency and consistency?
  • How do we support a culture of “up-leveling” so that practice assistants, paralegals, and junior associates achieve more, faster?
  • Email isn’t going away. How does project management successfully fit in?

Prototype scope

Defining the persona of each stakeholder provided clarity on what to focus on for the MVP.

Prioritizing personas

  1. Define and stay within the core: Committed to focusing on the legal work itself, we only needed to focus on the needs of one of our internal personas.
  2. Some people won’t use it: Observed behavioral patterns made it clear that focusing on the core would not impact some personas. We were okay with people like lead attorney managers, sales, and client account managers not having features for their workflows.
  3. Transparency for users: As the catalyst of the project, clients experiencing the technology was a priority the prototype must address.
  4. Wait on uncertainties: Although very much a goal, the business was not yet aligned around our vision for integrating third-parties. The focus on our internal law firm was a testing ground to help guide that decision making.

Research, whiteboard, repeat

Formalizing goals: Project Jello

Now that the project was taking shape, I decided it was time to celebrate what we were to embark upon. To create buzz for what was to come, I branded the project as “Jello”. This internal name helped keep things fun as we got deep into turning an ubiquitous problem space (project management) into a specialized solution for legal. Jello’s goals were:

Collaboration 👥

Support our growing partnerships with third-party practitioners. We wanted to make sure that from mundane practice assistant tasks to outsourced special projects, our solution would serve the unique needs of each stakeholder to collaborate on legal work.

Efficiency ⚡

Standardize project work to level up paralegals and practice assistants, galvanize firm-level best practices and maximize personal efficiency. Our long term vision was for project standardization to evolve into a rules engine that could automate routine tasks.

World-class service 💎

We wanted to establish a client-centric approach. Our solution would make it easy to extend visibility to clients so that they could track everything and prevent dropped balls. “Team views” would help contextualize work, prioritize highest value clients, and improve ease of context switching. 

Success metrics

Firm-wide adoption

  • 100% daily active usage by paralegals and practice assistants
  • 100% weekly active usage by attorneys

How we built it

Quick iteration was the name of the game. Starting week 1, we shipped and tested in production. The development goal for the prototype phase was features and experimentation over quality and usability. 

To keep things lean, engineering decided to build the prototype outside of the existing product using basic Bootstrap. This made it simpler and faster to translate designs to functionality.

Data structure exploration and early wires

Basic bootstrap for quick sprint cycles

Iterations of core flow

Beta testing

Beta feedback: Methodology

A big challenge throughout this project was training our users to work with product and design. The majority of Atrium’s legal team had never worked in a startup environment so aligning expectations was required.

Creating trust for a product in iterative development was especially challenging in the legal space. To break down barriers between our teams, we created a dedicated Slack channel for each product as an inviting and informal feedback channel. These channels were active and helped us evolve our processes around bug reporting, usability testing, and research to best resonate with our users.

Beta feedback: Methodology

  • The people love kanban. Introducing this common pattern to this use case provided at-a-glance consumption of project status and was a big win.
  • Core value resonates with paralegal and practice assistants. The goal of preventing dropped balls when drafting legal work was achieved.
  • Need to support manager persona. Little value for attorneys managing their pods. We had initially cut this out of scope, but lack of attorney engagement did have a negative impact on the engagement of our target use cases.
  • Lack of user roles/permissions creates confusion. There was a strict pod structure for legal teams in real life that was not reflected in the app. This caused a lack of clarity when more than one pod was working on projects for the same client.
  • Creates duplicate/manual work. Email is still where requests come in. It’s uncompelling for users to keep two systems of communication up to date at the same time.

MVP phase

How might we integrate Jello with existing tooling to create an end to end workflow ready for a GA launch?

Email plugin

Addressing issues from beta

Scope increased for two new features:

  1. Email plugin. Bridge the gap between triage and project work, minimize manual effort
  2. Notifications. Increase engagement for clients and a broader set of internal users

GA launch

There were a couple final projects that made our formal launch a success.

Existing site UI

Existing site map

Redesigned IA

IA shift for a new platform core

Jello was now the foundation of the platform, so dropping it into the old app was not an option. GA would be the launch of the new Atrium Platform.

I did a separate project to update the information architecture of the product so that navigation usability improved. The resulting solution was amazing. When I showed users they were either overjoyed or let out a sigh, both signs that the intuitive upgrade was long overdue. 

Bootstrap iteration, map view

Translating bootstrap to app UI

I paired with engineers working on frontend products to ensure a smooth transition to visual consistency as we integrated Jello into the existing app. This was in the early stages of formalizing our component library, so there were lots of decision making to ensure strategic development that also set us up for future success.

Final app UI, kanban view

Reflections & Impact

  1. Quicker pivot to growth. The pieces of this project that focused on engagement and retention rather than feature development had a quicker, cheaper impact on sustainable, compounding grow. I believe if we made Jello a leaner feature set, we could have reached a stronger, more universally compelling experience sooner. We got there later, but it had heavier costs.
  2. EPD teamwork is fun! We came out of this project with a solid framework for how our EPD teams can function together. We increased the culture of collaboration, user-centered engagement, cross-role understanding and employee satisfaction.

Starting something new?
Let's chat

allison@earlyux.com
United States
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.