Case file 02Partial release

Menu
Management

Menu Management is the system's most-used administration area. I led a shared redesign that keeps complex records clear and predictable.

Role

Lead design, workshop facilitation, interaction rules, and handoff.

Product

Volanté Backoffice, the business administration application.

Team and period

With Inaia Silva, product, engineering, and quality assurance, 2025 to 2026.

Status

Navigation and configuration work reached delivery in stages. More work remains in review.

Dense information

Give structure, records, and detail different jobs.

Administrators manage items, categories, prices, choices, and store permissions. Each task can affect many connected records.

I led the redesign with Inaia Silva. We used a left-to-right structure that keeps the editing context visible.

  1. Use the left tree to choose the business area or category.
  2. Search, scan, and select records in the centre grid.
  3. Inspect the selected record in the right panel.
  4. Open the full detail page only when the task requires it.

Search and filters stay at library level. Detailed editing stays with the item. This stops the same navigation controls from spreading across every record.

Menu Management grid component with sample item names, prices, tags, and selection states

Interaction decisions

A row should do the same thing every time.

Development exposed a basic question: should a row open on double-click, or when someone clicks the selected row again?

I compared familiar administration products and wrote one rule for all Menu Management tables.

  1. A single click selects the record and opens its preview.
  2. The arrow and See Details button open the full page.
  3. Repeated clicks keep the current task stable.
  4. Double-click never navigates, because rows can support inline editing.

The same rule guided bulk editing. We prioritized defined actions before an unrestricted edit-anything model.

Shared option groups also keep one source of truth. People edit the source group, and every connected combo keeps the relationship.

Design in public

Show the weak idea, then improve it.

The Quick Menu started as a 14 by 14 grid. Labels became too small, scanning slowed down, and the same structure had to serve point of sale, kiosk, and mobile.

We reviewed one version after another with the team. Each round stated what was wrong before moving forward.

  1. A grid-to-list switch made reordering difficult to predict.
  2. Row indicators did not translate well across platforms.
  3. Different layouts for each platform increased maintenance.
  4. The sixth version used one flexible column with unlimited rows.

The selected direction added list insertion, reorderable tabs, multi-select drag and drop, and search.

Engineering partnership

Sequence the redesign around real constraints.

Existing shared components lacked responsive specifications. I framed two options: update the full system, or define the Menu Management components first.

The team chose the module-first path. Inaia wrote left-panel guidance. I clarified when item panels omit a header to make room for the task.

I also led an impact-and-effort workshop with product, development, and quality assurance. The group prioritized bulk actions and right panels together.

Delivery

Ship the foundation, then expand it.

Navigation, category, and linked-option work reached delivery in stages. Design review continued through implementation differences and responsive questions.

Combo Sets became a first-class area with its own list, detail view, permissions, and multi-store actions. The interaction rules and shared structure made that expansion possible.

My next measures would cover bulk-edit completion, navigation errors, and time to find an item.

Next case fileSelf-service Kiosk →