The Challenge

tldr: design an experience that enabled users to create, collaborate on, resolve unplanned issues

Parsable's mission is to create a platform for industrial teams to digitize their work processes, easily collaborate, and enable new data to be captured for analysis—all in the service of getting “Jobs done right, every time”. That means being able to get work done under all kinds of conditions. From managers on the go, to line operators, to remote inspectors in harsh environments, we had a lot of factors to keep in mind.

The initial tool was built to help plan and precisely execute standard job instructions. What it didn’t account for, however, was one of the most common use cases of all— what happens when something goes wrong. While each customer had a different name for it, the need to create, collaborate on, and track unexpected issues in the field was one every customer experienced. Many of them had processes in place to handle this, but the creation and management of these events was clunky and disjointed, not to mention time-consuming. Lastly, issues were typically in completely disparate systems that were nearly impossible to track, making any analysis for improvement a major hurdle.

User Research

tldr: we went to a customer to dig deeper into their needs

I, along with the product team, account managers and our sales rep visited a customer site to uncover the core of the problem(s) they were having around issues and collaboration. 

During this 3-day visit, I had the opportunity to:

• Observe the use of the product on the shop floor

• Discuss business needs directly with coordinators of each dept.

• Interview floor operators and shop floor managers (2 of our product's main end-users)

• Observe group training sessions for operators

Our product team now had a wealth of information to analyze upon our return. Keeping in mind that each customer had somewhat unique use cases, we sought to combine this new data with that from various account reps to validate the most common needs before diving into solutions. After synthesizing as many patterns as we could across customers, we were able to draw out the following user stories:

• As an operator, I need to be able to create an issue at any point within a job’s execution

• As an operator, I need to create a completely standalone issue (unrelated to a job being executed)

• As an operator, I need to categorize each issue with a level of priority

• As an operator, I need to be able to collaborate with other team members to resolve an issue

• As a manager, I need to be able to see/filter all issues created

• As a coordinator, I need to have visibility into issue creation, management and resolution

Solution Exploration

tldr: rapidly iterated on ideas far and wide in order to zero in on an mvp solution

I worked with a PM (cred: Nick Russell) to generate various flow options as we explored a wide range of potential solutions. I created hand-sketches/whiteboard flows to drill down on the general concepts that we liked (and didn’t like). A plethora of group brainstorming sessions, independent exploration and research on how each system handled these problems led us to a few options that we felt good about.

When we were able to get a few ideas solid enough for broader discussion, I presented lo-fi wireframe flows to the product and feature teams for initial feedback. As we narrowed down options and weighed pros/cons of each, we gleaned a few key insights and limitations. We measured each option by assessing the core customer needs, technical challenges, design trade-offs and the customer-committed timeline we were working under.

tldr: I created hi-fidelity mockups and prototypes using Sketch and Invision

In order to maintain usage patterns that were deeply engrained in the application, some of the solutions we explored were simply out of scope for the R1 MVP. Many of these options were catalogued and stored for potential future design use in the product (possibly in R2, or as completely separate projects).

Through much deliberation, we decided on an MVP solution that would enable us to leverage an existing usage pattern in order to be more agile and lower the risk of creating more/adding to our existing engineering debt. 

I put together hi-fidelity mocks and created a prototype in Invision for the team to review. Once approved, I moved on to validating it with customers.

After receiving some feedback around the experience and iterating on parts of the design— development and QA began. Because this feature could be accessed in various screens throughout the app, there was no shortage of complex edge cases, requiring consistent triaging during the building and testing phases. Once each platform had reached a certain milestone, I performed rounds of testing to verify mobile parity and visual accuracy.

We then went back to our initial customers (most notably the one we visited) and presented the new feature. We noted and prioritized important usability feedback, and set realistic expectations for the MVP to come. Lastly, I worked with our Customer Support team to write the release notes and answer important usability questions as they surfaced.

The Results

Since it’s release in June, 2017 there have been more than 2,800 issues created, 800+ issues resolved and over 10,000 messages sent managing them.  

During the development and testing phases, we listed and prioritized the improvements we already knew would be helpful, but could not properly execute until other experiences in our product had improved or without extending our timeline. Namely, the most important aspects of our R2 were: 

• Reduce the amount of taps/clicks in order to create an issue (too much overhead) 

• Enable issue creation to trigger events in other applications (eg. ERP systems) 

• Create more specific permissions around issue management and visibility 

• Enable authors and executors to collaborate on work being done in the field

Throughout the process I developed a major appreciation of the complex challenges our customers face every day. I also learned how to better extract information from customers out in the field and through group interviews (through a language barrier no less). The experience emphasized the importance of a solid product strategy and balance required to build and maintain the relationship between customer needs, overall product quality and business value.

Ultimately, the release of the Issue Collaboration feature took a major step in differentiating us from our competitors (most of which had no solution for these use cases) and allowing our customers to centralize an important component into our system that was previously unaddressed in the product.