Nick Conflitti: Propeller Applications Case Study

Background

GoSpotCheck’s (now FORM MarketX) platform is positioned to help any business who traditionally collects information through spreadsheets and pen and paper. More notably, the product was targeted at users who primarily use mobile devices to complete their work out in the field. Field workers utilize GoSpotCheck’s mobile app to complete surveys, audits, and simple project tracking in the form of what we call, workflows. The managers of said field workers utilize GoSpotCheck’s web app to build the workflows and distribute them to their mobile workforce.

In doing this, field workers (known as “Doers”) complete simple forms that are built by their managers (known as “Builders”). These forms are often comprised of simple form elements like multiple choice questions, write-ins, Yes/No, and photo capture tasks but are not data-driven.

Project Propeller set out to make workflows data-driven. Some of the biggest complaints we heard from clients and prospects were that the workflows should be informed by the changing nature of their business (i.e. data). A workflow that Danny the Doer completes at location A, is probably not the same workflow that Debra the Doer completes at location A. The same can be said for different locations, or times of day, or other criteria that might be met based on any number of circumstances.

GOALS
• Increase total addressable market by serving more/complex use cases
• Massively scale and streamline our data pipeline
• Improve architecture and implement a design system to allow for faster feature development
• Support robust conditional logic for workflows
• Support data-driven workflows to dynamically change the tasks one must complete
• Allow captured data to inform the workflow to trigger other tasks to be done
• Allow customers to have a flexible data model
• Create flexible, powerful, real-time reporting tools
• Create more integrations with external service providers

To accomplish this we created an ETL-less platform of micro services that could accommodate any data schema and allow customers to create dynamic workflows that generated the reports they wanted.

PERSONAS
In planning and designing for this platform, we utilized a jobs-to-be-done framework to define our personas that would help us focus on what’s most important:

OLIVER THE ORGANIZER
Oliver could be a data ops engineer or a savvy IT admin, but is always the person whose job it is to organize, update, and maintain the data integrity that informs his company’s workflows.

*Not pictured. They missed yearbook picture day.

BETSY THE BUILDER
Betsy is the person who is intimately familiar with the jobs that need to get done in order to make the business run more efficiently. She is the one who actually builds the workflows and determines when, how often, and who can complete the workflows.

ABBY THE ANALYZER
Abby is the person who analyzes the output from completed workflows in order to provide actionable insights to the company so that they can continuously improve their operations.

DANNY THE DOER
Danny is the person(s) who is completing tasks within the workflow, which might include data entry, capturing a photo, or answering some questions about a task they just completed.

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.

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.

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:

Internal admin web app - Usage analytics, tenant management, feature flag management (CSMs, Account Managers)
Customer admin web app - Data ingestion, data model building, workflow management, business insights (Oliver, Betsy, Abby)
Customer mobile app - Field ops workflow execution (Danny the Doer)

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.

Usability Studies

Because of the high amount of risk in this particular area, I ran numerous qualitative and quantitative research sessions. These sessions ranged in purpose including; testing ease of use, navigation taxonomy, overall aesthetics, and task success completion. Roughly 25 qualitative sessions and 200+ quantitative studies were conducted to analyze the effectiveness of the designs. Here is an example of a quantitative study analysis completed by me to present my findings on an area of the workflow builder.

Outcomes

After almost 18 months of developing and designing Project Propeller, GoSpotCheck was acquired and merged with Form.com. At the termination of the project we had functioning applications for the Internal admin web app, Customer admin web app, Customer mobile app. I was very impressed with the workflow builder app that we developed utilizing ReactFlow.

However, as a result of this acquisition, Project Propeller was terminated and was never released to the masses.

Propeller B2B & B2C Apps