Workflows

One place for engineering teams to write specs, assign work, request reviews, and track projects.

Role

Product Designer

Duration

8 months

Team

CTO, 3 Product Managers, VP of Sales

The scalability problem.

As our team at Educative scaled from 50 people to more than 600, a centralized repository for projects, communication, and documentation became necessary. The existing tools solved separate parts of the problem, requiring a lot of context switching and maintenance.

To solve this for multiple personas across the company, we set out to build Workflows.

The Manager + IC Hybrid.

By this point, I had been at Educative for over two years. It was an ambitious product that our leadership was heavily focused on, and I worked directly with sales, engineering, and product leadership on the end-to-end process.

I was also involved in hiring and developing an outcome-focused team of designers and illustrators.

Talking to the demographic.

I spoke to 31 people, including 18 Engineering Managers and 13 Software Engineers, sourced through my LinkedIn network.

This was still exploratory, so I focused on how they used existing work-management tools, what they liked, what they did not, and where gaps existed. We found competitors across two main areas: documentation and project management.

  • “I can never figure out project progress.”Engineering Managers did not want to spend their time searching for documents or projects. One interviewee described Jira as so open that anyone could create anything anywhere, and it became bloated over time.
  • “I don’t want to use two different tools to manage my work.”Twenty-four of the 31 people I spoke to used Jira and Confluence as a pair. At Educative, PMs split work between Monday and Slite, then manually linked records and updated both statuses.
  • “Signoffs become blockers and I have to remind people via Slack.”Even when people wrote things down, they did not always reopen their notes. Product Managers ended up reminding colleagues in Slack, causing avoidable delays.
  • “Discussions on technical docs are difficult to resolve.”Implementation discussions could stay in limbo and prevent approval. Some PMs pushed documents through without signoff because technical reviews took too long.

I built a functional wireframe over a weekend.

After synthesizing the findings and settling on the MVP features, I took a weekend to prototype a fully functional low-fidelity wireframe containing the core experience.

It covered three touchpoints: Projects Home, Project Details, and the Document page. The first round of feedback showed that people needed clearer cues for where their attention was required, which tasks were due, and what they still needed to resolve.

  • Task ManagerI built a complete end-to-end task manager from scratch. Tasks were associated with projects and documents and could be assigned to anyone.
  • Review ManagerPeople could request reviews on their documents and track the process from request to resolution.
  • Project ManagerProjects grouped tasks and documents with due dates and collaborators.
  • Document EditorThis was the page where users spent most of their time. Tasks and reviews were part of the document, with states ranging from Not Started to Done.

The work helped land a $100K deal.

Sales used a prototype built from these designs during the enterprise pitch.