Task tools
They help structure work, but often separate execution from the conversation that explains why priorities changed.
Team Collaboration Product
Designing a more coherent collaborative workflow for small and medium-sized teams
Small teams rarely struggle because tools are missing. More often, information is spread across too many entry points. This project explores how a connected structure reduces switching and preserves context.
Product Designer
Desktop App Design
Team collaboration / Project management
Overview
As remote work and cross-location collaboration became more common, project management software became an increasingly important part of how teams stay coordinated. This project focused less on expanding feature coverage and more on reorganizing the relationship between project status, task progression, and communication, so small and medium-sized teams could work through a more continuous workflow with less switching and less coordination overhead.
Project Process
This project followed a structured but iterative process, moving from research and problem framing to solution development and evaluation. The goal was to understand where collaboration was breaking down, translate those findings into a clearer product structure, and refine the solution through validation.
Macro context
The collaboration environment changed,
but the burden of coordination did not disappear.
As remote and hybrid work became more common, teams grew more dependent on message streams, task systems, and shared calendars. At the same time, workdays became increasingly interrupted by notifications, multiple entry points, and repeated syncing actions.
68%
said they lacked uninterrupted focus time during the workday.
Microsoft Work Trend Index 2023
10
apps used per day on average by leaders to coordinate work
Asana Anatomy of Work Global Index 2023
System friction
Collaboration is still inefficient because work is coordinated across disconnected layers.
Task tools support planning. Chat tools support communication. Calendars support scheduling. But real collaboration still requires people to move between systems to rebuild context, confirm status, trace discussions, and synchronize decisions.
01
Information is still hard to locate
Even when people know where work might live, the surrounding knowledge is often scattered across tools and channels.
02
Work is tracked differently across teams
Different conventions and structures increase overhead when collaboration crosses roles, functions, or timelines.
03
Communication interrupts execution
Responding quickly to messages often becomes more urgent than advancing priority work, turning coordination into hidden labor.
Key interpretation
Derived from the industry reports and workflow research cited below.
Existing tools gap
Existing products support isolated activities well,
but not the transition between them.
Research on digital workplaces and task switching suggests that productivity loss often comes from chasing information across disconnected systems. The coordination cost is not removed by tooling. It is redistributed into transitions between tools.
Chat tools
They support fast alignment, but decisions and progress are difficult to preserve as durable workflow context.
Calendar tools
They organize time, but remain detached from the task and discussion history needed to understand what time is being spent on.
Cross-tool reality
Users manually reconstruct relationships between tasks, communication, and scheduling, which embeds coordination cost inside everyday work.
Target segment
Small teams feel this
coordination cost more directly.
In small and medium-sized teams, roles often overlap, operational capacity is limited, and communication happens while work is already moving. That makes context loss more visible and more costly, because the same people are often responsible for execution, coordination, and follow-up at the same time.
Strategy lens
A lightweight strategic snapshot clarified where the opportunity actually lies.
This is not intended to be a full business analysis. It only keeps the parts that were most useful for product strategy and design direction.
Final framing
The opportunity is not to add more features. It is to redesign the collaboration chain itself.
Based on the changing industry context and collaborative environment, the direction of this project is to reorganize the relationship between task management, communication, and time planning around the team’s actual collaborative process.
This framing gave the next research phase a clearer focus: where coordination cost concentrates, for which roles, and at which points in the workflow.
user research objective
Locating Information Gaps
Within the Workflow
After the industry background analysis, I wanted to validate a more specific question: when tasks, communication, and scheduling are split across different entry points, exactly where do collaboration costs concentrate, for which roles, in which scenarios, and at which points in the workflow?
01
Who carries the greatest coordination burden during collaboration
02
At which points teams are most likely to lose context
03
Whether small teams truly need more features, or a more coherent workflow
Participants and methods
Two core roles, multiple methods, and three high-frequency collaboration scenarios.
To keep the problem close to real collaboration, I focused on two core roles: project leads and team members.
Research Methods
Questionnaires
Interviews
Empathy Maps
Journey Mapping
Focal Scenarios
Task Advancement
Information Alignment
Status Tracking
Survey research summary
Broader input validated the project’s focus on smaller teams and coherent workflows.
Survey research complemented interviews and journey mapping by identifying team size patterns, expected capabilities, and recurring collaboration problems.
What is your current position?
Team Member 46%
Project Manager 42%
Executive/Admin 8%
Other 4%
About how many members are in your typical project?
40%
30%
20%
10%
1-5 People
6-10 People
11-20 People
21+ People
Which capabilities should be prioritized first?(Multiple choice)
Clear project visibility88%
Task ownership & context81%
Communication tied to execution73%
Scheduling linked to workflow61%
Lower learning cost52%
Where do tasks and updates usually come from?
Chat Tools
Task Boards
Meetings
Shared Documents
Email
Status Reports
Shared Calendar
Direct Follow-up
What collaboration issues appear most often?
Low Status Visibility
Incomplete Task Context
Unsynchronized Progress
Scattered Feedback
Tool Switching Cost
Repeated Clarification
Priority Confusion
Coordination Overhead
Where do teams check project status first?
Task Board / List
43%
43%
Chat History
32%
32%
Direct Follow-up
25%
25%
Research findings
Three recurring patterns explained where the collaboration chain breaks down most clearly.
Together, the findings showed that collaboration friction is driven by repeated breaks between status visibility, communication, and execution continuity.
Research Finding 01
Project status lacks a unified view, making it hard for managers to build a quick global understanding
For project leads, the main issue was not missing tasks, but the lack of a unified view. Tasks, discussions, and schedules existed separately and could not be interpreted together at a glance.
Even with multiple tools, managers still struggled to answer basic questions quickly: Is the project on track? Which tasks are at risk? Who needs coordination?
Core research conclusion: the team does not lack status information. It lacks a unified view that supports judgment.
Research Finding 02
Communication becomes disconnected from execution, forcing teams to repeatedly rebuild context
In daily work, discussion often happens outside the task itself. Once communication is detached from execution, teams repeatedly trace conversations and reconstruct decisions.
This creates execution friction: team members spend time rebuilding context instead of moving work forward.
Core research conclusion: the issue is not simply low communication efficiency, but the fact that communication is no longer continuously attached to the execution chain.
Research Finding 03
Small teams cannot absorb the additional burden created by complex systems
For smaller teams with overlapping roles, complex systems themselves became a source of cost. Teams needed faster entry into work, not heavier tools.
For these teams, the priority was clearer information, more direct paths, and less switching-not heavier process control.
Core research conclusion: what small teams need is not stronger control, but lower collaboration friction.
Problem definition
The final problem focused on workflow continuity rather than feature completeness.
Both the earlier industry analysis and the user research pointed to the same conclusion: teams do not lack collaboration tools. The real problem is that tasks, communication, and scheduling are broken apart across different entry points, preventing information from continuing to flow within the same context.
Scope Convergence
Once the problem had been redefined, the product scope also needed to be narrowed. Rather than trying to cover every complex project management scenario, I chose to prioritize the high-frequency paths where team collaboration breaks most easily:
High-Frequency Paths
Viewing project & task status
Syncing info within collaboration
Advancing schedule in context
Out of Scope (Low Priority)
Complex Approvals
Enterprise Governance
Deep Configuration
Core design decisions
Translating research insights into structural product choices
Once the collaboration problem was clarified, the design question shifted from adding features to reorganizing workflow structure. Three decisions shaped the experiential backbone of the product.
Decision 01
Unified workspace for status visibility
DashboardOverviewStatus
The home page was defined as a unified workspace - not a feature directory. By combining project overview, task status, today's schedule, and activity information, users build an understanding of overall project state before deciding what to do next.
Reduces cost of searching for project status across multiple pages
Helps managers build a quick overall understanding
Shifts from "tracking information" to "making judgments"
"The value of a unified workspace doesn't come from containing more information - it comes from making information easier to read and judge."
Decision 02
Continuous collaboration space
TasksCalendarTeamsChat
Chat, tasks, and calendar were organized as different points within the same collaboration chain. Through consistent navigation, adjacent work modules, and unified visual rules, the system supports viewing tasks, syncing progress, arranging time, and initiating communication within the same workspace.
Lowers switching cost between tasks, communication, and scheduling
Reduces burden of repeatedly tracing background
Turns disconnected actions into a continuous process
"Reducing context loss doesn't mean merging all functionality - it means organizing the collaboration chain continuously."
Decision 03
Lightweight, high-frequency paths
Small TeamsFast RhythmLow Entry
The product prioritized the most common and most fragile paths: task progression, team coordination, scheduling synchronization, and communication management - rather than complex approval flows, heavy configuration, or enterprise-scale governance.
Lowers learning and maintenance cost
Makes core paths shorter and clearer
Prevents product from drifting through feature stacking
"For small teams, value comes not from broader capability coverage - but from a lower-friction experience for frequent collaboration."
information architecture
Define the workflow before defining the modules.
If the product continued to be organized as a stack of separate functional modules, it would easily fall back into the same state of fragmented tools and frequent switching. For that reason, the information architecture stage began not with page count, but with the collaborative path itself.
Workflow Structure
Modules no longer exist as parallel feature entry points. They work together in service of one continuous collaborative process: Status Awareness → Collaborative Execution → Communication Support.
Structural Trade-offs
To keep the system clear while avoiding fragmentation from over-tooling, I made several key trade-offs during the information architecture stage.
Workflow over feature grouping
Modules stayed separate, but were organized to support one continuous collaboration flow.
Wireframe exploration
Low-fidelity exploration tested whether the structure was clear enough before visual design.
Once the information architecture had been narrowed, wireframes were used to explore layout and interaction flow across the key interfaces. The goal was not to lock visual style early, but to validate structure, information hierarchy, and core paths.
Key page types
Dashboard: the first cognitive entry point after entering the system
Tasks / Projects: the central path for viewing, advancing, and changing task state
Teams / Calendar: the supporting path for member coordination and schedule synchronization
Chat / Email: how communication could stay close to task execution instead of becoming isolated again
What this stage validated
whether the home page could help users quickly build project awareness
whether task structure was clear enough to surface priorities and progress
whether schedule and member coordination could enter the workflow naturally
whether communication remained connected to the execution chain
COGNITIVE WALKTHROUGH
The focus was whether users could move through key paths without hesitation or repeated context reconstruction.
At this stage, a cognitive walkthrough was used to evaluate the key task paths. The goal was to examine whether the current structure was clear enough for first-time use, whether transitions felt natural, and whether important information was visible at the moment it was needed.
Validation focus
Quickly understand the information on the home page and decide what to do next
Find the information needed while moving tasks forward
Switch naturally between communication, tasks, and scheduling without losing context
Understand the system structure instead of repeatedly guessing between modules
What this stage validated
This stage examined whether the structure was clear, whether transitions felt natural, and whether the information supported judgment across dashboard interpretation, task progression, scheduling alignment, and communication transitions.
Walkthrough evaluation criteria
01
Will the user try to achieve the right effect?
一Form correct intention
02
Will the user notice the correct action is available?
一Form and execute correct action plan
03
Will the user associate and interpret the response from the action correctly?
一Perceive, interpret and evaluate the feedback correctly
Walkthrough evaluation procedure
Problems Identified
The evaluation surfaced three issues that still weakened the experience: hierarchy, transition continuity, and comprehension cost.
Transition Smoothness
Some collaborative touchpoints still exhibit friction, leading to occasional background re-confirmation.
Iteration Directions
Based on these findings, the next round of iteration focused on strengthening hierarchy, improving transitions, and lowering the barrier to understanding the system.
Final Solution
The final solution was structured as a continuous collaboration path, not a stack of parallel modules.
For small and medium-sized teams working in fast, overlapping, and constantly shifting collaboration rhythms, the final solution focused on workflow continuity, structural clarity, and the ability to carry context across different actions.
When a team enters the system, the first need is not action, but judgment. The home layer therefore works as a stable entry point, bringing together project progress, task status, daily schedules, and recent activity so users can build a quick understanding of the current state. This layer gives later actions a clearer sense of priority and helps different roles enter the workflow from the same shared starting point.
Dashboard
The Dashboard supports the first judgment after entering the system. It places project overviews, task summaries, key reminders, and daily schedules in one view so users can understand the overall situation before deciding what to do next.
Activity
The Activity page focuses on what has changed recently. It brings updates, comments, changes, and reminders into one place, helping users recover context more quickly and reducing the need to trace information across separate entry points.
Once the overall state is clear, collaboration shifts toward task progress, team coordination, and scheduling. This layer determines whether users can continue high-frequency actions within the same context, so execution-related pages were organized into a tighter path. Task progress no longer sits on its own, while team relationships and scheduling are brought back into the execution flow, making the rhythm of collaboration easier to maintain.
Projects
The project overview works as a transition from the global view into specific workstreams. It allows users to scan project lists, status, and priority before moving into more detailed execution layers, keeping the structure continuous between overview and detail.
The Kanban view is better suited to tracking movement during execution. It makes task progression across stages easier to read, helping users identify bottlenecks, stage distribution, and momentum with less effort.
The Timeline page handles the relationship between execution and time. It helps users understand milestones, project pacing, and task distribution so planning and delivery can be read within the same view.
Tasks
The Tasks page supports more detailed day-to-day execution. Task state, ownership, priority, and due dates are organized at the same level, allowing team members to handle frequent updates and ongoing progress more directly.
Teams
The Teams page keeps collaboration relationships visible. It makes people, roles, and working structure easier to understand, so coordination during execution does not rely entirely on extra communication.
Calender
The Calendar page brings time planning back into the workflow. Task progress, meeting rhythm, and scheduling can be understood and adjusted within the same structure, reducing unnecessary switching during execution.
One of the recurring frictions in the research was not a lack of communication, but the weak connection between communication and task context. To reduce that gap, the final solution places communication pages back inside the collaboration path, so discussion, confirmation, updates, and follow-up can stay closer to the work itself. This makes it easier for team members to continue with the task at hand without repeatedly reconstructing context from separate channels.
Chat
The Chat page supports immediate coordination and short-cycle discussion. It stays close to execution, making it more suitable for quick alignment, clarifications, and task-related communication.
The Email page handles more formal and longer-range communication. It extends collaboration beyond immediate messaging while still keeping confirmations, follow-up, and external exchanges within the same overall workflow.
Results & Reflection
The most important result was structural, not cosmetic.
The outcome was not simply "a completed high-fidelity interface." It was establishing a clearer direction: reorganize the relationship between tasks, communication, and scheduling so teams can build awareness, advance execution, and synchronize within one shared context.The outcome was not simply "a completed high-fidelity interface." It was establishing a clearer direction: reorganize the relationship between tasks, communication, and scheduling so teams can build awareness, advance execution, and synchronize within one shared context.
What This Design Actually Changed
B
Before: Status checking, task progression, communication synchronization, and schedule adjustments were all separated — teams reconstructed relationships between those actions themselves.
A
After: Users first build an overall understanding of project status → move into task progression and team coordination → continue maintaining continuous information flow through communication and scheduling.
Key Project Learnings
Learning 01
The value of complex products comes less from feature count and more from organization
When facing complex collaboration problems, the real job of the designer is not to keep adding modules, but to reorganize the relationship between information and action.
Learning 02
User research should support decisions, not prove a process was completed
The most important research outcomes helped identify judgments that truly shaped the solution: status visibility, contextual continuity, and lightweight structure.
Learning 03
Validation corrects structural assumptions — not just visual polish
Validation doesn't endorse a solution. It reveals which assumptions already hold and which still need refinement. For system-level products, that matters even more.