Visual — hero
Professional work
Chanel — My Little Black Book
Growing MLBB without making it the answer to every request.
My Little Black Book 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 scope.
Where the product stood
The scale of the product and the organisation, not outcomes attributed to design.
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.
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.
A shared system makes new requests easier to absorb. It does not tell you whether the request should exist in the first place.
(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.
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
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 actually 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.
(03) Seller workflow
The field is a better filter than the feature list
That decision is a good summary of my role on MLBB. The job was not to turn every request into a screen. It was also to 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.
-
01
Find
0:00From Home, open the Suggestion Boards, name the board and pick the client.
-
02
Understand
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
Act
0:16Share it as a link. The client says what to set aside.
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.
