Propeller: Workflow Automation (B2B & B2C)

Propeller, the next-gen application of GoSpotCheck, is a workflow process automation B2B application that an enables fast, efficient execution of work driven and informed by data.
Company
GoSpotCheck: Founded 2011, B2C & B2B Enterprise
Time Frame
2018 - 2021
Role
Individual Contributor
Environment
Web, iOS, Android
Responsibilities
Design lead (UX/UI), Product Management, UX Writing, UX Research, Information Architecture

Background

GoSpotCheck (now part of FORM MarketX) helps businesses replace manual data collection like spreadsheets and pen-and-paper processes. It’s designed for mobile-first field workers who use the app to complete tasks like surveys and audits, while managers create and distribute workflows via the web app. Project Propeller aimed to make these workflows dynamic, driven by real-time data, ensuring that tasks change based on factors like location, time, and business needs.
Image of the propeller web app workflow builder on a laptop and the consumer iOS app on an Apple iPhone

Outcomes

After almost 18 months of developing and designing Propeller, GoSpotCheck was acquired and merged with Form.com. At the termination of the project we had functioning applications for the internal admin app, customer admin web app, and the customer mobile apps. The fully functioning workflow builder with an infinite artboard was built using ReactFlow and the Propeller design system. However, as a result of this acquisition, Propeller was terminated and was never released to the masses.

Personal Achievements

  • Shaped the platform's design and strategy, directly impacting the customer journey.
  • Defined customer needs and product strategy by analyzing 4,000+ NPS comments, Aha! submissions, and stakeholder interviews.
  • Conducted 125+ quantitative and qualitative research sessions (moderated and unmoderated) to make data-driven, iterative improvements.
  • Collaborated with engineering to create and maintain a design kit and component library.
Branding art of old school astronaut helmet with AI stars

Primary Goals

  1. Increase total addressable market by serving more/complex use cases
  2. Support data-driven workflows to dynamically change the tasks one must complete
  3. Allow captured data to inform the workflow to trigger other tasks to be done
  4. Create flexible, powerful, real-time reporting tools

Designing for Personas

Headshots and accompanying information of the three main personas of the Propeller app; Danny the Doer, Abby the Analyzer, and Betsy the Builder. Not shown is Oliver the Organizer.

Discovery and Planning

For the first month on the project, I gathered all of the existing research, Aha! submissions, and NPS feedback we had on relevant feature sets we knew could help our target audience. In addition to gathering and analyzing this data, I conducted ~20 internal stakeholder interviews with:
  • Customer success managers
  • Product managers
  • Designers
  • Customer support representatives
  • Sales engineers
  • Engineers
  • Executives
After analyzing the research, interview notes, and data I defined all of the common themes within each of the key feature sets, which helped me create a backlog in each given area. This helped frame the conversations for roadmap development with the team and internal stakeholders for the team’s areas of focus.
Screenshot of Google Spreadsheet prioritizing user needs by category and release.
As both product designer and product manager for the first 7 months on the project, I prioritized user stories by category and whether it was needed for our customer conference, Alpha or Beta (MVP).
I analyzed 5 years worth of customer Aha! ideas.

Diagramming Freemium User Paths

After identifying focus areas, we started to design customer journey maps and user flow diagrams. This helped us start to define potential information architecture options as well as the platform architecture definition.

Diagramming Mock Workflows

As we started to define specific functionality in areas of the platform, I often did exercises with myself to make sure we were meeting customers needs. To do this I mapped out given data schemas and drew out how I would build a workflow with the given data to solve a use case.

Designing and Testing

The information architecture started to organically flesh itself out as we defined user flows and customer journey maps for various use cases. We also knew we would need to be designing for our customer as well as our internal teams to manage the tenants of the platform. The platform architecture ended up being comprised of three applications:
  1. Internal admin web app - Usage analytics, tenant management, feature flag management (CSMs, Account Managers)
  2. Customer admin web app - Data ingestion, data model building, workflow management, business insights (Oliver, Betsy, Abby)
  3. Customer mobile app - Field ops workflow execution (Danny the Doer)

Designing Key Workflows

From a user experience perspective, I started to design key workflows for:
  • Sign up flows for a freemium model
  • Customer admin web app - Data ingestion, data model building, workflow management, business insights (Oliver, Betsy, Abby)
  • Authentication flows for both web and mobile
  • Data importing and CRUD operation
  • User provisioning and de-provisioning
  • User role and permission assignments

Designing an Infinite Artboard User Interface

The area of the platform that garnered the most attention was the actual workflow builder itself. This was the area of the platform that we identified as high risk. At this point in the initiative, we had made the decision to develop the workflow builder with a low-code/no-code user interface. We came to this decision to maximize our total addressable market for Betsys that are both non-technical or very technical. Because of this it introduced lots of challenges that created risk for development, design, and adoption of the product.

From a product design perspective this presented many navigation and usability challenges. Within the user interface, this manifested in a builder experience that would allow the user to switch between “visual” (no code) and “advanced” (low code) mode. Because a user is able to switch between these modes at-will meant both interfaces would need to mirror the progress made in each mode in real time.

Designing for the Consumer

GoSpotCheck's end users (Danny the Doer) are used to interacting with our mobile apps respectively built for their native operating systems, iOS and Android. With speed to market in mind, we developed Propeller's consumer apps with React Native providing flexibility and efficiency in development, while being able to provide native patterns for each operating system.

The consumer mobile app needed to allow for:
  • Review their goals and metrics, which are set by their manager.
  • Find and initiate workflows (AKA Missions) via list or map.
  • See other Doers around them in case help is needed.
  • Perform all task types within a mission with native functionality (capture photos, video, input data, etc.
(
Next
)