This case study focuses on redesigning project-planning interactions in SPIDER, addressing usability challenges in complex workflows, while working within the constraints of an established enterprise system and agile delivery process.

This case study focuses on redesigning project-planning interactions in SPIDER, addressing usability challenges in complex workflows, while working within the constraints of an established enterprise system and agile delivery process.

This case study focuses on redesigning project-planning interactions in SPIDER, addressing usability challenges in complex workflows, while working within the constraints of an established enterprise system and agile delivery process.

client

Atlas Copco

year

'25

timeframe

6 Months

team

Designers (2), Product Owner, Scrum Master, Module Owners, Developers, Testers.

UX Design

Enterprise

Redesign

Context & Role

Context & Role

Context & Role

SPIDER is an internal platform at GECIA (the innovation center of Atlas Copco) that enables end-to-end project delivery by connecting planning, execution, and supporting operational workflows within a single system.

I contributed to the redesign of multiple modules within the platform, including configuration management and customer feedback.

This case study focuses on three selected problems within the Project Management module, where I researched planning workflows with stakeholders and designed solutions to improve how planners and project leaders structure and manage complex projects.

Design Approach

Design Approach

Design Approach

The redesign began by understanding Spider and how project planning was done in practice, and the role of Planners and Project leaders.

Task-based interviews were conducted among these user groups, observing them as they planned real projects to capture both stated challenges and behavioral patterns.

Insights from interviews and workflow analysis were synthesized into key problem areas, which were reviewed with stakeholders before exploring and refining design directions.

Problem

Problem

Problem

Project planners had to move through multiple steps to update project details. The experience exposed too much information upfront and relied on frequent confirmation pop-ups, interrupting planning flow and increasing cognitive load.

Solution

Solution

Solution

We consolidated the multi-step flow into a single, scrollable page with sidebar giving status feedback, restructuring information hierarchy and removing low-value confirmations. Secondary details are revealed only when needed.

By reducing navigation and interruptions, planners could move through project detailing more fluidly and complete routine updates more efficiently.

Problem

Problem

Problem

Milestones were restricted to a predefined set of phases, requiring planners to select from fixed milestone options without the ability to add or modify them. While this structure supported high-level KPI tracking, it failed to accommodate projects of varying scale and complexity. As a result, planners resorted to workarounds, such as nesting milestones within milestones or creating separate projects, to reflect real planning needs.

Solution

Solution

Solution

After multiple explorations and discussions with stakeholders, rather than removing the existing phase structure, we focused on introducing controlled flexibility within it. Milestones could be cloned and customized within the same phases, allowing planners to edit names by adding suffixes while still aligning with predefined tracking requirements.

This approach balanced planning flexibility with organizational reporting needs, reducing the need for workarounds while preserving consistency for KPI tracking.

Problem

Problem

Problem

Activity-level effort planning required users to manually balance hours between activities and individual members in it. Originally planned activity hours were not visible once changes were made, forcing users to rely on memory, an issue that became pronounced in projects with a large number of activities. Additionally, users could not proceed to the next step unless total activity hours exactly matched the sum of member hours.

Solution

Solution

Solution

We designed the effort-planning logic as per our observations (top-down/bottom-up approaches) to keep intent and execution in sync, and previously planned activity hours were always displayed as a reference.

Hours entered at the activity level were automatically distributed across members, and changes at the member level dynamically updated total activity hours, eliminating the need for manual balancing and preventing unnecessary blocking errors.

The revised experience reduced cognitive load, removed planning blockers, and allowed users to progress smoothly through activity-heavy project plans without losing context.

Constraints

Constraints

Constraints

• Due to the agile delivery setup and 2-week sprint timelines, design iterations were often validated through stakeholder and product owner reviews rather than extended user testing.

• Many decisions required balancing usability improvements with existing system logic, reporting requirements, and downstream dependencies, resulting in incremental rather than disruptive changes.

Learnings

Learnings

Learnings

• The redesign improved clarity, flexibility, and efficiency across key project-planning scenarios, particularly for complex and activity-heavy projects.

• This work strengthened my ability to design within enterprise constraints, translate user pain points into system-level improvements, and make informed trade-offs while collaborating closely with stakeholders.

Create a free website with Framer, the website builder loved by startups, designers and agencies.