Head of Design
8/19 - 12/21
Led product team responsible for the design of Web-based connected worker procedure (“checklist”) authoring platform and mobile job completion application suite.
Rearchitected entire platform to align features with client roles and use cases. This substantially increased usability and client satisfaction.
Grew team from two to seven. Hired five UX designers in one year, including experts on accessibility, design systems, and healthcare procedure management.
Fully-integrated UX design milestones into development Agile/JIRA processes and roadmap.
Designed and wrote $60 million funding round presentation materials.
The Parsable connected work platform allows facility managers to write detailed checklist procedures which are then completed by workers. A typical client checklist was five to ten pages long and contained 50-100 steps.
When I joined, Parsable had a robust feature set but clients were very, very confused about how to use the platform.
Inconsistent, confusing terminology
One problem was terminology—Parsable used words in ways no other tech company did. For example, across the tech world, the term “template” represents an object from which identical instances are created, leaving the original template object unchanged. However, at Parsable, a template was a set of instructions added to a larger job. Simply changing the name of the feature from “template” to “steps set” (i.e. a set of steps a worker needs to follow) reduced confusion tremendously.
Inconsistent, confusing IA
Parsable clients were simply hoping to replace a time-worn, but simple process:
Which could be grouped into three primary use case areas:
People: Within a client organization, “People” includes not only the workers who execute jobs but also managers who assign jobs and the subject matter experts (SMEs) who author the procedural checklists. Parsable had scheduling, authoring, and execution functions scattered throughout the product.
Author: SMEs write, review, approve, and update standard checklists (i.e. “Author”). The approval phase is critical as there may be regulatory standards which have to be met. Parsable had good authoring tools but no review and approval process.
Execute: Job completion is only one state that needs to be tracked, hence the broader term, “Execute”. Jobs could be assigned or unassigned, not started, underway, completed, and re-opened. Parsable had no single, top-down view into the states of all jobs.
I began by documenting and categorizing every function and field in the existing product.
VIEW FULL ANALYSIS▸
I further simplified the product structure into three primary feature areas—People management, Authoring, and Job Execution that better aligned with clients’ prior checklist process.
VIEW FULL PROPOSAL▸
Final navigation
The resulting product organization was much easier for clients to use. Features could be shown or hidden based on users’ specific roles.
