Here’s everything that worked and everything that didn’t, plus our AI strategy going forward.

Almost everyone who we asked about putting AI in our Design System wanted the same thing, “Can we generate UI?”. So, as we set our sights on tools that would allow our users to build with our system, we focused on one main aspect.

An AI interface generator.

Getting there was less straightforward. The focus on preparing our existing assets was far more significant than we could have expected and aside from the AI tools we created, the real work was actually clarifying and aligning all of our work between design, code and documentation (the Design System holy trinity).

The short version

• We restructured component documentation around composition: templates, prop tables, value examples.
• Packaged all assets in an AI skill, with a clearly defined interface creation process and strong guardrails.
• Avoided training models or DESIGN.md files, as neither gave reliable outputs using the system.

Here’s how we got there and what our setup is.

What didn’t work

We started off with the most popular approaches: train a dedicated model on existing front-end code (with RAG), create a DESIGN.md file, or build some kind of MCP connection.

The most popular approaches didn’t really work

Model training was expensive and complex, and our initial testing was full of hallucinations. DESIGN.md files weren’t a good approach because we wanted people to use our actual system and components, not just a stylistic impression. MCPs were challenging to build in our high security setting, but we still wanted to test with that kind of connection to our Documentation.

Naturally our first step was to simply feed our existing documentation into an AI model and then see what it could do with it.

In short – not much.

Challenges managing context

Getting our complete documentation into a model’s context was the first challenge. We tried just giving the URLs to a model to read, but that would have been too easy. The model could barely parse anything in our custom docs setup.

We ended up simply uploading all the markdown files with our first prompt. The model immediately told us there were too many files, so we merged everything into one huge .md file.

Using simple, direct questions we assessed how the model accessed information. “How should I use a primary button?”, “What’s the code for default date picker component?”, “What’s the class to apply the colour info?”. Note all the questions just ask for memory access, not any logical understanding on the model’s part.

Although the model could answer most of these basic questions, as soon as we started to step up the complexity or logic of the question the model would fall short. Two things quickly became clear:

1. The model wasn’t reading through all of the documentation
2. Our content wasn’t formatted in a way that AI could actionably use

Documentation formatting problems

Our typical component Documentation format is a mixture of property tables, code examples and usage guidelines (all on the same page). As it happens, this combination isn’t the friendliest for AI to parse. Our models really struggled to follow our guidelines and examples (which are very focused on being understandable to humans!).

We started to try and break up our documentation into code snippets, guidelines and other examples, but the combinations were still unreliable and we were struggling to update our huge single markdown file.

Issues sharing and reusing

Between all of the context management, documentation formatting and testing, we had some more issues to contend with. Sharing the model was challenging as everyone had slightly different AI model access and tooling — between Copilot 365 and GitHub Copilot, plus all of the available models, everything that we tested gave wildly different results.

What worked

If we wanted to achieve our vision of an AI interface builder that used our actual Design System, then what we really needed was a way to consistently share our content and define some guardrails that any AI setup or model could reuse. Here’s what we did.

Formatting asset files

We knew we needed to format our Documentation better, and beginning with our assets (components and foundations) we found a composition-focused structure produced very reliable outputs.

For each of your components, no matter what language, framework or technical structure you have, you should have created a property table at some point. For our system each component is well documented with a basic table:

Then for each property we document all of the available values:

If your components are built in a framework like React or if you’re using Web components then you should have this step as part of your build process, but regardless it’s an easy exercise.

We actually took this time to revisit and align all of our component props (a huge shoutout to Davide Tremolada for powering through all of them!).

For each asset file we set up a structure like so:

A template for the component markup (in this case just plain HTML) and a full prop table. Below the prop table we then give examples of how the component changes with each value:

With this setup any model is able to reference a component and know exactly what to use to compose the code needed.

Guidelines

I’ll keep this one brief. For the guidelines we found it’s best to just give individual files with bulleted lists and code examples where necessary.

# Forms

## Spacing
- 4px spacing under any input label
- By default use 16px between inputs, set either via margin or flex gap.
- Adjust spacing between inputs depending on page density

### Standard spacing example
```html
(example code snippet)
```
## Checkboxes & Radios
- Checkbox and radio groups should be vertical by default with no spacing in between. Only allow horizontal layouts in areas where the rest of the UI is more horizontal (such as filter bars above a table)
- Do not group these components in fieldsets, just use a regular div with any necessary utilities applied

### Standard structure example
```html
(example code snippet)
```
## Layout
- Usually forms should have a vertical layout
- Horizontal layouts are ok for more dense forms
- When using horizontal layouts, align the form fields in a grid using bootstrap flex or grid utilities. Larger inputs could merge two or more columns together but keep the grid where possible.
- When inputs are in a grid, leave empty columns if necessary to align inputs better

SKILLs

So what could bring this all together? Enter SKILLs.

AI skills are instruction files that program custom tasks for AI agents. In skills you can include context files, processes and even scripts to execute. For our Design System interface generator, this was all exactly what we needed.

Our skill was then structured into three major parts:

1. The SKILL.md file itself which contains all of our instructions
2. An assets folder containing each of our component properties and values
3. A guidelines folder with individual guideline files for each component, foundation and design pattern

The Instructions

The SKILL.md has been through the most iterations out of any part of this setup. Here’s a breakdown of the structure that’s worked best.

First, we have the default skill setup with descriptions and prompt hints, before very clearly defining what we want our output to be: HTML interfaces using the SG Design System.

---
name: sgds-build
description: "Prototype interfaces in code using the SG Design System. Use when: building UI prototypes, creating HTML mockups, generating SG Design System layouts from images or descriptions. Accepts images and text prompts, outputs a single copy-pasteable HTML fragment."
argument-hint: "Describe the UI to build or attach a screenshot"
---

# SG Design System Interface Builder

Build HTML interface prototypes using the SG Design System component library. Accept a text description, an image, an existing code snippet or a combination, and produce a single HTML fragment ready to paste into the preview tool.

Next we set up the rules that the model must follow. These are our guardrails. Each was created to cover specific mistakes that the early versions made.

## Output Rules

1. Return **one HTML fragment only** — raw markup starting from the outermost container element.
2. **No** `<!DOCTYPE>`, `<html>`, `<head>`, `<body>`, `<script>`, or `<style>` tags. The preview tool already loads the SG Design System CSS & JS via CDN.
3. The output must be a **self-contained, formatted and copy-pasteable code block** — a user copies the entire response and pastes it directly into the tool.
4. Use only classes and markup patterns from the SG Design System. Do not invent custom CSS or inline styles unless absolutely necessary for layout that the design system does not cover.
5. Use semantic HTML elements where appropriate (`<nav>`, `<main>`, `<section>`, `<header>`, `<footer>`, etc.).
6. Take the user's input at face value. Do not add additional components, states, features or functionality unless described. Unless specified use the most default and simple arrangement/state of components.
7. By default only generate a UI fragment or section, unless a page is specifically requested or the user has defined a UI that needs to be in a page.

We now look at the process, which is really the instructions that the model uses to generate UI. Here are the essential parts of our generation instructions.

1. **Read the user's input.** They will provide a text description, an image, an existing code snippet or a combination. Identify every UI element visible or described (buttons, alerts, badges, forms, navigation, layout sections, etc.), their properties and states and also any layout patterns that can be identified.
2. **Load component references.** Before writing any markup, read the relevant component files in [./assets/](./assets/) for every component you plan to use. Match each UI element to its corresponding asset file and use the documented templates, classes, and prop values exactly.
3. **Follow guidelines.** Read [./guidelines/layouts.md](./guidelines/layouts.md) and apply the documented design patterns and guidelines (grid, containers, spacing, flex utilities) to structure the page. If the input includes HTML code then review the code and adjust the markup to use the correct component templates and classes, and restructure the layout to follow guidelines as needed.
4. **Compose the HTML.** Assemble the full interface as a single HTML fragment, combining the components and layout patterns. Avoid using custom CSS unless absolutely necessary (for page layout that can't be achieved with utilities). 
5. **Review.** Verify every class name and markup pattern traces back to a component reference or guideline. Remove anything that doesn't.
6. **Generate the final HTML fragment.** Produce the final HTML fragment as the output and inform the user if there was anything that you were unable to do and why.

Finally we finish off the skill instructions with references on where to find assets and guideline files, explaining how each of those files is structured and how to reference them. This helped focus the model on relevant sections. At the end we added a useful “Key constraints” section, just to double down on some more guardrails.

## Key Constraints

- **Never guess class names.** If a component or utility class is not documented in `./assets/` or `./guidelines/`, do not use it.
- **Prefer composition.** Build complex UI by combining documented components rather than inventing new patterns.
- **Match the input closely.** When given an image, replicate the layout, component choices, and visual hierarchy as faithfully as possible using available components.
- **Keep it simple.** Use the minimum markup needed. Do not add wrapper elements or classes that serve no purpose.

Testing

Testing was straightforward. We set up a series of target prompts, tried them with different models and then recorded the results. The aim was to try to get as many models as possible to align on the correct layouts.

When there were mistakes, it was usually as simple as updating one of the guideline files or tightening our main instructions in the SKILL.md.

Once we had something stable we shared it widely and started to see what other teams were building with it — everything from trading order tickets to football tournament trackers.

What’s next

Now that our skill is in use we’re focusing on improving accuracy, but also looking at our major Design System user groups and thinking about more assistive creation tools:

• For Designers: generative ideations and design-to-code
• For Developers: documentation reference, linting and production-ready code generation, plus a technical migration tool
• For non-technical consumers: A complete interface builder tool

We’re testing Vercel’s JSON render for even more consistency and also looking to update our documentation in anticipation of an internal MCP, but, first we will attach all of the skill markdown files to our documentation site, plus an llms.txt file with instructions on how to reference our documentation.

Outcomes

The skill works! It’s being updated almost constantly as we find more inconsistencies, but the core component composition is robust. Results no longer depend much on the model: GPT 5.3+ and Opus/Sonnet 4.5+ all return reliable results.

So far multiple projects have used it to build UI that, after our usual review process, is now in production, and Designers and Developers are using the skill to build prototypes and applications.

Almost no matter what we build, the user’s prompt has a huge impact on the quality of the output. Users with existing knowledge of the Design System were able to utilise it a lot more effectively. The ability to communicate intent with the model is an unavoidable weakness, but perhaps we can have the model question the user more and work together with them to create the output.

I’ll end on my usual reminder, make sure that you always prioritise your most important users and most important use cases — no matter what’s popular or what you see other teams doing.

The realities of getting a Design System ready for AI was originally published in Societe Generale Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most discussions about AI in product design today focus on producing things: How quickly can we write requirements? Generate wireframes? Churn out code?

That’s useful, but it’s not where we get the best out of it in the team. After several years working on small and large transformation programmes, I’ve become convinced of one thing: slow delivery is frustrating indeed, however false alignment is even more expensive.

The larger the organisation, the more dangerous a lack of alignment becomes. An unproductive way of using AI can also make it worse. So here’s how I use AI to detect and clear ambiguity before teams start building around it.

The real pain point AI can solve for designers

When I receive a brief, I always start with these questions:

What assumptions are being treated as fact?
Which user groups might be missing?
Which dependencies are implied but not mentioned?
What can invalidate the proposed solution?

There’s nothing revolutionary about these questions. Experienced designers, product managers, and engineers have been asking them for years, the difference now with AI is speed.

Instead of waiting for a meeting with five busy stakeholders to take place, I can test an idea from multiple angles in minutes. The real value here is in identifying questions that haven’t been formally raised yet, to get project teams thinking about them and aligning.

A real story of not detecting misalignment earlier

A couple of months ago, I worked on a migration programme involving at least six complex modules, with a target of full delivery in nine months.

My first reaction? “Nine months? How realistic is that?”

So we did what teams do: reviewed each module, assessed complexity and estimated the effort required. We aligned and agreed to reduce the scope from six modules to four, within the same timeframe.

It felt like progress: the estimates were more realistic, the roadmap looked healthier and the Product team, Engineers, and Sponsors felt reassured. And that’s where I made my mistake:

As work progressed we uncovered workflows that nobody had mentioned before, user scenarios that were entirely missing from the initial scope, on top of some simple journeys that were not included because the process existed only in people’s heads.

And you’ve probably already guessed the result:

🔴 Redesign work
🔴 Replanning due to delays
🔴 Frustration
🔴 Reduced stakeholder confidence
🔴 Tense discussions about ownership and accountability

Looking back, the real problem started months earlier: everyone believed we shared the same understanding when we did not.

The biggest cost was not design or development effort, it was the cost of learning critical information after commitments had already been made.

2 things I do differently now with AI

EXAMPLE 1: DUE DILIGENCE

I recently started to work on a new digitalised workflow. This time I ran the brief through my AI “Challenge the brief” prompt, which looks for missing users, scenarios, and edge cases.

A simple question emerged: what happened to the person who used to perform this step manually? The role was mentioned briefly in the documentation but wasn’t considered part of the scope. What surprised me was that nobody could confidently explain why the role had been excluded, even the Product Owner.

Once we spoke with the right stakeholders, the answer became clear. Had we discovered the issue weeks later, after reviews, approvals, and development work had started, the conversation would have been far more expensive.

Of course, we can never clear up everything upfront in a project, but we can now manage critical assumptions that deserve attention early, before they turn into expensive surprises later on.

EXAMPLE 2: ROUGH DRAFTS

When people see finalised looking screens, it’s all too easy for them to validate without really thinking of the larger picture. Now I prefer to use AI generation the other way around: I purposely generate imperfect starting points to spark discussions.

Recently, I was asked to add five new KPIs to an already dense dashboard. Instead of doing it with AI, I explored different ways users might interpret and organise the information.

When I later reviewed those options with the Product Owner and an end user, they challenged several assumptions and refined the direction, and we ended up making an actionable dashboard. AI didn’t provide the answer, it helped explore ideas quickly for people to challenge them.

Conclusion: even in the age of AI, alignment is still king

Today, I can create and iterate on screens in seconds using agents and design skills. But I’ve learned that speed creates value once the critical assumptions have been challenged and the problem is clearly understood by everyone.

In a large organisation, that understanding is rarely a given. The bigger the programme, the more teams, stakeholders and dependencies become involved, each bringing their own assumptions. Alignment doesn’t happen naturally (unfortunately), it has to be continuously built, challenged and maintained.

Because no matter how powerful AI becomes, alignment remains one of the few things organisations can’t automate.

The big forgotten cost in projects was originally published in Societe Generale Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

As product designers, we are increasingly using AI at work for coding, design and productivity. Yet some of the most popular prompts in the team aren’t technical at all:

Help me write a difficult email.

Make it sound professional.

Challenge my thinking.

AI is incredibly useful. It can help us find the right words and blind spots. But I can’t help wondering: if we increasingly rely on AI for feedback and difficult discussions, what happens to our own communication muscles?

Giving feedback is more than finding the right sentence. It is about understanding context, reading emotional reactions, and adapting in real time. So with Michael PIERRE-DESMONDE, we decided to help the team remember and practice these very human skills.

The issue of having a team who were too kind

When people think about feedback challenges, they usually imagine conflict-heavy environments. I see the opposite in the team: we’re collaborative, empathetic and respectful. People genuinely care about each other and want to maintain positive relationships.

Sounds ideal, right?

Well, not entirely. After a team design presentation, I remember someone confessing to me that the presentation could have been significantly improved. However, they never shared it. They were worried about hurting the presenter’s feelings. Would AI do a better job of dealing with this?

When design critiques become too safe, or people hesitate to challenge decisions they disagree with or hope that AI will pick it up, the concerns that could have been raised directly during a review sometimes resurface later in private conversations. As a result, we miss opportunities to learn and to improve our design craft. And we miss opportunities to strengthen our relationships as well.

Helping people dare again

We needed shared principles simple enough for people to remember them during the middle of a design review, but precise enough to explain why “being nice” wasn’t the same as being helpful.

That’s when we revisited Kim Scott’s Radical Candor framework framework. It provides clear language for identifying common feedback patterns, including a trap that many of us immediately recognized: ruinous empathy.

“I didn’t want to hurt you, so I said nothing.”

Rather than simply presenting the theory, Michael and I organized a team workshop to practice giving feedback using real-life design scenarios and to explore different feedback approaches. As an example, we asked the team to write feedback in the real-life design scenarios below:

• Design review / critique : A designer presents a new UI feature that doesn’t align with accessibility standards.
• Design / dev collaboration: A developer repeatedly ignores design specifications.

After writing feedback proposals in small groups, everyone shared their own and discussed different feedback approaches.

We knew that giving feedback is harder than people think. Many participants believed they were delivering balanced feedback. But others perceived the same feedback as too harsh, too vague, too indirect or not caring enough.

We also collectively realised a few things:

• Culture matters more than being a native speaker: what feels direct to one person may feel aggressive to another. What feels considerate to one person may feel vague to another.
• Great feedback does not always need an audience: sometimes psychological safety means choosing a different setting rather than forcing a public debate. The most effective conversation can happen one-to-one.
• You can vent but keep that version to yourself: at one point during the workshop, a group of participants went off-track and created an “aggressive honesty” box in reaction to feedback that felt too soft 🫢

What’s next? The hard truth about culture change

After the workshop, we were optimistic about the future design critiques. But awareness is not behaviour change. A single workshop can spark reflection, but it did not transform the culture of our team on its own.

That did not stop us! A month later, we introduced a set of supporting tools to help the practice stick. A quick-reference cheat sheet, so people had something to glance at before a review. A Microsoft Copilot prompt that assesses the quality of your draft feedback against Radical Candor principles: it flags where it drifts too soft or too harsh, and explains why, so you get a second pair of (AI) eyes before hitting send. And the CORE structure (Context, Observation, Result, Expected next steps), a simple format we adopted to make praise as specific and actionable as criticism, instead of a generic “thanks for your help.”

Ironically AI became part of the solution. Not as a substitute for communication, but to help practice those skills ourselves. Better products emerge from better conversations, and better conversations require feedback. Even when it is uncomfortable? Especially when it is uncomfortable.

If this resonated, Radical Candor is worth exploring further. Kim Scott, the framework’s creator, writes regularly on the topic on Medium, and you can find the full framework, book, and resources at radicalcandor.com.

This article was co-written with Michael PIERRE-DESMONDE.

Are we forgetting how to give feedback in the age of AI? was originally published in Societe Generale Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

As AI Lead for Societe Generale in the UK, I’ve spent the past year observing how people really use GenAI tools at work, speaking with colleagues across Financing, Compliance, IT and Design. Beyond the hype, I wanted to understand what makes an AI use case truly valuable.

Across these discussions, I discovered a recurring theme: the most valuable use cases are often not the shiniest ones, and usually not talked about a lot in AI conferences or by AI influencers. For the design team, for example it’s not necessarily about vibe-coding. We actually learned to design-in-the-browser and code with our design system before using AI tools. Instead, it’s really more about easing our work from the mundane and boring tasks.

Today, I want to give credit to the mundane, and look at how GenAI changes our approach to work. Let’s see how 3 designers in the team use boring AI.

How Tracy uses AI as her work librarian

Before every design project, we collect a lot of documentation about business context and requirements. In a previous article here we even joked about it: “Did you ever have to digest a 40-page PDF of documentation only to realize afterwards that you just needed to read 2 of them?”

Tracy has found another way to manage this on her projects. With our internal version of ChatGPT, she no longer needs to memorize all the information upfront. Rather, she uses it as a friendly librarian who can recall the information for her. Even better, she can ask for contextualised examples like below:

As Tracy puts it:

“Whenever I have questions I just see it as a companion and ask questions on the go, instead of every time digging back into documents to find answers.“

Similar to how librarians can help us find information (but not write the books), AI can’t replace a missing or ghosting stakeholder on a project. Tracy reminds us in her interview that all the generated work and examples must be checked with her project. There’s no such thing as synthetic stakeholders!

How Davide uses AI as his transcriber

Nowadays, teams are asked to be leaner and leaner. This means that individual designers tend to take notes themselves in research interviews and usability tests. Yet, we can still carry ambitious research projects especially with GenAI tools.

Davide explained to me how he interviewed 20 traders on his own. He couldn’t record them or use a transcription tool, so he ended up with written notes all over the place in English and Italian (as Davide is Italian and some traders too). Instead of spending hours sorting his notes, he used his GenAI chat to synthesise the main pain points per interviewee and then across all his interviews.

As Davide puts it:

“I saved around 3-4 hours of work. I checked the results against my original notes and it gave me a very good base to start the workshop with the product team.”

Indeed AI transcription is skilled at summarising and sorting unstructured data, but it can’t make relevant decisions and does not replace the design workshops with business product owners, front-end and back-end developers where everyone brings in their context knowledge.

I attended a conference recently where 2 researchers shared that they ran a diary study in parallel with an AI startup. The AI report was instant but shockingly shallow, not because the model was weak, but because it lacked context about the product and company strategy.

How Henry uses AI as his knowledge spellcaster

Maybe the best example of the mundane AI usage is Henry’s use case. He shared with me how he quickly invokes knowledge on the go, during project meeting or when doing focused design work. This replaces a traditional Google research session.

In the example here, he was in a project meeting and just quickly hit ⊞ + C to open a floating Copilot Chat to confirm some CSS properties:

As he puts it:

“I’m really using it for not massive workflows, but day-to-day tasks. But what it is, it’s maybe lots and lots and lots of 1 to 5 min time savers.”

And here again, there are some points of attention. Unlike an ordinary web search, we know that GenAI answers are probabilistic. If you need to do a math formula, use Excel and not GenAI. Learning to work with probabilistic answers is definitely something we need to get more comfortable with.

Conclusion, for now

In the company we often differentiate our projects between “Run The Bank” and “Change The Bank” (our terms for operational vs transformational projects). “Run” tends to be repetitive and well suited to be formalised into operational procedures. “Change” requires a lot more context and nuance to agree on what needs to be done and how to do it.

Using GenAI as work librarian, transcriber and knowledge spellcaster has made the “Run” work more efficient, and maybe a little more fun for Tracy, Davide and Henry. Ironically, it has also created more space for their expertise: we need experts who know where it makes sense to use GenAI, where it doesn’t, and when it becomes reckless. Especially when dealing with “Change” projects.

Have you come across any boring AI use case with big impacts? Or found that shiny AI doesn’t deliver on its promise?

Thanks Tracy Leung, Davide Tremolada and Henry Daggett for sharing their examples with us.

Boring AI: how GenAI is changing our everyday work was originally published in Societe Generale Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the world of finance, entering monetary amounts is a daily ritual.

Yet, until 2023, our design system at Societe Generale CIB lacked a unified component for this essential task. We wanted to cover it, but projects weren’t really asking for it. They were just using our number input and adding functionalities themselves. We wanted to unify the input experience, but still no real project use case to prioritize.

Finally, the feature request arrived from a large project (using our design system’s contribution system): an input field that could format numbers for readability, display the currency next to it, and offer shortcuts for quickly entering large amounts like thousands and millions.

I was already working on our currency picker component, so we agreed to add it to my scope. Based on a quick analysis, we thought that this was essentially just a simple number field with formatting and alignment features. Spoiler: it wasn’t.

Turns out, creating a new component is one of the most deceptively complex things. This is the story of our humble money input.

Act 1 — Sailing off

Like for all component studies, first I looked for existing projects that had already implemented and used amount inputs, specifically looking to cover a range from novice users with simple needs to professional experts who work daily on credit allocation or trade execution.

I identified these four major features:

Formatting: When amounts get large, raw numbers become hard to parse at a glance. Grouping digits into chunks makes it faster for the brain to scan and compare numbers and will reduce misreading errors.

Keyboard shortcuts: For users entering amounts frequently, speed matters. A common pattern is allowing K, M, and B to expand into thousands, millions, and billions. Simple, but powerful (and great for keyboard navigation and accessibility).

Currency: Displaying the currency next to the amount was another key requirement. We already have an append/prepend feature on our inputs, so we’ll just reuse it!

Alignment: Like currency position, number alignment varies across services. While alignment often follows locale conventions, some projects require specific rules. For example, in tables, right-aligning numbers is essential to keep units aligned and comparisons easy.

Act 2 — Complexity emerges from the waters

The complexity layers revealed themselves quickly. As I tried to converge on one solution, a flood of interaction and user experience questions surfaced.

To make the component truly flexible and adapt to different contexts, we needed to introduce several configurable options, decide how to name them and what the expected values are.

For example, displaying a currency could be a simple true/false property. But then, how should it appear? As a symbol (e.g. €), an ISO code (EUR), or the full name (Euro)? With nearly 200 currencies in use, maintaining a full list would be unrealistic.

Our solution was to add custom names for currencies as another free text property. Nothing specified? No currency displayed. Otherwise projects can just use whatever they want.

By mid-2023, after several iterations, we had a first version: an input that cleanly displays amounts with an optional currency label, flexible positioning of amount and currency and shortcuts to write large numbers.

We finally released the first version in September 2023, and it felt like a moment to breathe.

Act 3—The fleet of tickets

Post release, people started using it and adoption grew well. And with that, new fresh requirements and unexpected conflicts began to surface.

One that really stood out was the decimal challenge:

“I want to choose the number of decimals to display”.

As with everything with this component, sounds like an easy enough request. Teams wanted to control how many decimals were shown without altering the actual input value. For example, if a number had no decimals, it should still display two zeros (e.g. 10 becomes 10.00). If it had more than two decimals, the extra digits should be truncated or rounded visually (e.g. 10.1234 becomes 10.12).

But different currencies follow different currency-specific standards for decimals. This sparked long discussions between us and with projects, not only about truncation versus rounding and their operational impacts, but also about naming the property. Some projects wanted to prevent users from typing more than n decimals, others wanted to allow all decimals but only display a certain number when the input loses focus…

Eventually, we split it in two properties: max-decimals-displayed for visual truncate of decimals, and max-decimals for a classic limitation.

Phew, one issue closed. Onto the next. And the next.

Conclusion

A year and 11 updates later, the component has reached a remarkable milestone: no new issues have been raised in three months! We’ve had great contributions from other teams.

This component is now used daily in production across our products, and it has significantly streamlined the experience of inputting money amounts.

I learned from this odyssey that designing for scale means embracing true complexity, messy iterations and real collaboration.

A component is never truly “done” — it evolves with its ecosystem, adapting to new needs and constraints.

As I write this, we’re refactoring our components, moving from StencilJS Web Components to a React-first setup. The odyssey continues ⛵⛵⛵

Replay — Design Systems Paris

The unexpected odyssey of building a money input was originally published in Societe Generale Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I received this feedback after what I thought was a successful product scoping call, I was in disbelief. Up to that point, I never had issues with one-hour scoping meetings or getting users to answer lengthy interviews. Actually, sometimes I had to be the one to remind them that we had overstepped the timing of our meeting, and that I was needed elsewhere (like, lunch 🍝).

It’s also what I learnt in my design training and from experience. It worked on previous projects. So why not here?

Introducing… the Extremely Busy People (EXBP)

As my career at Societe Generale progressed, I took over more and more complex projects. Eventually, I came in direct contact with a new group of people I wasn’t used to interacting with — the extremely busy people (or EXBP — as we love acronyms in this sector). Who are they?

Imagine people constantly looking at four wide screens (two horizontal, two vertical — plus an additional laptop) in front of them. Any sort of data constantly updates and flickers. At the same time they are receiving calls from clients asking them to price products or perform trades, while also working on new requests coming from sales, who are talking with other clients, with additional pressing needs.

When you work with these people, you cannot ignore that they are extremely busy.

To collaborate successfully, I tried many things and developed new working strategies. Here they are.

1. Be flexible and schedule things… last minute. Yes, really!

Counterintuitively, planning days or weeks in advance does not really work because EXBPs’ free time can disappear in seconds, for a variety of reasons: client calls, wrong values that blink on the screen, sudden acts of war that destabilise the markets, etc. Any meeting proposal above 30 minutes is often regarded as inefficient and probably declined (or ignored).

Since availability is uncertain, you need to meet them on their turf (their availability, whenever that is). Your planning needs to be flexible.

• Contact them on the same day or just the day before. Use 30-min slots and have a few additional free slots in your calendar, to juggle their availability.
• A short, direct message is the best: who you are, why you are writing them, what you need from them. You will be surprised that this very direct, emotionless message is often met with a clear and fast response. Efficiency is the new kindness (beware: only with EXBP, don’t try this at home!).
• Let them know that you can reschedule. This will give them peace of mind and shows you care about their priorities as well. And if some of them are caught in emergencies again and again, just move on — work with who’s available.

I recently ran 20+ interviews with EXBP across various continents. All the meeting invites sent were for 15-minute slots — everybody always accepted. And, surprise, we often talked more than that. But it was always their decision to give more time, and this made them more willing to do so.

2. Streamline everything and monitor attention levels

Two minutes into an interview with a trader at their desk, I could see their eyes start to move and gaze up and down… top-left, bottom-right. The focus had shifted to data displayed on their multiple screens. The answers became laconic — I was disappearing from their cone of attention. I had to quickly bring back their attention by mentioning the last pain point they had shared, before it was too late.

To avoid this happening, there are a few simple steps:

• Prepare a list of questions or tasks (ex. for user interviews or usability testing), then make it shorter. Then do it again. Plan for the essential and keep the rest for the end, only if they are willing to engage more.
• Introduce yourself and the context, but fast. A short “Hello, thank you for taking the time to join this session” is enough.
• Mind the tone of their voice, you will notice very quickly if your questions start to be regarded as an invaluable loss of precious time.

In the little time you have (which might be less than what was initially agreed), you need to be able to extract as much key information as you can — while keeping their attention.

3. Use realistic data and realistic prototypes

In a previous project I had prepared a usual complex data-filled prototype. During the introduction of the first usability testing session, I explained that the data displayed was just an example and the prototype was made of static images. Still, I spent 80% of the time answering questions about incorrect data and numbers, and how specific interactions would work once “in production”.

To focus on meaningful feedback and minimise distractions, here are a few recommended practices you can follow:

• Display data that makes sense. For this type of user, data is everything. If it’s not realistic (ex. you used a fake client name such as “Cake maker 01”, or you used random numbers in your inputs) they will become confused, they will ask about it and you will not be able to focus on the actual feedback you need.
• Show interactive coded prototypes, if you can. I don’t want to open the discussion about whether designers should code, but coded prototypes behave exactly like the web version of the tool. They are fast, with no latency no matter how many interactions you add. Every element is clickable and realistic, giving users a real feeling of what they would encounter when in production.

Following these exact tips, after that call ended I quickly scheduled a meeting with the Product Owner. We reviewed the data and updated it to create a realistic example without any inconsistencies. In the next testing session, we finally focused only on the layout and main actions, with no questions about numbers.

EXBPs have an eagle eye for details, spotting inconsistencies even better than a designer. Simply put, you need to be able to show them something very realistic and easy to access.

Conclusion: I love working with busy people now

You might think that working on this kind of projects is challenging. On the contrary — this is my favourite type of project. EXBP are in fact the most attentive and detail-driven users you will work with, and interacting with them offers many opportunities for professional growth:

• You can count on them to spot problems in your design, in the data you used and in your information hierarchy.
• They are (mostly) direct. If they think something doesn’t work, they will tell you right away. The classical speech about not holding back feedback is not needed. You will receive precise, explicit feedback by default.
• They want to get things done. As they can rely on you to make things streamlined, you can rely on them to make efficient use of your time.

If you too are a product designer working in high-pressure environments, especially with extremely busy end users, I would love to hear your tactics. Drop a comment or connect on LinkedIn!

How I adapted my design approach for extremely busy people was originally published in Societe Generale Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

In recruiting, my bottom line was my bottom line, nuance was out the window. If you are a trader your P&L sheet tells the whole story. You know where you stand.

Now I find myself as a designer in a world of structured nuance. There are core principles, but what is considered successful design is different in each business. At Societe Generale success is often measured at a project level, sometimes using metrics and variations of the Google HEART framework.

This makes tracking individual success tricky… great. Maybe I need to set a minimum auto-layouts count? Or maybe start counting the amount of interactions each prototype has? Everyone seemed to get it, but I didn’t, Maybe it’s just post KPI disorder but I needed my numbers to know if I was doing well.

This led me to ask my team: what does individual success look like for a designer here, and how is it measured? Here’s what they shared.

Evidences of alignment in your project

Project alignment is a marker that’s often overlooked but a factor in achieving success on projects. Did we do what we said we’d do? If yes? Success.

Making sure the project team is aligned on outcomes like deliverables, timelines, goals etc is an easy way to track your progress and contribution. When the whole team is pulling in the same direction and you’re doing your part- that’s success.

Your curiosity leading to solving non UX issues

You can’t know everything, but what’s your appetite for filling your gaps in knowledge and sharing your findings?

Curiosity adds value. Say you’re thrown into a project full of jargon, unfamiliar concepts, and unclear solutions. Your job is to lean on the team’s knowledge, dig into external benchmarks, and build up your own understanding.

Sometimes this kind of curiosity helps you discover non UX issues within your projects. Maybe the MVP scope is not as accurate as thought. Or maybe users actually don’t need more data. This proactive approach not only fills gaps but also demonstrates impact and growth.

Feedback (of course)

Feedback is a double-edged sword; good feedback can boost your confidence, but negative feedback can either motivate you or kill your confidence.

Developing a healthy relationship with feedback is key. It helps you see your blind spots, understand what the team needs from you, and adapt. Acting on feedback, and staying open to it is a strong signal of growth and success.

Just remember to take feedback with a pinch of salt. It can be biased or weighted depending on different levels of expectation, personal preference, or even the weather.

Evidence of trust and being asked your opinion

This is probably the most nuanced point the team mentioned. Some people referred to it directly, but others used terms like accountability, reliability etc. But it all comes down to the same thing:

Do people trust you to get the job done? And more importantly do you trust yourself to get the work done?

Trust shows up in small but meaningful ways. Being given more responsibility, being asked for your input, being pulled onto new projects - these are all evidence of trust. Your own confidence is part of it too. Trust in all forms is a powerful indicator of your success.

In Conclusion

While we can track metrics like OKRs, there’s no magic solution to cure my post-KPI disorder. In design, success isn’t as clear-cut as an individual commission tracker or a P&L sheet; it’s fundamentally qualitative.

That said, there’s something personal to keep track of: your reputation. Are you viewed as an expert? If not, focus on building trust, managing feedback, nurturing your curiosity, and aligning with objectives until you become that person.

Acknowledgements: I’d like to thank the the team of success experts I spoke to provide insight on this riveting topic, Davide Tremolada, Andrea Rekalidis, Zé Monteiro , Tracy Leung, Morgane Peng, Michael PIERRE-DESMONDE

Measuring success in design, a career switchers perspective was originally published in Societe Generale Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Remember that scene in “Inside Out” where emotions are running around inside Riley’s head? Our brains do something surprisingly similar when we interact with AI tools, though we rarely notice it happening.

Fascinated by this, I went down a rabbit hole during my master’s in Human-Computer Interaction Design leading me to research and discover something unexpected. There’s actually a scientific framework that explains what’s going on — and more importantly, how we can design better AI experiences by understanding what’s happening in our users’ minds.

As a Product Designer now at Societe Generale CIB, I can see these concepts come alive in our design projects. So here’s what we’ve discovered while putting these ideas into practice:

The not-so-simple dance of human and AI

Let’s start with what seems like a simple process. You are sitting in front of ChatGPT, ready to tackle a task. The steps look straightforward enough:

1. Open ChatGPT
2. Formulate your first prompt
3. Get an output
4. Iterate until happy
5. Continue with your workflow

Simple enough, right? Well…not exactly. Sometimes even the simplest requests can turn into frustrations. Just look at this poor soul trying to get ChatGPT to draw a circle:

Here’s where it gets interesting. What’s actually happening in your brain during these “simple” interactions is far more complex. There’s an entire layer of metacognitive processing happening that we don’t usually think about.

Wait…Meta-what now?

Metacognition — it’s thinking about your own thinking.

In simpler terms, metacognition is the brain’s backstage process that monitors, evaluates, and controls how we solve problems and process information. Think of it as having a tiny control room in your head that’s constantly asking “How am I doing?” and “Should I try a different approach?”

The four metacognitive challenges of AI

When using AI tools like ChatGPT, our brains face these key metacognitive hurdles:

1. Self-Awareness: Using AI isn’t just about knowing what you want — it’s about being aware of how you think about what you want. With AI, you must explicitly recognise and communicate these mental processes. This heightened self-awareness isn’t always intuitive.
2. Task Decomposition: AI often needs tasks broken down into specific sub-tasks to be effective. For instance, instead of asking AI to “improve my presentation,” you might need to break it down into “condense each bullet point,” “make the tone more conversational,” and “add transitions between slides.”
3. Metacognitive Flexibility: when AI outputs miss the mark (and it will), you need to flexibly adapt your approach. Should you rephrase your prompt, restructure, start over, or tweak parameters? This is challenging especially given AI’s non-deterministic nature — meaning the same prompt might give different results each time.
4. Confidence Adjustment: the eternal question: when things go wrong, is it you or the AI? Having a well-calibrated sense of your prompting and evaluation abilities against the AI’s capabilities is crucial.

Introducing the “Designer’s Seesaw”

What does this mean for us designers who design for AI? Building on Microsoft Research’s framework, our job boils down to two key strategies:

• Enhancing users’ metacognitive abilities (helping them perform their metacognition better)
• Reducing AI’s metacognitive demands (making the tool less mentally taxing)

I picture this as a seesaw:

At Societe Generale CIB, our design team has been actually tackling these challenges as more AI use cases emerge, often without realising we’ve been using cognitive science! Here are two examples of using the “Designers’ Seesaw” from our recent projects.

Example 1: providing interactive support to enhance self-awareness

MyCases is a digital platform used to track and manage both client and internal requests and incidents. In this design concept by one of our designers, AI detects potentially inappropriate content in users’ emails and provides warning feedback in a modal:

How can we analyse it with the “Designer’s Seesaw” metaphor?

This design prompts users to reflect on their intentions and communication style through interactive and contextual feedback. Rather than just flagging issues, the AI acts as a thoughtful guide that promotes self-awareness and self-evaluation.

This approach helps users develop stronger metacognitive abilities as they become more conscious of their writing choices over time (sometimes we all need a moment to think twice!).

Example 2: adding explainability to reduce metacognitive load

Document assistant is a service that helps users process and manage various documents — from classifying and splitting them into categories to extracting and validating data. In this feature, the tool helps users extract data automatically from annual reports. One of our designers introduced a visual confidence indicator that shows how certain the AI is about the extracted data with this design:

How can we analyse it with the “Designer’s Seesaw” metaphor?

This design serves two purposes:

• Display AI’s confidence levels to guide users toward finding the sweet spot between trusting themselves and AI. Instead of either doubting themselves too much (and over-relying on AI) or being overconfident (and ignoring AI’s help), users can develop a balanced approach. This helps them adjust their self-confidence for better output evaluation.
• Guide users’ attention to where it’s needed most. By highlighting which parts need manual verification, it makes the whole review process more flexible and intuitive — you can quickly adapt your approach based on where the AI is less confident (thus supporting metacognitive flexibility).

This confidence indicator works as a trust calibrator — crucial in high-stakes banking environments like ours. It gently reminds users that AI can make mistakes too, preventing blind over-reliance while still keeping users engaged when occasional errors occur.

Less mental gymnastics, more efficient work.

Bridging minds and machines through design

As AI continues to evolve faster than my coffee consumption during design reviews, we need more designers who understand these metacognitive challenges. It’s not just about making AI tools that work — it’s about making them work with how our brains work.

Here’s what I’ve learned through this journey:

• Think beyond interface design to metacognitive design for AI
• Create AI experiences that work in harmony with human minds

Want to start designing better AI experiences? Remember that you’re designing for both the conscious and metacognitive aspects of user interaction. Success lies in supporting both.

Special thanks to the Microsoft Research team (Tankelevitch, Kewenig, et al., 2024) whose paper “The Metacognitive Demands and Opportunities of Generative AI” provided the foundation for this article’s framework. And to all the designers who, like me, have ever stared at an AI tool and thought, “There has to be a better way!”

Another special thanks to Morgane Peng (and Claude) who let me borrow her brain cells for this article — sometimes one brain isn’t enough to think about thinking! 🧠

Thinking about thinking: designing AI for the human mind was originally published in Societe Generale Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a designer, you may be required to work on the scope of a project which is nothing more than a set of priorities wrongly presented as a “Minimum Viable Product”.

The MVP concept can be misused to cut out anything that appears too complex or for including an excess of features to guarantee user satisfaction. The main victim of this is the user experience, which will subsequently be defined by the wrong rationales.

As a last line of defense before starting development, designers should have good reflexes to identify these situations. It’s even better when you can help re-establish consistency on a product.

One could say it is not the designer’s role to frame product prioritization. Although this is not completely wrong, as designers, being user-centric means caring about the product’s outcome, and therefore helping get it back on track when misconception risks are detected. We could even go further and act as product design facilitators.

Let me develop this further.

A fake MVP can hide a lack of maturity on a project which is not ready for the design process. When there is pressure to come up with a good idea during the UX phase, product owners can rush through the scoping phase, leaving designers without clear documentation to start.

Before falling into the trap of prototyping based on various uncertainties, first you should refocus the project onto Product Framing and User Research.

1. Identify the uncertain elements

An issue often observed with MVP’s is when they contain elements whose design or technical feasibility are uncertain. You should be able to establish how confident project stakeholders are on what the business wants to deliver.

To do this, you can carry out an exercise using the assumption matrix. Define each element based on two factors. First, confidence: is the evidence for it strong or weak. Second, priority: is it important or not. Then use the matrix to place each item where they lie along the x and y axis.

The area which is both important and has strong evidence will likely become part of the MVP. The zone which is not important and has weak evidence will likely be dropped from the first version.

The red zone, corresponding to the important stories but with weak evidence, will be the most sensitive. These will require the project stakeholders to launch further studies that may delay delivery if the content cannot be dropped from the first version or split into smaller feasible stories.

I worked on an application whose product owner exposed a lot of “must-have” features to deliver with a strict timeline. When starting the design process, I felt doubts on development side regarding the feasibility of some features. Also considering my design assumptions, I convinced the project to carry out an assumption matrix workshop.

As expected, this exercise clarified priorities and highlighted the need for further analysis on uncertain items. At the end, the PO faced a real dilemma: choosing between delaying the MVP to include all his initial priorities, or reducing its scope which was too big. The scope has been finally reduced.

2. Split and distribute value across the whole experience

Story mapping can help maximise user value of the initial solution. It helps to prioritise user stories, ensuring that the most important features are addressed first, keeping the focus on the end-users.

It’s a very powerful concept if it’s used in collaboration with business and technical experts. It also has to be used at the right time, ideally after defining user flows and wireframes, to help stakeholders have an accurate view on the product.

We break the map down into thematic sections based on the different stages of the journey. This ensures features will be prioritised across the whole user experience.

Representing the different versions visually allows us to easily identify prioritisation conflicts. For example, when an item has been prioritised in version 1, but is dependent on an item placed in version 2, it will probably be dropped from the MVP.

When it comes to splitting the product, if the first version doesn’t bring any value to users, then don’t plan to deliver it. Either delay it so that you can add the missing values. Or review your slicing in order to be more accurate in the value you’re bringing without being forced to deliver too big an MVP.

Be careful not to over-anticipate the content of future versions. The MVP is the most essential, and all subsequent versions will be confirmed by lessons learnt from real usage.

I started a client portal project with a detailed scoping document, including a pre-defined MVP based on design thinking concepts. Presented in an Excel file, project stakeholders didn’t understand that the sum of these features listed did not equal a consistent product but was simply a features wish list.

Starting the user flows, the product owner quickly realised that their MVP version was outdated and required additional features and screens. After validating the wireframes , we conducted a story mapping workshop to refine our MVP, focusing on key user paths. The workshop led to a much more consistent MVP, facilitating final design work and clear communication with all stakeholders.

I got good feedback on the story mapping exercise, mainly from IT teams who regretted not having it earlier to avoid useless studies and pricing work.

3. Review your User Research

If no value is clearly identified in your MVP, you should put the design work on pause and refocus on the value proposal with your project stakeholders. When elements such as personas or user flows are neglected or even absent, it is likely the project won’t be targeted at solving the real problem.

These issues, which can be spotted at different steps in the design process, challenge the product owner if they have a certain solution they want you to provide. Whilst you don’t want to find these issues during usability testing, it’s still not too late fix them.

Don’t hesitate to refine the basic User Research scoping set with your stakeholders. It can help to reveal if the initial user research exercises were not completely understood or if you’ve missed something on the user needs.

I worked on a document exchange service with customisable security levels. Relying on the scoping set provided, I start designing without being challenged too much by the product owner. However, during usability testing, a key user revealed that the proposed solution was useless because it did not work with external clients, which represented 90% of their interactions…

The PO prioritised only the internal perimeter which was easier to develop. Not being able to readjust our product on time, we delivered the “MVP” as designed, knowing it wouldn’t fully meet user needs until future iterations.

4. Review your learning plan

Before I became familiar with the concepts of UX metrics, I used to rely mainly on the business KPIs provided by the project. I then understood that the level of new users onboarded, or the increase of the Net Business Income was not always synonymous with a good user experience.

On UX projects, we now push product owners to think about the objectives they want to achieve by contributing to a design process. These objectives can be related to Adoption, Engagement or Retention and they are key in identifying the value brought by the design approach. The signals and metrics you’ll associate to the objectives allow you to measure the success of the MVP.

Without this sort of learning plan, you won’t know with accuracy if your goals are being achieved and what adjustments are needed to improve the user experience. Make sure the plan is established before going too far with your design work.

If the project team is not willing to invest much time on it, propose using at least basic metric indicators to measure adoption and engagement on proposed features. This will help to frame the MVP priorities by focusing on usage that brings you closer to achieving the project’s objectives. It will also prevent working on unclear priorities after you deliver the MVP.

Don’t hesitate to explore documentation on Google HEART framework if you want to learn more about measuring user experience.

I’d been asked to work on the web analytics for an application whose marketing team complained about low subscriptions rate. The project delivered the MVP while being totally blind to metrics. Once accessing the analytics, they were lost in a mass of data they didn’t know how to figure out.

By defining a conversion objective, they were now able to raise relevant questions about user profiles, traffic sources, impacts of marketing campaign… This allowed us to isolate key metrics to track where the experience was broken. This finally led to adjusting the screens to better place these subscription options in user paths.

5. Proof-of-concepts

If it’s too complex to launch the previous reframing phases with your project, you can help to visualise better the targeted solution.

Ideally this should be done through wireframes. However, if this is not enough, you may need to go a little bit further in a proof-of-concept phase and reflect deeper on how the future solution can be materialized. By seeing screens, features, data , buttons, filters… products owners and developers can better measure the costs and stakes of developing a solution and the gap between what they wish for and what is feasible in the short-term.

As the goal is to help projects take a step forward with their solution, don’t be too picky on the prototype details. High-fidelity prototypes should only be done for the confirmed MVP experience, when considerations of functionality, technicality and design are certain. For the future targeted elements, wireframes or proof of concepts often suffice to visualise the concepts.

A colleague initiated a design process focusing on a single business use case considered an “MVP”. The use case represented was the most frequent faced by users, so the product owner thought it would provide the most essential value of the product.

Due to delivery constraints, they didn’t want to invest on user research, assuming the first use case could be easily replicated across other business areas. Anyway, to ensure product scalability my colleague proposed proof-of-concept screens, illustrating the solution’s efficiency beyond first perimeter.

These screens exposed a global user experience that they had to consider in order to reach their goals… This helped a lot on the prototype iterations, allowing discussions about value, scalability, and feasibility considerations, that finally ended up with a much better consistent MVP version.

Conclusion

I have uncovered several ways to help avoid your product starting out with a bad structure based on a fake MVP.

My main advice is to focus on Product Framing and User Research practices while staying agile in your approach to consider your company’s and project’s context. Don’t hesitate to go directly to proof-of-concept screens if you feel this is the most appropriate solution to unblock the situation.

In the end, if it’s established that the product design is at risk, take advantage of your perspective as a designer to be persuasive and convince project stakeholders to adjust their strategy.

Thanks for reading! Don’t hesitate to drop a comment and share your feedback.

Additional editors: Honor Pattisson and Morgane Peng

This article concludes a series on Minimum Viable Products, which started with the publication ‘How to Unmask fake MVP during the design process’.

What to do when a fake MVP is unmasked? was originally published in Societe Generale Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Given my experience as a designer and former product owner, I have a different perspective on agile methodologies in product design… While the benefits of agility are in theory undeniable, in practice, this term is sometimes misused. I’m thinking especially of those unfinished solutions incorrectly labeled as “MVPs” (Minimum Viable Products).

These fake MVPs frequently emerge due to time and budget constraints which, in turn, pressurise project owners to deliver only what they consider to be essential for the product. The problem is that the rationales behind the priorities are not user-centric, increasing the risk of misusage and costly rework in the future.

Having frequently encountered this issue, I started to help other designers in the team to identify fake MVPs, and now I’m sharing it here with examples from real-life projects.

Evolution of the concept of MVP

First, let’s summarize what a true MVP is. It represents the first usable version of a solution, designed to quickly validate key assumptions with final users and to guide future product iterations.

There was a time it was thought usability perspectives could be omitted from the MVP. It was considered that the value of a product was mainly determined by the count of features deployed. First, release the functional backlog, fix the bugs, then improve the performance … ok now we can talk about your UX finishes.

Today, it is commonly understood that Product owners, IT experts and designers have to collaborate to shape the MVP scope, taking into account user-centric insights. This paves the way for continuous improvement, bringing the right value expected by users, and enabling learning from user feedback and web analytics.

Let’s go now to the crucial question: how to differentiate a fake MVP from a real one? There are 6 clear signs I recommend you look out for.

1. Too big

Believing that an MVP is too big to fail is a common mistake. A product that contains too many features doesn’t align with the “Minimum” concept of an MVP. The aim is to provide essential user value and then learn from their usage. As a designer, it is essential to remind the project to not be overly ambitious with their MVP content.

I had to work on a very large project with several features promised to users before the design process had even started. Instead of studying the real usage of users, the project chose an ‘all or nothing’ approach, leading to more people than expected having to commit to the project.

As a result, basic metrics showed that users didn’t connect to the service, even those who had been presented the initial service proposal. It was difficult to understand exactly why adoption was not a success. If we had focused on a smaller number of features, this would have given us the time to get users’ feedback as early as possible, and potentially adjust our priorities to answer their real needs, rather than over-anticipating their usage.

2. Technical infeasibility

An MVP defined without considering technical feasibility cannot be taken seriously. If a project rushes to the development stage, without analysing it’s feasibility, this can result in delays if features are judged unfeasible only too late. A consistent MVP has to be validated by key technical stakeholders, by gathering their feedback before committing to development. For big projects, the involvement of technical architects can be crucial in assessing overall product viability.

Once I worked on a project aiming to connect a telephony software to a ticketing tool. We advanced on the design process, relying on technical capabilities that had not been fully checked with all IT stakeholders.

When presenting our prototypes, one IT guy raised his hand to express that our free telephony licence couldn’t allow an API plug with our application, so we needed to pay a very costly licence which was out of project’s budget. In the end, we had to completely rework the experience, dropping most of the features designed and the overall process taking longer than anticipated.

3. Lack of scalability

If the product version seems locked into a set of features that don’t consider future user needs, it can prevent it from growing properly. A product’s evolution depends a lot on its starting plan and testing how people use it. This could mean adding things that weren’t in the original plan. To avoid disrupting what’s already been put in place, don’t limit the design thinking to just the initial use cases.

The MVP should definitely take into account budget matters when launching a product. Not having a reliable and scalable foundation for the version can generate costly adjustment when it comes to adding new features.

I worked on a service initially built without UX work and users were no longer satisfied with it. The issue was that the new design proposed was based on the exact same APIs as the original service, which limited the ability to really rework the user experience.

Initially, users were pleased to have a new, more user-friendly UI. However, complaints started to come in when their needs were being systematically rejected due to technical infeasibility. In fact, the real problem was due to the scalability of the product. It’s legacy backend structure had to be revamped for what appeared basic user requests (e.g., adding a navigation menu, offering a search bar with decent loading time, enabling multi-selection…etc). We had to risk disrupting a service used by thousands of users to perform this structural review.

4. No value for users

It can happen that a project’s priorities are based on timeline considerations rather than actual user needs. The focus is on what can be developed without too much complexity. This can result in a useless product version; one that does not align to what users want and fails to have the expected value.

During the development phase, Product Owners can be under pressure to meet deadlines. However, they should not challenge the value of the MVP and try to remove features to catch up with timelines. Another bad practice is to drop UX/UI issues identified during testing, considering them as issues to be fixed in the backlog later on.

On an application I worked on, we needed to add a quick preview feature. Despite knowing that users would prefer an optional panel on the side, the product owner opted for a minimalist version to expedite release.

This led to users complaining that they still needed the ability to close the panel that was now being displayed permanently! This finally generated a lot of noise and last-minute changes in the development cycle. Delaying the release by one sprint would have prevented the issue.

5. Not defined at the right time with the right stakeholders

Determining the MVP scope at the optimal time is key. An MVP defined before the product’s design phase cannot be called an MVP. If it’s normal to anticipate the first product priorities at an early stage, packaging them into a consistent version without the design output shouldn’t be doable.

Pay also attention to the people involved in defining the MVP. Prioritizing a product should not only consider the value it brings to users, but also the complexity of the involved features. Thus technical and design feedback are essential to estimate the confidence level in functionalities.

I worked on a project where the MVP had been defined by high-level sponsors and project managers that would not be part of the final design process team. They basically provided a set of priorities without even knowing the design outputs to the solution.

This created a bias for the product owner, who had to try to stick to these while participating in the design phase. The sponsors hadn’t considered that several technical elements would be costly to implement and would limit the list of possible features they wished for in their “MVP”.

6. No learning plan

A product version can’t claim to be an MVP if there’s no learning plan in place. Targeted metrics are needed to understand user interactions with the product, validate or reject assumptions and make necessary adjustments. The absence of metrics must be considered as a warning sign to challenge the product.

Be careful with projects that plan their product roadmap and sprints too early. Projects must employ agility with caution, to ensure they don’t fall into excessive formalism and over-anticipating product versions. Again, this could come at the expense of user feedback, which is crucial for the product’s life and establishing the right priorities.

I worked on a project with a big agile framing, where IT developers were asked to commit to features early on to ensure they could be delivered continuously in the future.

The main problem with this was that we didn’t have time to analyse the usage after the first delivery. There were no defined metrics to verify the experience proposed. This meant a lot of assumptions had to be made from the basic usage statistics, which showed a low level of connection to the application.

Wrapping up

When feeling doubts about your MVP, take a step back from your project before acting and ask yourself the following questions:

• Is the MVP too big?
• Are there technical feasibility points that must be addressed?
• Does it lack scalability for future growth?
• Will users really find value in the proposed version?
• Was it defined in collaboration with the right stakeholders at the right time?
• Is there a clear learning plan in place to continuously improve?

Beyond the MVP, these signs can sometimes reveal projects not mature enough to start a design process. This doesn’t directly call into question the product value proposal, but rather a product framing that needs to be reinforced before going ahead. As designers, we have opportunity to help Product Owners building a target vision and better frame their versions.

How? That’s what I discussed in the second part of the article: What to do when a fake MVP is unmasked?

How to unmask fake Minimum Viable Products during the design process was originally published in Societe Generale Design on Medium, where people are continuing the conversation by highlighting and responding to this story.