Markdown-free editing for Work Management
- Overview
- In Datadog Work Management, the description is where the real substance of a work item lives, but the field was a markdown input. Writing a heading, link or table took syntax knowledge and a mental translation between what you typed and what readers saw. Internal feedback, my PM and an engineer on my team all wanted something lighter. Engineering didn't have the bandwidth and the change was frontend-only, so I designed it, built it and shipped it myself.
- Impact
- I led the design and frontend implementation of a new inline description editor, shipped as a stack of six PRs. It's now live for Work Management customers.
- Role
- Product DesignerFrontend Engineer
- Duration
- Summer 2026
- Team
- Roxanne M (PM)Benjamin G (Senior Engineer)Rahul G (Senior Engineer)
The problem
The description field was a markdown input, which caused two problems. You had to know the syntax: tables meant typing pipes, dashes and alignment rows by hand. And you wrote in one mode and read in another, going from read mode to edit mode to save instead of just clicking and typing.
The new editor
Slash commands and a selection toolbar replace the syntax, and inline editing replaces the mode split. The interaction model comes from Notebooks. One rule shaped every decision: the editor only offers what markdown can store.
Seeing what changed
Before. The timeline already posted the full description on every save, and autosave multiplied it into walls of flattened markdown. You had to compare them by eye to spot what changed.
What shipped. Each edit becomes one line, and “View changes” opens a word-level diff right in the timeline.
What didn’t make it. I explored three versions that opened the history in a modal. The inline diff got most of their value with far less to build and maintain.
Design to production
After a quick Figma pass, I designed most of this in the browser, where details like cursor placement and link edge cases can be tuned by using them. It’s built on ProseMirror through TipTap.
Stacked PRs
I split the work into six stacked PRs, each building on the last, with the final one switching the editor on. About 8,200 lines and 105 tests.
Comments and review
Review shaped the design, not just the code. An engineer showed me a header toggle that didn’t survive a reload, which became the markdown rule. Review also caught bugs that could have lost unsaved edits.
Feature flag
Everything shipped dark behind a flag, and all six PRs merged together so nothing broke mid-stack.
Internal dogfooding
We turned it on internally first, and real use found bugs tests had missed. After a round of fixes, it went live for customers.
Great work on taking up the editor improvements, ironing out the smallest of the wrinkles takes time & I think we should set a similar bar for our UI features.
— Engineer on the Work Management team
I’m in Work Management every day. So my engineer and I realized right away. And the table is working great too.
— Work Management user
What I learned
- The storage format is a design constraint. “Can markdown store this?” settled most decisions before I’d drawn anything.
- Make every stacked PR clickable. Reviewers should be able to try a PR without waiting for the end of the stack.
- Ship to internal users early. Dogfooding found what tests missed.
Thanks to my PM, the engineers who reviewed every PR, and the Notebooks designer and engineer.