Overview
Role & Resposibility
I’m the sole designer in this project.
I am involved in the project from end to end.
Scope & Constraints
Small Dev team, 1 developer, and a manager.
2 months to deliver this project in a remote setting.
Problem
The operation team in my company was using third-party software to manage their daily tasks.
However, most of their day-to-day work is done in Docpark Go - a bespoke internal software, so they had to jump between browser windows multiple times a day.
This project aimed to streamline operational experience around creating, accepting, and managing tasks, by introducing a task manager directly in Docpark Go.
Research
Gathering Requirements
I conducted 1-to-1 interviews with end-users.
One of the key findings:
Users wanted a quick and easy way to assign, track or complete a task while they were working on the task itself in Docpark Go.
Gathering Inspirations
I researched into similar software for inspiration, and found a quick action panel from a bootstrap template that could potentially address my problem.
Prototype & Iteration
I invited end-users to validate some low-fi wireflow.
I always pay special attention on questions asked by users, these questions often hold insights on what users are looking for in the system.
After the concept was accepted, I then used HTML and CSS to create high-fi prototypes.
Below you can see the resulting Quick Action Panel: this design allows user to create, compelete and manage a task while they are working on the task itself.
Implementation
After the high-fi mockup was done and signed off, I then walked the Dev team through the design.
Below are the user stories I created for Dev so they could have a clear understanding on what to build.
Post-Implementation
Testing and Release
I had a final walkthrough with the QA team and the developer to make sure things were all correct.
I was also in charge of writing the release notes, which are normally in the form of a video to showcase new features.
Feedback and Follow-Ups
I created a release group chat for feedbacks and questions.
Learning
Writing user stories is a great way to communicate, not only with developers.
In my past projects, I used to present user needs to stakeholders by talking through the mockups I made.
Often this kind of meetings require a lot of mental effort and space for imagination.
Instead, writing down user stories at the very beginning of the design process benefits all parties involved:
End-user
They can validate my understanding of their problem not only visually but also by clear statements.
Project Manager
They can use these stories to estimate a more accurate project deadline.
Developer
They have more time to focus on programming and have a clearer vision of what they are developing.