Case Study

A Preset Model for Updating Layouts

One click, no guesswork: template updates simplified.

Hand-drawn sketch: hover animations with before/after states
Domain
Enterprise SaaS
Presentation Software Add-in
My Role
Associate UI Designer
Ideation to Markup Language
Team
CEO, Product Owner
Stakeholder, Developer
Timeline
2022
My role in five sentences
  • Developed the terminology architecture through four iterations, moving from an action-based model to a preset model.
  • Derived the collapse pattern from DeepL as a UI reference.
  • Made the technical decision to use a ListBox instead of RadioButtons.
  • Wrote and aligned the German UI copy.
  • Carried out the redesign in direct coordination with an international partner company, from the first sketch to the XAML implementation.
For confidentiality reasons, the company name and UI screenshots have been replaced with mockups and generic descriptions in this version. The process, sketches, and design decisions remain unchanged and original.
01 · Context

The purpose of preset-based template selection

The product is a B2B add-in for a presentation software suite. Its template feature updates slides from an outdated corporate design to a new one, automatically adjusting layouts, fonts, and colors. The target audience: individual users and small teams without dedicated design resources.

02 · The Problem

All or Nothing: A Choice Without Guidance

The preset decision sat at a single dialog with no room for error correction. Getting it wrong meant manual rework, exactly the effort the feature was meant to eliminate. I identified two structural issues with the existing design:

The dialog offered no differentiation. Two unnamed options, no description of consequences, no way to judge which fit a given task.

The dialog didn't scale with the underlying logic. Four distinct preset scenarios existed technically, but the two-option UI couldn't represent that complexity without becoming a menu.

Mockup of the old dialog with two radio buttons, without a description of the consequences
Before · dialog with two radio buttons (mockup, not the original UI)
03 · Process

Ideation, Iteration, Implementation

The starting point for the redesign was the product decision to use tiles instead of radio buttons to represent the preset options. This idea didn't come from user research but from a marketing consideration, communicated via the CEO and a business partner. The task was to design what the tiles would communicate, how they would differ from each other, and what belonged in the expander — and then implement it in XAML.

1
The four distinct preset scenarios

The first sketch called for four tiles: "Full Adjustment", "Light Adjustment with resize", "Light Adjustment without resize", and "Custom Adjustment". The model was complete but too complex for a quick decision.

Hand-drawn sketch on graph paper: four options stacked as a radio button list
First sketch · four preset options with tooltip panel
2
Designing a naming logic

In this first attempt of replacing the "level-of-adjustment" naming logic with more action-based captions, three of out the four captions describe what the user does (action), one describes the result state, and "Update" itself is vague enough to describe both. This breaks Nielsen's "Consistency and Standards" heuristic (Nielsen Norman Group, 10 Usability Heuristics for User Interface Design, 1994).

Hand-drawn sketch on graph paper: four options stacked as a radio button list
First sketch · four preset options with tooltip panel
3
Fixing the inconsistencies

The second iteration called for three tiles: "Full Update", "Resize Only", "Keep Layout".

Hand-drawn sketch on graph paper: four options stacked as a radio button list
The fourth level had the rarest use case. The solution: don't remove it, hide it. Three tiles for the three most common scenarios.

The next iteration shifted towards a goal-oriented perspective: "Apply Template only / Change Template & Cleanup / Ensure Corporate Consistency". It was conceptually a step forward, but too abstract and too close to marketing language.

Naming logic diagram: state the objective, three consistently named options
Naming logic · consistent by design, still discarded for being too close to marketing language
4
Structure: tabs vs. expander

Two variants were developed for the hidden settings: tab navigation and an expander. Tabs were discarded early on, since they suggest equally weighted alternatives. An expander signals: these options exist, but you probably don't need them. The reference was DeepL, whose interface hides rarely used options in a similar way.

Hand-drawn notebook page with wording iterations
Expander structure with three presets and hidden extended settings
5
Naming iteration: spectrum

Iteration 3 tried a spectrum: "Low / Partial / High". The user has to calibrate for themselves what "Partial" means for their content.

Hand-drawn notebook page with UI copy wording and translation notes
UI copy wording · basic, partial, full option sketches
6
Naming iteration: presets

Iteration 4 replaced the spectrum with presets: "Basic / Medium / Full". The user trusts a curated preselection instead of calibrating it themselves. The final naming was finalized in coordination with the product team.

Hand-drawn notebook page with UI copy wording and translation notes
Expander structure with three presets and hidden extended settings
04 · Result

The final UI

"Will be super helpful for all situations."
Feedback from the user test before launch

The prototype was approved internally. The final version carries the structural principle of the design: three named escalation levels with an expander for advanced options. The XAML implementation was a shared effort: window infrastructure was handled by development, while UI content, icons as DataTemplates, layout, and styles were implemented independently.

Mockup of the final dialog with three tiles: Basic, Medium, and Full
After · dialog with three tiles — Basic / Medium / Full — and expander (mockup, not the original UI)

To my knowledge, no formal usability tests were conducted. The result is supported qualitatively: positive sign-off internally and from sales, with the feature in production since release.

For confidentiality reasons, the product name, screenshots, and manual references have been replaced with mockups and generic descriptions in this version. The sketches shown and the design process described remain unchanged and original.

All Projects

To the project overview →