Project Management and Planning Tool
Internal Enterprise Tool
Company: Confidential (a multinational organization's tech group)
Before 2019, a tech group within a large organization needed help planning and analyzing every tech project in the pipeline. They decommissioned a tool that didn't work and decided to revamp it. I was part of the preliminary launch of the project.
[ I have omitted mention of names, identities, designs, and other discernable information for confidentiality. The visuals or designs shown here are reinterpreted and, as such, are not the final work.]
My Role & Timeline
As a sole designer, I led the end-to-end design process from research through launch.
Team
Product Owner
Sr. Business Analyst
2 Engineer Leads
2 Agile development teams of 6-8 engineers
6 Leads from cross-functional up/downstream products
Duration
six-month project
PROJECT SUMMARY
Tool's data inaccuracies led to ineffective reports, which was the central pain point
The awareness of problems arose when the business executives noticed project data was either missing or incorrect. This point led to a general belief that the teams inputting the project information should care more about the quality of their work.
Originally designed as a source record and for reporting
The decommissioned tool collected and stored all tech project information in the pipeline. A manager or a designated team member manually collected and entered the required information. The project data flowed down to a reporting tool, enabling executives to review and make informed decisions to prioritize and deliver products that affect their customers.
Redesign a new tool to reduce inaccurate data targeting launch within six months
The business goal was to build a new tool to generate accurate data for business efficiency. With an initial budget of six months to deliver a preliminary launch of a revamped tool, each business had time to decide whether to find a new vendor tool or become involved in further enhancing a revamped one.
RESEARCH
Defining the problem space
We needed a clear roadmap of what we needed to build in the next few months. With the help of the product owner, I planned three separate research activities to gather insights about the business process and past experiences of the decommissioned tool:
2-day stakeholder interview, mainly for their insight into the previous tool's inaccuracy of data input.
Image: Based on stakeholder interviews, the system diagram shows roles/persona utilization spread within the tool environment and different data viewpoints from their perspectives.
Constructing viewpoints
Ten interviews with people in the field for viewpoints on the work process and how they used the previous tool to get the work done.
2-day manager group session walk-throughs for context to the business process.
Image: Workflow diagram of a business process produced during one of the workshops with the managers.
Learnings from the field:
Working with what's familiar
From interview responses, it was evident that teams began using spreadsheets instead of inputting information into the tool. Since there were no mandates, users could easily take this route; working with spreadsheets is common practice within the organization and more familiar than learning to use the tool.
We use Excel to input project information. There is no value in adding project information (to the retiring tool). We only use it to create a record since it's tied to other data systems we use.
– Quote from a manager about the previous tool
Proliferation of spreadsheet use
Learning that some project information data exists on cross-functional tools made me realize why spreadsheets became popular—other tools had the functionality to export data as a spreadsheet. Rather than manually copying and pasting the data into the project management tool, most teams skipped the step.
Tying it into business pain point
Stakeholders mentioned that spreadsheets became problematic source references as the files are challenging to track, especially without version controls and the inability to track change history. Not all data are coming from other tools. They hoped to find ways to lessen users' bad habits, such as producing data outside the tool.
Learnings from the field:
Manual and time-consuming tasks
I learned that managers delegated work and uploaded it to the reporting platform. The pain point was in determining the status of each project. The status description and the definition varied from business to business. In addition, there was no standardized way to assess the status— it required work experience to analyze data points.
Learnings from the field:
Form labels
Users pointed out the confusing field labels when reviewing the retired tool's form fields. They either needed clarification about the vocabulary or the context; is it asking for the file name or the associated project name?
Learnings from the field:
Navigating through the unfamiliar
During the walk-throughs of the retired tool, users conveyed their frustrations with navigation or functionality. 2 out of 3 people only frequented their task areas from memory, afraid to explore different areas of the tool. When asked about their fear, most people stressed about messing up or unknowingly making errors through clicking.
Concluding from the research activities
Learnings from the interviews helped the team conclude that several usability issues may have led to some of the data inaccuracy. We focused on the identified problems from these findings.
EXPERIENCE DESIGN
Decreasing manual data input
Our team decided to streamline or connect the data between the cross-functional tools to decrease the likelihood of human error. In addition, management decided to instill mandates in the new tool to ensure only correct and quality data become part of the process.
Simplifying navigation
Learning to use a new tool can become overwhelming, especially if the interface looks more complex than it is. We simplified the menu options and directed users to the relevant context at the right time, which helped lessen the cognitive load.
Image: Navigation can either help or overwhelm. Simplicity can sometimes be less of a burden. Navigation from the previous tool at left and redesigned navigation on the right.
With contextual controls and the help of terminology definition, users can navigate unfamiliar language and leave less room for guessing.
Image: The ability to view data and edit on the same screen provides a familiar way to correct the data. Using a tooltip (on the right) to view term definitions clarifies and provides context.
Definition of project phases
With standardized rules and procedures defined, revealing only relevant tabs/fields and requirement indicators guide users through completing each phase. This feature was absent in the decommissioned tool, which had a high probability of incompletes.
Image: Errors and incomplete messages implemented to help users complete and advance to the project's next phase.
PROTOTYPE & TEST
Experimenting and testing an idea
We conceived and tested features to eliminate user friction and enhance the project data management. In particular, the team wanted to see a visual diagram for project groupings. Would users find it helpful?
Diagrams may be functional if the test participants immediately acknowledge or describe how they would incorporate them into their tasks. If no one realized or were confused, that would not be the best feature for the preliminary launch. From concept testing, the participants had many questions and needed clarification, so we took it out.
Image: Rough prototypes used for concept testing. The abstract diagram on the screen illustrates the project connections.
VALIDATE
Reviewing designs
Initially, a one-on-one usability test validated a particular story. However, due to time constraints, the product team replaced it with group sessions. The managerial participants were 25+, initially reviewing clickable prototypes as the wireframes were abstract. Once the participants were comfortable, the reviews moved along much faster with the wireframes, which also could be iterated much quicker.
DEVELOP
Building approved ideas
The map below shows how various user stories fit into the individual screens. Some UI standards or a basic system, such as a calendar and page control patterns, were set before the start of sprints. Maps, UI standards, and wireframe documents aided in communicating and performing quality checks at the end of each sprint.
Image: Flow diagram of users moving from the project list to project details with user story labels.
Image: Default screen listing projects or portfolios.
Image: Date input field with calendar functionality pattern defined.
Image: Table pagination and control functionality pattern defined.
CLOSING
Result
The team launched on time. About 75% of the business lines signed up for continued funding to refine and add additional features to the revamped tool. At least six stakeholders expressed positive enthusiasm about including the project status indicator with the initial launch.
Challenges and learnings
Focus on the most crucial problems when in a time crunch:
Constructing an application from scratch within six months only allowed four months for actual design work; it required close collaboration and support of cross-functional teams and stakeholders. Large groups making decisions were sometimes complex and needed creative reframing to guide decision-making.
Without existing analytics or quantitative insights about the previous tool, much of the problem-solving has been our hypothesis based on interviews, testing, and feedback.
