⮐ Back to Case Studies

The start is what stops most people

Client

Overview

Create a project onboarding workflow that captures the requisite date to stand up a project, and allows for more successful completions of project setup completion

Impact

Users were able to spin up a project in seconds and move on to inviting collaborators to enrich the project data asynchronously. It was nearly impossible to destroy progress during the setup process when we re architected the requirement to a single unique input.

Step 1: Define the problem
The new project setup workflow was initially set up to gather all of the important details necessary to get a project moving. What we soon found out thru observation was that this process included steps that might be handled by several individuals in an organization. We also came across a usability bug that would dump all of your progress thru the creation process if you clicked the back button on your browser, or your session expired. Both common occurrences given the nature of the process.

Existing multi step project creation process. Included creating project teams and setting policy for permissions, payments, and certifications. It was created with the assumption that all required information would be available at the time of interaction.

Step 2: Form a hypothesisWith this in mind we started to collect assumptions about what project creation needed to accomplish to be successful. We formed the following assumptions to test.

  • The new project creation tool was too complex. If we simplify the process, more users will be successful in creating projects, and inviting others to it.
  • It did not afford multiple participants in its creation. If we allow multiple users to contribute to the project, users with specific information can enter it, this will increase data enrichment, and integrity.
  • It needed to be more protective of data entered. If we don't destroy incomplete work, it is more likely that users will complete the workflow.

Step 3: Test
Based on the hypotheses from our internal review and feedback from our users, we built out some simple prototypes to validate (or invalidate) our assumptions.

What if we simplified project setup?

A simplified approach to project setup only requires that you stand up the project container with some basic parameters.

This simple form allows a user to stand up a project with minimal input

What if we oversimplified it?

We soon discovered, we only needed to stand up a project instance that we could invite people to. With that in mind, we really only needed a project name.

‍

Lessons Learned

This project reminds me of Jared Spools $300 million dollar button example. Our products initial research participants were single user project managers. As soon as we started to expand to larger organizations, our model fell apart. We had created a process that made perfect sense from an engineering perspective, but lacked insight and affordance to the needs of our users in the context of their day to day jobs.

The fix was simple...once we understood what the problems were. This process reinforced the need to visit with our users to determine not just what jobs need to be done, but who will be doing them and the constraints they are working with. There is no substitute for observing the user in their environment or better yet, using the software under similar conditions to do their job.

‍