
Visual · hero
Professional work
Chanel · My Little Black Book
Growing the app without making it the answer to every request.
My Little Black Book (MLBB) supports a wide range of boutique work: finding a client, preparing an action, selling, paying, checking stock or picking up a task later. When I joined, the app was still mainly European. Over nearly two years, the product, the team and the number of requests all grew at the same time.
(01) Context
Three divisions, one app
A request can make perfect sense for one division and create unnecessary weight for the other two. If every local need becomes its own branch of the product, the app gets harder to understand and harder to maintain very quickly.
I worked with the Product Owners and engineers to keep shared behaviour where it made sense and allow real business differences where they were justified. Later in the mission, I was the only designer on the product.
Part of that work was structural. Some of the design source still lived in Sketch when I arrived. We moved the work into Figma and built the first shared component layer while feature delivery continued.
A shared system makes new requests easier to absorb. It does not tell you whether the request should exist in the first place.
Where the product stood
The scale of the product and the organisation, not outcomes attributed to design.

123- 1The shared media component gives the campaign visual the space.
- 2The chosen visual is shown in full, as the client will receive it.
- 3Channels use the common list pattern: named, one tap to choose.
(02) Product judgement
One feature I argued we should not build
At one point, one business branch wanted a calendar inside MLBB. The idea sounded reasonable: centralise more of the manager’s day in one app and reduce tool switching.
Field work changed the picture. Managers already had planning tools and established habits. MLBB was already carrying a lot of functionality, the technical debt was real, and the available effort would almost certainly produce a weaker calendar than the tools people already used.
So the risk was fairly clear: add more weight to an already dense product, only to replace a working behaviour with a worse version of it.
I did not want to take a flat “no” back to the business. I showed the ideal case, what we could realistically build with the current constraints, and what the lightest version would look like. Placed next to what we had observed in boutiques, the value became difficult to justify. It was a political conversation, but the feature was eventually dropped.
How the calendar request was weighed
- 01The ideal calendar
- 02What we could really build
- 03The lightest version
- 04Next to the planning tools boutiques already use
(03) Seller workflow
Start from what happens in the boutique
That decision sums up a lot of my role on MLBB: before turning a request into a screen, understand what it would change for the seller or manager and what the product would have to carry afterwards.
When a feature did deserve to exist, the interface had to demand as little attention as possible in the middle of a boutique interaction.
The Figma migration, the shared system and these product calls all served the same purpose: let MLBB keep growing without having to reinvent itself every time a new request arrived.
-
01
Create a board
0:00From Home, open the Suggestion Boards, name the board and pick the client.
-
02
Add the pieces
0:10Add the pieces by their full names and references, the way sellers talk about them. A board can be prepared ahead and filled over time.
-
03
Share with the client
0:16Share it as a link. The client says what to set aside.