Jacob Rush
Design, Product
San Francisco, California

Designing an editing experience

A systems project creating a quick and consistent editing experience

The product

A CRM for Product led growth

Business goals

The MVP of Poggio was looking to improve on its early traction

Increase product activation

Poggio had begun to see an influx of users, but struggled with conversion and product usage

Increase data commits

CRMs are built on top of data. Without a sufficient amount of data commits, the value of automations, reporting, and insights diminishes.

Build trust in data accuracy

Inaccurate data can quickly lead to distrust in a product, which is extremely hard to re-earn.

Problem

Inefficient editing experience

The MVP of Poggio routed all edits into a drawer, listing all customer input fields

Loss of Context. Redirecting users to a separate drawer resulted in a loss of context of their current view, items, and details. Users were surprised and disoriented by this interaction.

Non-targeted editing. Editing values was only available through a long form of input fields. This increased cognitive burden, making it difficult to quickly locate and edit a singular value.

Product + Design Goals

Design a system-wide editing experience

Quickly and contextually edit individual data points

Users edit a lot of data in Poggio. Ensuring speed while maintaining  context will enhance the user experience drastically.

Editing is a high priority action

Editing is a primary workflow within Poggio. Data gets edited daily. Making sure editing is discoverable will reinforce this workflow.

Design flexible, scalable editing components and workflows

Editing is a core action. Reusable, scalable components will increase consistency and reduce future engineering effort.

Design Challenge

What component is the best for editing?

To design a consistent experience, it was necessary to audit what component would best support an editing experience in all workflows

Popover Menu

Popover / From Table

Popover / From Header

Popover / From Header

Modal

Modal / From Table

Modal / From Header

Modal / From Card

Dropdown Menu

Dropdown / From Table

Dropdown / From Header

Dropdown / From Card

Weighing flexibility, scalability and speed

Popover Menu

(+) Flexible Use. Popover menus fit smoothly with many workflows and screens.

(+) Maintains context. Appears in-line, taking minimal space. Maintains context and details.

(+) Quicker Editing. Popovers appear in-line, offering a quick editing experience.

Modal

(+) Flexible Use. Works for data editing within any workflow, screen, or component.

(–) Loss of Context. Modals are focused, and can block contextual data.

(–) Slower editing. Modals remove the user from their workflow, slowing down the editing experience.

Dropdown Menu

(–) Inflexible pattern.  Must be paired with input fields; are suboptimal within headers and cards.

(+) Maintains context. Appears in-line, taking minimal space. Maintains context and details.

(+) Quicker editing. Dropdowns appear in-line, offering a quick editing experience.

Decision

Popover Menus

Popover menus offered the most well rounded solution to the project goals. They offered cross application flexibility, while supporting a quick, contextual editing experience.

Design Challenge

Auto-save or manual save?

Committing accurate customer data is essential in a CRM, to increase trust of the underlying platform

Manual Save

(+) Guardrail against accidental commits. A save button protects data integrity by reducing accidental edits.

(–) Space intensive. Labeled CTAs must be included with every piece of editable data.

Auto Save

(+) Quicker editing. A save button is an added guardrail that slows down the editing experience.

(–) No guardrail against accidental commits. Without a save button, it increases the likelihood that users make accidental edits to important data.

Decision

Manual save

Manually saving protects the reputation of Poggio by preventing accidental commits, and increasing clean and accurate data.

Design Challenge

How should edits be triggered?

To design a consistent experience, it was necessary to audit what component would best support an editing experience in all workflows

Labeled CTAs

(+) Scalable. Labeled CTAs can support several features: navigation, commenting, etc.

(+) Discoverable. Labeling CTAs increases prominence and reinforces discoverability

(–) Space intensive. Labeled CTAs must be included with every piece of editable data.

Clicking in line

(–) Less scalable. Clicking in line doesn't support future actions like history, navigation, or commenting.

(–) Less discoverable. Editing is high priority feature. Clicking in line significantly reduces the prominence of editing

(+) Saves space. Clicking in line removes the CTA, saving space and preventing redundancy.

Decision

Labeled CTAs

Labeled CTAs closely aligned with the project goals of creating a scalable, highly prominent editing experience.

Closing the Project

A reusable, scalable, targeted editing experience

Success metrics

Improving user interactions and internal processes

Increased project speed by usage by 2 story points

The reusable editing experience contributed an increase product velocity

Increased data commits by 10% month over month

Due to the quicker editing workflows, Poggio immediately saw more data commits from all users.