Project Details
Team
I was the sole designer and led design for the entire lifecycle of the product.
Worked with 5 engineers, 1 product manager, and 1 project manager.
Process
2-week sprints
Daily standups
Agile work environment
Timeline
Shipped MVP in 4 months
Rolled out over 15+ feature enhancements after launch
Background
The development process of a product begins with the business requirements but as a company grows, so does the pains of misalignment and miscommunication. The task is to solve for this gap in the process.
User Research
By interviewing 8-10 various business and engineer users for 30mins each, I was able to gather some common insights. Some of the takeaways include:
No single source of truth for project requirements
Too little visibility, too much latency
Lacking formal review and approval process
Hard to track the conversation against the user stories as business and devs use different tools to write and track requirements.
Business and technical constraints
Although I practice mobile first design, this product will strictly be used on desktop due to required VPN enabled and the complexity of the platform.
The biggest challenge was that business needed flexibility to work in an iterative environment as engineers needed stricter handoff of requirements that doesn’t change so easily so there’s alignment throughout the production process.
Existing Problem
All the different methods that teams use to handoff and attempt to track these requirements, all suffer from lack of traceability during and after the completion of projects. This negatively impacts the quality and efficiency to iterate or fix development bugs.
Defining what we need to solve this
By creating a tool that enforces business and developers to easily create, track, converse, and report on project requirements, the development process will be a more efficient and less prone to miscommunication. 4 main functions that we believed would solve this are:
A place a user can create and edit requirements
A place a user can make iterations of the document - Version Control
Rope developers earlier in the requirement creation process to align functionality and limitations
A conversation functionality to encourage a central place to communicate between teams on the creation of requirements
User Story 1: Requirement Creation
As a business owner, I want to create and edit requirements easily so that I can communicate and report them with stakeholders.
Below is a user flow that allows the business user to achieve their goal of creating requirements from the start of the product experience.
Wireframe Sketches of My Documents and Requirement Editor Screenshots
Creating a new Document
Click-through Prototype
Creating a Requirement
Click-through Prototype
3 panel independent scrolling
Card components for grouping requirements
Easy side navigation that scroll anchors the card in focus.
Dynamic right panel meta data and action items per in-focus requirement
Challenges and Discoveries
I truncated each requirement card so make it easier for users to scan through the document, but little did I know that users actually found it a lot easier to see everything at once even though the document would get lengthy. This is because users are used to editing apps such as Word, Quip, or Pages. Click once to edit makes editing any part of the document quick and accessible.
User Story 2: Version Control and Approvals
As a business owner, I want to easily iterate on a requirements document so that I can make necessary changes before handing off for development.
As a developer owner, I want to track all the requirement changes so that I can make sure products are built with the upmost quality and efficiency.
Solidifying requirements with collaboration
By giving business the freedom to iterate on the document and an approval process to enforce sign off before development begins.
Detailed outline of working and published versions
Preview and exporting to various files
Clear approval status of the published version and each approver
Details of required dates and authors
Challenges and Discoveries
The approval process was a tricky feature to design for, as there are many moving parts associated with the interactions from both sides of the process, the requester and approver. I initially combined both the version control with the approvals to try and make the task use less interactions, however this diminished the experience by not allowing users to create multiple version and export versions without an approval process.
User Story 3: Action Items
As a business owner or developer, I want to reduce latency by effective communication so that I can deliver with the least amount of time possible saving resources and stress.
Number alert for quick glance unresolved action items
Action item filtering of assigner or published version
Quick preview and click to target
Single level reply for organized conversations
Clear labels and icons to differentiate resolved and unresolved items
Challenges and Discoveries
Initially I had resolving action items an independent call to action but from talking to the business, it is important to have users write a short explanation to how they are resolving the action item. This helps avoid ambiguity especially when collaboration plays a major role in this application to solve the problem of misalignment.
Building out Acceptance Criteria
For a complex product like this, I outlined the acceptance criteria for each requirement and user story.
An acceptance criteria is conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.
I used Gherkin’s syntax to write expressive scenarios in my acceptance criteria for each user story. If you’re not familiar, a good read that explains this is The Cucumber Book: Behaviour-Driven Development for Testers and Developers. Here are some of the scenarios I wrote using Cucumber:
Mapping the experience
4 main pillars that make up the application:
1. Activity - Document details, versioning, and action items.
2. Summary - Supporting documents to the requirements
3. Requirements - Creation of themes, requirements, and user stories
4. Read - A flat readable view useful for approving document versions
What did success look like for MVP launch?
Adoption
Teams throughout the company started requesting to use the application
Gave over 50+ demos to various teams and stakeholders
Created over 10+ reusable keynote slides
Numerous requests to use the product throughout the company
On-boarded over 1,000+ employees to MVP, actively using and growing
Efficiency
Teams reported saving sprint cycles due to the application, which is hundreds of hours per sprint
More bugs were fixed in less time due to stronger communication and alignment on requirements
Feature Enhancements
Secondary features are needed to support the core features of the application to make the functionality of core features more robust and behave to solve for all issues surrounding core problems. Below is a flow diagram of the different notification types and their target pages.
Notifications
Notifications allow users to be informed about activity in the document that’s relevant to them in real time. This is key when a project is time sensitive and stakeholders are waiting on an action that needs to be taken by the assignee.
Below shows what instances are notified through both the client and email, and how easy it is switching between document and all notifications (global) in the same component.
Assigning Action Items
Assigning people to an action item allows for direct notifications, helping grab attention from a specific contributor. This will help reduce latency and focuses the users attention on whats required on their behalf.
Below you can see the user flow of a creator of an action item that wants to assign another contributor to the action item:
Landing Page
Explorations
I explored several iterations of the landing page with the same feature benefits, floating image and call to action - All above the fold (600-700px).
Goals
High conversion rate
Get users to create their first document
Give enough value proposition with core feature benefits to motivate users to create their first document.
Single Call to Action, making it stupid simple to get started.