[READ ME] The Noémie Operating Manual
A little guide to how I think, communicate, collaborate, and do my best work.
Hi! 👋
I’m excited to work with you, and I’m looking forward to what we’ll build and learn together.
I tend to believe that the quality of our work is deeply connected to the quality of our collaboration. We all have different ways of thinking, communicating, making decisions and receiving feedback, so I find it useful to make some of those things explicit.
This is my attempt at giving you a little operating manual for working with me: what I value, how I work, what tends to bring out my best, and a few known bugs you may occasionally encounter.
This isn’t a set of rules. It’s an invitation to understand how I work, and hopefully to make it easier for you to tell me what you need from me too.
1. How I View Success
Good work starts with understanding the problem.
I care deeply about the quality of the thinking behind the work, not just the quality of the final output.
For me, success means:
We understand the problem we’re actually trying to solve.
We understand who we’re solving it for and why it matters.
We make decisions intentionally rather than by default.
We challenge assumptions instead of quietly building on them.
We create something useful, feasible and desirable, not just something that looks good.
We learn from what we do, whether it succeeds or fails.
We leave the process, the product and ideally ourselves a little better than we found them.
I have high standards, but they are standards I apply to myself too.
I also believe ambitious work will sometimes fail. That’s okay. A thoughtful failure that teaches us something is far more valuable to me than a mediocre success that happened by accident.
The outcome matters. The path matters too.
I also tend to think long-term. I would rather aim for something ambitious and occasionally fall short than optimise for something safe and small.
2. How I Communicate
Give me the context
I tend to think in systems, so the why is usually more useful to me than the task itself.
“Can you redesign this screen?”
is much less useful than:
“Users are struggling to understand X. Product needs Y by Friday, and Engineering has a constraint around Z. How might we approach this?”
Give me the landscape and I’ll happily help navigate it.
I think better in writing
I am generally clearer in writing than I am spontaneously in conversation.
In meetings, I sometimes think out loud, which can make my reasoning sound more meandering than it actually is.
If my point isn’t clear, please ask me to make it concrete.
You are absolutely allowed to say:
“What’s your actual recommendation?” or: “Can you give me the short version?”
I will appreciate it.
I value clarity over politeness
I like thoughtful disagreement.
You don’t need to agree with me because I’m the designer, because I’ve been thinking about something for longer, or because you think I want you to agree.
If you think I’m wrong, tell me.
I would much rather have a constructive disagreement than polite alignment followed by confusion later.
Async is my friend
I generally prefer Slack or Teams for day-to-day communication and asynchronous collaboration.
I don’t expect instant replies, and I don’t expect everyone to be constantly available.
If something is genuinely urgent, please make that explicit.
Otherwise, give me some time to think. I tend to do my best work when I can get into a deep-focus zone without being interrupted every twelve minutes.
3. My Design Style & Process
I think in problems, not screens
My natural sequence is:
Understand the problem → understand the users → explore the possibilities → make decisions → design the experience → validate → refine → ship
Rather than:
Open Figma → draw something → figure out why we’re doing it later.
So if I ask a lot of questions before opening Figma, that’s usually intentional.
I like ambiguity early and clarity late
Early in a project, I’m very comfortable saying:
“We don’t know yet.”
I actually enjoy that phase.
I like exploring different possibilities, challenging assumptions and keeping the solution open while we’re still learning.
But once we’ve made a decision, I care a lot about clarity, alignment and execution.
Messy thinking early. Crisp decisions later.
I share the ugly version
I don’t wait until something is polished before sharing it.
I’d rather share:
a rough sketch
half-baked ideas
competing options
an imperfect prototype
a FigJam full of chaos
a hypothesis you’re not sure about
than a beautiful Figma file that took three days to produce before anyone had a chance to challenge the direction.
Early feedback is cheap. Late feedback is expensive.
I care about feasibility (yes, I do!)
I like working closely with Product and Engineering rather than throwing designs over the wall.
Technical constraints aren’t an annoying reality that comes after design. They’re part of the problem we’re solving.
Bring me into those conversations early. If something can’t be built, tell me why and let’s find the best experience within the constraint.
4. How I Like to Receive Feedback
I genuinely want feedback.
Not just feedback about the work, but feedback about me: how I communicate, collaborate, lead, behave and show up as a teammate.
I see feedback as one of the best ways to keep learning, and I would much rather hear something uncomfortable that helps me improve than be left guessing.
That said, different kinds of feedback work better in different ways.
Feedback on the work
For design work, I prefer feedback that is:
early
specific
contextual
grounded in user needs, evidence, business goals or technical constraints
Less useful:
“I don’t like this.”
More useful:
“I’m worried users won’t understand what happens after they click this.”
Even better:
“Based on what we heard from users, I’m worried people will interpret this action as X rather than Y.”
Please challenge the thinking, not just the pixels.
Feedback about me
If the feedback is constructive, personal or potentially sensitive, I strongly prefer a 1:1 conversation, ideally verbally or face-to-face, rather than written feedback or feedback in front of a group, leadership or other colleagues.
The reason is simple: feedback about someone’s behaviour is inherently open to interpretation.
I find it much more useful when it becomes a conversation rather than a verdict.
One thing I particularly appreciate is being asked what I think first:
“How do you think that went?”
or:
“How do you feel about how you handled that?”
Sometimes I’ll already be aware that I didn’t handle something well. Sometimes I won’t.
Knowing where my own self-awareness starts makes the feedback much more useful.
Then tell me what you observed, how it affected you or the team, and what you think I could have done differently.
I don’t need you to soften the message. I need enough context to understand it.
And please don’t worry that I won’t be able to handle constructive criticism. I genuinely want to know.
Positive feedback is different
Encouragement doesn’t need the same level of ceremony.
If you enjoyed something I did, found something useful, or think something went particularly well, Slack, a written comment or a quick message are all very welcome.
I may be quite rational and independent, but apparently I am still a human being and positive reinforcement does work. 😄
One important distinction
Design critique:
→ Early, specific, contextual, and preferably directly on the work.
Constructive personal feedback:
→ 1:1, ideally verbal, with room for dialogue.
Positive feedback and encouragement:
→ Anytime, anywhere. Written is absolutely welcome.
5. Working With Functional People
I see Product/Functional roles and Design as partners in framing and solving the problem, not Design as a service desk for producing screens.
I like collaborating on:
defining the problem
understanding user value
clarifying outcomes
exploring options
prioritising
managing scope
making trade-offs
deciding what not to build
If the scope is impossible, I’d rather have that conversation early than quietly try to squeeze an elephant into a lunchbox.
I also appreciate SA partners who are comfortable saying:
“We don’t know yet.”
That gives us something real to work with.
6. Working With Technical Architects
I don’t expect every idea to be technically possible, and I don’t need everything to be implemented exactly as designed. It’s better if you bring me your constraints early.
What I care about is finding the best experience within the actual constraints.
If something can’t be built, I’d much rather understand the constraint and explore alternatives with you than discover it during handoff.
I also appreciate engineers challenging designs when they see a simpler, better or more robust solution.
The goal isn’t to defend the design. The goal is to build the best thing together.
7. What Builds My Trust
There are a few things that make me trust someone very quickly.
Transparency
Tell me when something isn’t going well.
I don’t need problems wrapped in three layers of corporate bubble wrap.
I’d rather hear:
“This isn’t working, and here’s why.”
than:
“Everything is broadly on track.”
when it very clearly isn’t.
Ownership
I admire people who don’t just identify problems but actively try to solve them.
Bring me the problem, but ideally also bring me:
what you’ve already tried
what you’ve learned
what you think we should do next
who else might need to be involved
I love people who use all the resources available to them rather than waiting for someone else to rescue the situation.
Curiosity
I trust people who are curious, who ask questions and who are comfortable saying:
“I don’t know.”
Not knowing something is completely fine.
Not being interested in learning it is much more problematic.
Commitments
If you tell me you’ll do something by Friday, I expect either Friday or an early warning that Friday isn’t going to happen.
I don’t mind plans changing.
I mind discovering three days later that the plan changed and nobody told me.
Intellectual honesty
If the evidence contradicts your idea, change your mind. I’ll do the same.
Challenge me. Give me good feedback. Tell me when I’m wrong.
I will probably trust you more afterwards.
8. Things That May Occasionally Annoy You About Me
I come with some known bugs. Please report them directly to me. 😇
I can overthink
I naturally see edge cases, second-order effects and possible future problems.
This is occasionally useful.
It can also result in me turning a small problem into a philosophical inquiry about the nature of software.
If you hear me boiling the ocean, tell me:
“What is the simplest thing we need to solve right now?”
I can be too rational
My instinct when someone brings me a problem is often:
understand → analyse → propose a solution.
Sometimes the correct sequence is:
listen → empathise → shut up.
I am still working on that feature.
I can be demanding
I care deeply about quality, and I naturally see how something could be better.
The downside is that I can sometimes focus more on the gap between good and great than on recognising that something is already good.
If my feedback starts sounding like an endless list of improvements, please tell me.
I can jump too far ahead
Because I tend to think long-term, I can sometimes propose a beautifully elegant future-state solution when what we actually need is a pragmatic solution for next Tuesday.
If that happens, pull me back to reality.
I can assume too much context
I’ve often spent a lot of time thinking about a problem before discussing it, so I can forget that other people haven’t been living inside my brain for the last three weeks.
If I’m skipping context, stop me.
I can be comfortable with ambiguity for longer than others
As a designer, I’m quite comfortable living in the grey zone while we figure things out.
That can be frustrating if you need a concrete answer immediately.
If you need me to make a decision, tell me.
9. My Pet Peeves
“Can you just make it pop?”
Without a problem, objective or user need attached.
Being brought in too late
Especially when all the important decisions have already been made and Design is then expected to make the predetermined solution “user-friendly”.
Treating assumptions as facts
“Users obviously want…”
Do they?
Polishing before understanding
A beautiful solution to the wrong problem is still the wrong solution.
Office politics and unnecessary drama
If there’s an issue with someone, I strongly prefer addressing it directly and constructively to them, not to me.
10. My Strengths
Systems thinking
I naturally connect the dots between users, product, technology, business and long-term strategy.
Problem framing
I enjoy taking something complex and making the underlying problem understandable.
Making complexity simpler
One of the things I enjoy most about UX is taking something complicated and finding the structure underneath it.
Facilitation
I’m comfortable bringing different perspectives together and helping teams move from disagreement toward alignment.
Calm under pressure
I tend to stay relatively composed when things become complicated.
I’m usually more interested in understanding what happened and what we can do next than in finding someone to blame.
Curiosity
I genuinely enjoy learning, especially when different disciplines collide.
Building relationships
Although I’m naturally quite independent, I care a lot about trust and meaningful relationships.
I tend to invest deeply in relationships that matter.
High standards
I care about quality and will usually push for a better answer when I believe one is within reach.
11. Things I’m Working On
Being more concise
Getting to the heart of the matter faster.
Being more direct
Saying what I really think earlier, especially when something isn’t working.
Balancing perfection with progress
Knowing when something genuinely needs another iteration versus when my designer brain is simply looking for another mountain to climb.
Execution
I have no shortage of ideas.
Turning the right ones into reality, quickly and consistently, is something I want to keep improving.
Making appreciation as visible as critique
I naturally see the gap between something and its potential.
I’m working on making sure people also hear what is already working.
Choosing the right altitude
Sometimes the team needs a five-year vision.
Sometimes it needs to know what we’re doing by Thursday.
I’m working on getting better at knowing which altitude is useful in the moment.
One Last Thing
You don’t need to manage me.
You don’t need to tell me what you think I want to hear, protect me from uncomfortable information, or make everything sound better than it is.
Treat me like a thoughtful peer. Challenge me. Give me context.
Tell me when I’m wrong, when I’m overcomplicating something. Tell me when something isn’t working.
And if you give me feedback about myself, please know that I genuinely want to hear it. I just want us to have the kind of conversation where we can understand each other properly.
I’ll do my best to give you the same in return.
If we can trust each other enough to be honest, curious and occasionally disagree, while still having fun building things together, that’s probably a pretty good definition of a successful collaboration.