Kendoo

User Experience Strategy

Decide what to build before deciding how it looks

User research and design grounded in how people actually behave, so the roadmap reflects what users need rather than what the team assumed.

Discuss your challenge See all services

Triggers

The situations that lead here

These usually get described as design problems. They are more often decision problems.

  • You shipped the feature and usage did not move
  • Onboarding loses people and nobody knows where
  • Support answers the same question every week
  • The roadmap is a list of requests with no ordering principle
  • Two senior people disagree about what users want and both are guessing
  • A redesign is being proposed and nobody can say what it would fix
  • The product grew by accretion and now nothing is findable
  • Churn is happening quietly and the exit reasons are all different

Scope

What the work covers

Research that reaches a decision, and design that follows from evidence rather than taste.

  1. Research with real users

    Interviews and observation with the people who actually use the product. What they do, which is regularly not what they say, and where the current experience breaks down.

  2. Evidence you already have

    Support tickets, sales calls, churn conversations and analytics. Most companies are sitting on more signal than they realise and have never read it as one body.

  3. Information architecture

    How the product is organised and named. The structural decisions that make things findable, and the hardest ones to change later.

  4. The flows that matter

    Onboarding, the core loop and the moments where people give up. Concentrating on the paths that carry the value rather than redesigning everything.

  5. Design direction

    The interaction and interface decisions that follow from the research, worked through far enough to be built rather than admired.

  6. What to measure

    Agreed before the change ships, so you can tell afterwards whether it worked instead of arguing about it.

The argument

Most product disagreements are evidence problems

When two capable people disagree about what to build, the argument almost never resolves on reasoning, because both positions are consistent. They are disagreeing about facts neither of them has.

Those facts are usually cheap to get. A handful of conversations with real users settles the question in a way that months of debate does not, and the same themes come up so quickly that the exercise is shorter than teams expect.

So this is not a visual discipline. It is a decision discipline that happens to produce screens. The value is in the roadmap you did not spend six months building.

How it runs

The shape of the engagement

  1. Frame the question

    What decision is actually waiting on this. Research without a decision attached is how a study ends up in a drawer.

  2. Gather the evidence

    Conversations with users, plus the signal already sitting in support, sales and analytics. Read together rather than separately.

  3. Decide, and write it down

    What the evidence supports, what it rules out, and what remains genuinely uncertain. Recorded with the reasoning, so it can be revisited on facts.

  4. Design and instrument

    Flows and interface direction worked through to something buildable, with the measure of success agreed before it ships.

What this is, and what it is not

What it is

  • Research aimed at a decision that is already waiting
  • Evidence from users and from what you already hold
  • Structural and flow decisions, written down
  • Design direction that follows from the evidence
  • Agreement on what will be measured afterwards

What it is not

  • A visual refresh with no question behind it
  • A research report with no decision attached
  • Ongoing production design capacity
  • Usability testing to confirm a decision already made
  • A redesign proposed because the product looks dated

Where the honest finding is that the product works and the problem is that nobody knows about it, that is said plainly, and it is a positioning question rather than a UX one.

Shay Ben Barak

Trusted expert for this work

Shay Ben Barak

Product, UX & HCI expert

Shay works across product and experience strategy, user research, interaction design and usability for complex systems.

He holds an M.Sc. in cognitive science from the Technion, lectures at the University of Haifa and mentors startups through Google for Startups. He joins Kendoo engagements when the product question needs dedicated UX and human-computer interaction expertise.

Questions executives ask

Is this design, or research?

Both, in that order. Design without research is a well-executed guess, and research that never reaches a design decision is a document. The work is the line between them: evidence turned into decisions someone can build.

We have designers already. What does this add?

Usually the strategy layer above the screens. Designers who are handed a backlog produce good versions of whatever they were asked for. What is often missing is the decision about what should be built at all, and the evidence to settle it.

How much research is enough?

Far less than teams fear and rather more than none. Five or six well-chosen conversations settle most product arguments, because the same thing keeps coming up. The failure mode is not too little research, it is research nobody uses.

Our users are enterprise buyers and hard to reach.

That is common and workable. Where users are genuinely inaccessible, support tickets, sales calls, churn conversations and product analytics carry most of the same signal. It is worse than talking to people and much better than guessing.

Results

See how this looks in practice

Real engagements, shared anonymously. The situation, the decisions, and what changed.

Explore the results

Settle the question with evidence

Thirty minutes on the product decision you are stuck on, and what it would take to answer it properly.

Discuss your challenge See all services