Jeremy Xie. Selected work
EN/中文

Selected work / 03 · Project Sheet

From product logic to a complete interaction system.

Project Sheet combines database logic with spreadsheet presentation. I used both to build a design approach, investigate tasks and prioritize problems, then address task dependencies through two connected areas: improving the Gantt view and defining the field’s interactions.

Explore the design process
ROLE & SCOPE
UX design: product and requirements analysis, competitive and task research, Gantt improvements, dependency interactions, and component-based design delivery.
Tasks, timing and dependencies, coordinated in one view.
1New field
2Design workstreams
3Gantt priorities
4Dependency stages

01 — Understand the product

Database logic. Spreadsheet presentation.

Project Sheet serves focused scenarios such as project management and CRM. Its data logic draws on databases, while its presentation draws on spreadsheets. I analyzed requirements through both functional structure and information organization, considering how data and actions work together and how people understand them.

01 / DATABASE LOGIC

Functional structure

What data is stored, how records relate, and what actions are possible.

02 / SPREADSHEET PRESENTATION

Information organization

How the same data is arranged so people can understand it and act.

The task view anchors both paths in a real product context.

How can these two characteristics become a practical design method?

02 — Build the method

Complete actions, across three layers.

For functional structure, I used create, delete, read, and update to check interaction completeness, from configuring a field to entering its cell content. For information organization, I examined views, toolbar operations, and fields: how a field appears across views and behaves under grouping or filtering.

Original information-structure board: views, tools and fields affect one another.
Two complementary checks / adapted from the originalFIG. 02

Are the actions complete?

  1. C

    Create

    Configure the field; add cell content.

  2. R

    Read

    Locate the record; understand the relationship.

  3. U

    Update

    Change content and related states.

  4. D

    Delete

    Remove the intended object with clear feedback.

Where does the information change?

  1. View

    The form of a record across grid, Gantt, gallery and Kanban.

  2. Tool

    The effects of grouping, filtering and hiding fields.

  3. Field

    The meaning, constraints and content of a cell.

Example: a new dependency field needs field configuration and cell entry, plus a readable representation in each view and under grouping or filtering.
READ THE DESIGN THROUGH USER TASKS

Connect the job to the interaction decision.

Alongside the operation-based checks, I can explain the design through what people need to accomplish: arrange work, understand its timing and adjust related tasks. The concrete proposals below show how each job connects to an obstacle and a design response.

JOB

Arrange team work

OBSTACLE

Task order and dependency direction need to be understood across views.

DESIGN RESPONSE

Consistent relationship types, labels and arrow directions, with creation from fields or Gantt endpoints.

Explore the design
JOB

Read the schedule accurately

OBSTACLE

Fields compete for space; dates and milestones become hard to distinguish at larger scales.

DESIGN RESPONSE

Focus the main field, show owners in the Gantt area, and reveal exact dates and grouped milestones.

Explore the design
JOB

Adjust connected work

OBSTACLE

Batch edits and parent-child changes need clear, coherent range behavior.

DESIGN RESPONSE

Connect multi-selection, batch date changes, parent-child rules and an option to disable dependency-date linkage.

Explore the design
A task-based retrospective of the original proposals, with reasoning similar to Jobs to Be Done. The documented historical method remains CRUD and information-layer checks.

Apply the same checks to a concrete task-dependency requirement.

03 — Requirements & research

One new field. Two connected workstreams.

Task dependencies help teams understand sequence and timing, with the Gantt view providing a key context. Existing usability issues could undermine the new field, so I worked with product to divide the work into dependency design and improvements to the Gantt view.

WORKSTREAM A

Improve the foundation

Resolve the usability issues in the view that will carry the new relationship.

WORKSTREAM B

Define the relationship

Design how a dependency is created, recognized, changed and removed.

Keep familiar forms. Refine the details.

Competitive research examined entry points, direction, display, editing and removal through the same action framework. Familiar arrows and fields provided the foundation; the design focus moved to micro-interactions and UI details.

Observe tasks, then ask why.

Two experienced test colleagues, three people new to the feature, and three light users participated in qualitative research. The observations locate usability problems; they do not establish population-level success rates.

Original competitive examples: relationship entry points and line direction.
TASK 01

Create a Gantt view

Match the date fields and establish the first time bar.

TASK 02

Adjust connected tasks

Change dates for several tasks and understand parent–child timing.

Research appendix · original task sheet

Tasks were organized by action dimension. The appendix contains multiple task groups; no completion-rate or timing scores have been added.

Table C · original task and question sheet.

04 — Priorities & scope

Choose the changes that solve connected problems.

Not every issue needed to be solved in the same release. I considered frequency, learning difficulty and impact, with development cost constraining scope. Related findings were then grouped into three areas of improvement, each checked for other problems it could address.

Original priority plot: frequency against learning difficulty / impact; color indicates anticipated development cost.
A

Information space

Focus on the primary field; put owners in the Gantt area; make hidden fields recoverable.

  • E1

    Too many field columns take up too much page space.

  • E3

    When collapsing columns, I want to keep the title column.

  • E4

    I do not know how to reopen hidden columns.

  • G3

    I cannot see task owners without expanding the fields on the left.

B

Time accuracy

Clarify time scales, exact dates and milestone placement.

  • G1

    I cannot tell precise start and end dates at month, quarter, half-year or year scales.

  • H1

    I cannot tell the exact milestone date at month, quarter, half-year or year scales.

  • H3

    Multiple milestones are hard to distinguish.

  • K2

    At large time scales, I cannot see the new date after an edit.

C

Coherent multi-task actions

Connect selection, batch edits and parent–child ranges.

  • J1

    Adjusting the order of several rows is inconvenient.

  • K1

    The handle for changing a subtask’s date is too small.

  • K3

    Parent and child time bars do not automatically adapt to changes.

First make the Gantt foundation work. Then bring the dependency into it.

05 — Workstream A · Gantt view

Clearer information. Coherent actions.

The Gantt improvements addressed three priorities: allocating space to essential information, making dates readable at different scales, and defining consistent interactions for multiple tasks.

A

Give the timeline room to breathe.

Problem · fields occupy the view, while owners require another lookup.

Focus the field area on the primary key. Move owner avatars into the Gantt area and duration into hover feedback. Keep explicit controls to collapse and restore other fields.

The optimized view: task identity on the left; owners and timing alongside the bars.
B

Make the date precise at every scale.

Problem · large scales obscure exact ranges and merge milestone positions.

Distinguish dates and weekends at week, month and quarter scales. Reveal the exact range when a time bar is in focus; define milestone positions and aggregate those within the same unit.

Date feedback alongside the focused time bar.
Milestones at quarter scale: shared time units are grouped.
Original date-adjustment feedback: precise dates during the interaction.
C

Keep multi-task editing coherent.

Problem · batch changes and parent–child edits follow disconnected rules.

Click a time bar to select it; use Shift for multi-selection. Batch date edits and dragging follow the same change. In the original design, shrinking a parent pulls children into its range; extending a child expands the parent.

Original multi-selection state.
Original parent–child range interaction.

06 — Workstream B · Task dependencies

A field is complete only when every action works.

With the Gantt foundation addressed, I returned to the method to define how dependencies are created, recognized, changed, and removed. I checked their behavior across the grid, Gantt view, detail panel, and other views to maintain a consistent understanding of relationship direction.

C

Create · one direction across entry points

VIEWTOOLFIELD

In the grid, choose a relationship type and search for a task. In Gantt, drag from a time-bar endpoint. Matching icons and arrows clarify the direction, target and completed state.

Choose the relationship type, then find a task.
Search while keeping selected relationships visible.
Original Gantt design · three consecutive statesCREATE / GANTT
01 · Start from the edge of the time bar. The arrow makes the direction explicit.
02 · The target gains a border and shadow as the connection approaches.
03 · The completed connection stays in its task and time context.

Constraints and conflict feedback

Existing dependencies cannot be created again, and dependencies cannot be created between parent and child tasks. Time conflicts use red lines and label icons; a logical conflict makes the dragged line bounce back.

Time conflict: a red connection signals a task-timing conflict.
Logical conflict: the original line-bounce-back illustration.
R

Read · recognize both relationship and direction

VIEWTOOLFIELD

Dependency tags need to differ from linked-record and multi-select fields. Color and symbols work together, and gallery or Kanban views use one relationship per row. Gantt paths reveal the same relationship spatially.

Gallery dependency tags: color and symbols distinguish direction, one relationship per row.
A stepped line keeps the relationship readable between time bars.

The original design defines Z-shaped, stepped and snake-shaped paths for different positions. Hover emphasizes related paths; grouping is considered alongside the line rules. Frame 12 also describes a click entry point for editing or removal.

U

Update · show the effect and preserve control

VIEWTOOLFIELD

Cells handle changes through removing and adding relationships; the detail panel supports changing the type. The design also links dependent dates after a drag, with a setting to turn that behavior off.

Original date linkage: related tasks move with the edited dependency.
A setting allows automatic task scheduling to be turned off.

Changing the dependency type

The original menu distinguishes “Be blocked by” and “Blocking”.
Task and relationship context in the detail panel.
D

Delete · make the target unambiguous

VIEWTOOLFIELD

Removal should make the current target clear. Keep the entry close to the tag or connection, and emphasize the relationship being acted on.

Hovering a relationship line reveals a removal control and emphasizes the target.

The deleted object is the relationship, not the task. Table and detail entries remove the tag. Frame 14 shows hover-to-remove on a line; the click entry in Frame 12 is retained as a separate source description rather than combined into an invented final rule.

Complete relationship-removal board: field tags and Gantt connections.

07 — Component-based delivery

Let the file express the design logic.

The design logic also informed the way the files were built. I separated the Gantt view into the task list, timeline, and time bars, using components and Figma layout parameters to support consistent states and changes.

Complete handoff board: task lists, timelines, time bars and component organization.
Gantt / three modulesFIG. 12
01 · Task list02 · Timeline03 · Time bars
Original modules and variants, organized to carry the interaction rules into the design file.

Layout detail · from the original component

row/ganttHorizontal layout · 343 × 40 · spacing 0
column/ganttVertical layout · 336 × 48 · spacing 0
cell/ganttFixed cell · 48 × 40

08 — Outcomes & reflection

From design improvements to a better experience.

The original review reports a 3.4% rise in Gantt usage frequency following the November 2022 release, alongside a separate account of addressing enterprise customer needs. My takeaway is the connection between product understanding, research, prioritization, and detailed interaction design.

PROJECT SHEET · PRODUCT EXPERIENCE

Better experience across the product.

I connected research, feature planning and interaction design, prioritizing Gantt improvements and dependency fields within the broader product experience.

−24%

Negative feedback count

Decrease across Project Sheet overall.

4.2 → 4.5

Overall user rating

Improvement in the overall product rating.

These two measures cover Project Sheet overall. Gantt usage frequency is presented separately below.

+3.4%

Gantt chart usage frequency

A method carried through the work.

The accumulation here is a continuous line from product understanding to research, priorities and interaction details. Data logic, information organization and each action check one another.

Separate evidence · customer feedback

The review separately records responses to enterprise customer needs. The feedback chart below is not the measurement behind the 3.4% usage change.

Feedback recorded in the original project review.

Appendix · other views

Task view
List view
Gallery view
Kanban view

Completeness in a complex tool comes from checking data logic, information organization, and each action against one another.

Continue exploring

Design Systems & Collaboration

From connected tasks to a shared design language.

Back to selected work