BackUX Evaluations

Admin Platforms & Applications

Concept Evaluation

Concept Evaluation · June 8, 2026

What was evaluated

The AM Back-Office Platforms & Applications admin interface from Figma (node-id 1840-2405). Three main frames were evaluated: an empty default state, a platform-selected state showing its associated applications and available actions, and a state showing a newly added application. Additional modal screens for creating a platform, adding an application, and confirming archive actions were also reviewed.

Functional7.5/10
Usable5.5/10
Desirable3/10
Buildable8.5/10
Viable5.5/10
Brand Framework2.5/10
Design Principles2.9/10

Functional

Does it solve the core problem?

7.5/10Developing

What's working

  • Solves the core admin problem with a clear hierarchical flow: select platform → view applications → take actions
  • Cascading selection pattern is predictable — mental model is intuitive
  • Uses only stable CONNECT components (Card, Button, Radio, Modal, Breadcrumb, TextField) — no novel tech debt

What to improve

  • Missing error states and post-action feedback throughout — users don't know when something goes wrong
  • No empty state when a platform is selected but has no apps assigned
  • Deletion and archive confirmation outcomes are not shown — users don't know what happens next

Usable

Can users accomplish their goals easily?

5.5/10Developing

What's working

  • Three-panel layout is familiar (similar to email inbox patterns) and mostly intuitive for first use
  • Primary task (select platform + create application) completes in 3–4 steps — quick

What to improve

  • Selection mechanism is ambiguous — the card looks identical before and after selection; there is no visual confirmation that a selection was registered
  • "Available Actions" bar is buried at top-right with a vague label — no context about which actions relate to the selected platform
  • No visual feedback on selection (highlight, background change) — users cannot confirm their selection was registered
  • No onboarding, tooltips, or help text for first-time admins — the flow must be discovered through trial and error

Desirable

Do users want this? Does it align with research insights?

3/10Needs Work

What's working

  • Simplifies a complex admin task — shows implicit care for admin users by reducing cognitive load

What to improve

  • No emotional engagement or delight — interactions feel entirely mechanical with no acknowledgement of effort or progress
  • No story connecting admin work to the LEGO mission or end-user play experience
  • Missing micro-interactions: no smooth transitions, success celebrations, or loading states with personality
  • No outcome visibility — admins don't see that their actions have meaning (e.g., 'This platform enables 1,200 shopfloor users')
  • Interface doesn't answer the 'why' behind the work — purely transactional

Buildable

Can we implement this with available resources?

8.5/10Strong

What's working

  • All CONNECT components used are stable and off-the-shelf — no custom builds required
  • Estimated 2–3 weeks for a junior developer at low risk (1w data layer + hooks, 1w UI assembly, 0.5w modals and validation)
  • Clear data model and interaction patterns that can be modelled on existing admin prototypes
  • Existing admin folder structure supports A/B test variants if needed

What to improve

  • Need to clarify archive/delete business logic with product before sprint planning (soft vs. hard delete, cascade rules)
  • API shape for bulk operations is unknown — confirm before sprint planning

Viable

Does it align with business goals?

5.5/10Developing

What's working

  • Low long-term maintenance cost — straightforward CRUD interface with minimal ongoing complexity
  • Three-column layout scales adequately to ~50 platforms with pagination and scroll
  • Aligns with the CONNECT system vision (consistent component reuse)

What to improve

  • Business objectives are not documented — viability is conditional until success metrics are defined (e.g., 'reduce admin time per platform by 50%')
  • No search, filter, or sort — will become unworkable as platform count grows beyond ~50
  • Assumes a simple 1:Many (platform:applications) relationship — won't scale to complex hierarchies, permissions per platform, or audit trails

LEGO Brand Framework

Alignment with LEGO mission, values, and System-in-Play

2.5/10Needs Work

What's working

  • Enables mutual value creation — admins manage platforms that directly support downstream business partners
  • Quality execution: clean layout, no visual clutter — reflects 'Only the best is good enough'

What to improve

  • No System-in-Play DNA — the interface is isolated, with no connection to the LEGO mission or broader AM ecosystem
  • 5 of 6 LEGO values are missing: Imagination, Fun, Creativity, Learning, and Caring are not expressed in tone, interactions, or purpose
  • 'Play Well' spirit is entirely absent — nothing about this experience feels playful or optimistic
  • Admins have no visibility of how their work connects to the end-user play experience or positive impact
  • Add moments that link admin actions to outcomes: e.g., 'You just enabled an app used by 500 shopfloor workers'

LEGO Design Principles

Alignment with the 5 shopfloor design principles

2.9/10Needs Work
Design for Your Audience2.5/10
Build from System-in-Play5/10
Tell Stories1/10
Be Playful and Optimistic0.5/10
Keep It Simple6.5/10

What's working

  • Uses CONNECT components consistently — 'Build from System-in-Play' is well executed at the component level
  • Layout is uncluttered with a clear visual hierarchy — 'Keep it Simple' is mostly met

What to improve

  • Design for Your Audience (2.5/10): No user research foundation; treats all admins as identical despite varied roles. Missing accessibility features (keyboard navigation, dark mode, font size controls). Fixed desktop layout only.
  • Tell Stories (1/10): No narrative connecting admin work to the LEGO mission. No outcome visibility. Copy is likely utilitarian rather than brand-aligned.
  • Be Playful and Optimistic (0.5/10): Zero micro-interactions, no transitions, no delight. Creating or archiving is mechanical — no success states or personality in loading.
  • Build from System-in-Play (5/10): 'Available Actions' breaks the CONNECT pattern — consider integrating into card footers or a contextual menu instead.
  • Keep It Simple (6.5/10): First-time guidance is missing and users must discover the flow through trial. Radio button vs. card click target needs clarification.

Next Steps

  1. Layer in playfulness and storytelling — iterate on the design to show how admin work connects to the LEGO play experience. Add micro-interactions, success celebrations, and outcome visibility (e.g., 'You've freed up this platform for 500 future users'). Estimated: 0.5–1 week design iteration.
  2. Clarify business objectives and archive/delete rules with product before sprint planning — define success metrics and confirm data model assumptions (cascade rules, soft vs. hard delete, bulk operations).
  3. Improve the selection and actions flow — add visual feedback on card selection (highlight, background change), relocate 'Available Actions' into card context (footer or contextual menu), add tooltips for first-time users, and design error states and post-action feedback.