Framer CMS List: make each item a whole you can add, remove and reorder
Framer is a visual website design and publishing tool. CMS List lets content teams maintain course outcomes, FAQs or tutorial steps as rows, then display changing content through a consistent card design.
Form your own approach first, then explore the reasoning to check trade-offs and validation you may have missed. There is no single right answer.
How should a CMS preview the move from numbered fields to a list?
Scenario
A course site stores outcomes as numbered fields such as “Outcome 1 title” and “Outcome 1 description.” Design the confirmation experience for converting them into a list of outcomes, where each row has a title and description and page cards read those rows. The migration affects both content storage and page display, so users need to understand the change before confirming.
Given conditions and requirements
Design a confirmation flow for converting numbered fields into a list in your own CMS. Do not assume this is Framer’s existing interface.
- Existing content. A course has “Outcome 1 title/description” through “Outcome 5 title/description.” Some fields are absent, some exist but are empty, and an item may contain only a description. Page cards still bind to the old fields.
- Change scope. Conversion affects both content and page bindings. A “conversion successful” message alone is insufficient. Different courses may produce different numbers of rows.
- User decisions. Show which items are retained, which need a decision and which page bindings cannot be mapped automatically. Do not silently discard empty items or rewrite the text.
- Validation. Design preview, confirmation and return-to-edit paths. Propose at least two tasks that test whether users understand the change. Reconstructing the product’s internals is outside the exercise.
Work through this case
Course A has a complete first pair, a second pair with an empty title but a description, and no third pair. The second page card still reads “Outcome 2 title.” Show how a user sees these differences, checks the affected card and handles a binding that cannot be mapped automatically. A binding connects a page element to the field supplying its content.
What to deliver
Deliver a before/after preview sketch, a confirm/return flow with unresolved items, and two tasks asking users to predict retained content and page output. No migration implementation or automatic text completion is required.
Explore the reasoning
- Show content differences before totals. Put one course’s old fields beside its new rows. Distinguish absent values, empty strings and descriptions without titles. A row count helps, but cannot prove lossless conversion.
- Connect content to its use on the page. Selecting a row should reveal its intended card or binding. Put unmappable items in a pending list that identifies affected pages, instead of exposing only field IDs.
- Bind confirmation to the visible version. Refresh the preview when conversion rules change. Do not keep an old confirmation. Let the user preserve the original content and return to unresolved items; inventing a title should not be a requirement for proceeding.
- Test understanding before claiming efficiency. Give participants a course with only a description and a page still bound to an old field. Ask what will be retained and what remains unresolved before publication. The experiment has not been run. Record mistakes and completion paths before deciding how to improve the interface.