Propeller R&D (2020)

---

Responsibilities

• UX/UI design
• Design library asset creation management
• Component library documentation
• Qualitative user testing and analysis
• Quantitative user testing and analysis
• User story writing
• Ceremony conductor
• Roadmap planning
• Hard question asker

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.

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 / 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.

Design / 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
2. Customer admin web app
3. Customer mobile app

Internal admin web app

This app’s target audience are comprised of Project Propeller’s customer success managers and customer support representatives. Within this app, tenants could be manually provisioned/de-provisioned, users created, and account metrics monitored.

Customer admin web app

The customer’s web app is where Oliver, Betsy, and Abby would primarily work to manage data, build workflows, and analyze the output from the workflows.

Customer mobile app

The customer’s mobile app is where Danny the Doer primarily completes tasks for the workflows that are assigned to him.

From a design perspective, I started to design key workflows for:

• Sign up flows for a freemium model
• Authentication flows for both web and mobile
• Key workflow building journeys (happy paths and error paths)
• Data importing and CRUD operation
• User provisioning and de-provisioning
• User role and permission assignments

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.

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. As a result of this acquisition, Project Propeller was terminated and shelved.

Bummer, right?