Product designer · product manager

I ship product work unusually fast.

Twenty-plus years designing and running products — interaction design, research, and product strategy — now multiplied by AI. I am an early adopter of it, not a tourist. The experience is the thing. The tools just let me use more of it in a week.

This page is for hiring managers who want a product designer or a product manager. I do both, and I treat them as two views of the same job. Each story below is a full article, not a bullet list.

See five jobs danny.hope@gmail.com

Read these jobs as

01

Ensemble AI

Product designer · 2026 · industrial AI

Ensemble automates business processes for medium and large enterprises with AI. I joined as product designer on Flux Reliability, the spare-part product for people who keep production lines running. The users are not warehouse clerks in a tidy aisle. They are technicians on a factory floor, looking at a part that may have no barcode, a name nobody agrees on, and a history that lives in someone’s head.

That is a product problem pretending to be a form. If logging a spare is slow or untrustworthy, every later promise — matching, location, replenishment — is built on sand. I treated the first job as: make the act of recording a physical spare something a tired person can finish, and something the catalogue can believe.

The situation

Vision was broad and a little fuzzy. The company could see a large industrial AI suite. The slice that actually unblocked the rest was smaller: get a spare into the system, identified well enough that the next person does not start again from scratch. Founders, engineering, and design were not yet arguing about the same object. Some days the object was “inventory.” Some days it was “reliability.” On the floor it was “what is this, and where did I put the last one.”

I have seen this pattern for twenty years. A platform story is easier to sell than a logging story. The logging story is the one users fail first. If you skip it, you get a beautiful empty catalogue.

The design work

I started on the floor, not in the component library. I mapped how technicians find, name, and park physical spares: scan when a code exists, type when it does not, guess when the label is oil and the official name is a sentence. The interface had to tell the truth about stock that is incomplete, duplicated, or sitting on a shelf that the system has never heard of.

The flow I prototyped was short on purpose. Scan or type. Match against the catalogue, including the uncomfortable “this might be one of these” state. Confirm a location a human can walk back to. That last step is design, not a data field. A location that only a database understands is a lost part.

Design reviews were about whether the screen was lying. Does this look like a finished record when it is not? Are we hiding the mess to look enterprise-ready? I would rather a technician see “we are not sure” than click Confirm on a fiction. AI tooling meant research notes became a tryable interface in days, so those reviews happened against a prototype, not a deck of boxes and arrows.

The product call

I sat in the product seat for the slice that unblocked everything else. Scope stayed narrow on purpose. The temptation in an industrial AI company is to jump to prediction, automation, and the slide that says “closed loop.” None of that holds if the team cannot agree what a logged spare is.

So the roadmap question was not “what can the model do.” It was “what decision can the team make this week if they can poke a working UI.” I used AI the way I now use it everywhere: compress the distance between a conversation and an artefact. Notes from a walkthrough became a flow people could click. Arguments moved from “I think users will…” to “try this and tell me where you stop.”

That is product management with design hands. You do not need a twelve-week discovery phase to learn that a spare without a barcode is the common case. You need to put that case on the happy path and refuse to treat it as an edge.

What I would do again

Pick the smallest real job, make it honest, and get the team deciding against something they can use. In 2026 that loop is short enough that “we should write a spec first” is often a way of delaying the argument. I still write things down. I just do not wait for the document to be the only thing in the room.

Hiring managers sometimes hear “AI” and picture a person who outsourced the craft. The opposite is true here. The craft is knowing which spare-part moment is the product. The tools let me get to that moment before the calendar eats the quarter.

02

UX Brighton

Founder and curator · 2008–present · community product

I started UX Brighton in 2008 as a grassroots usability meetup. It is now an annual conference, a job board, a mentorship programme, and a community that treats product and UX as two views of the same work. I am still the founder and curator. That is not a title I keep for the letterhead. It is the job of deciding what the year is for, and then making the day good enough that people can do something on Monday.

A conference is a product. It has users, a constraint (one day, one room, finite attention), a business model, and a quality bar that you feel in the corridor at lunch. If you only think of it as “content,” you get a playlist. If you only think of it as “an event,” you get logistics with a theme stuck on the poster.

What the product is

Each year I curate around a point I want the room to leave with. UX and product management. UX and AI — what practitioners actually need to know, not a vendor tour. Emerging methods when the methods have earned a day. The theme is a design decision. It is also a product decision: it tells speakers what to refuse, sponsors what they are buying, and ticket-holders why this year is not last year with new lanyards.

I run tickets, sponsors, editorial, and ops as a small product business. There is no separate department that “does the product bit.” When something is late, it is because I sequenced it late. When the day feels tight, it is because I allowed a talk that did not serve the point. That accountability is the whole appeal of founding something you still operate.

Designing the day

I coach speakers the way I would coach a product team away from a feature dump. The question is not “what do you know.” It is “what will a practitioner try next week because they heard you.” I shape the running order as an artefact: energy, contrast, a through-line, and enough air that people can talk to each other. A conference programme is information architecture you sit inside.

The evening meetups taught me the same lesson at a smaller scale. A good night has a job. A vague night has snacks. I still write the prep lists, still care about how a room feels when someone is new, still refuse the idea that “community” is a vibe you cannot design. You can. You just have to treat hospitality as part of the interface.

Operating it

The metric is a better day, not more features. I have added a job board, mentorship, and the usual machinery around a conference because they serve the same users, not because a roadmap template had empty boxes. If a new surface does not make the year clearer for a practitioner, it is a distraction with a CMS.

AI now sits in how the conference is produced. The same person can move from an idea to a live page, an email, and a programme draft without a waiting list of specialists. That is not a parlour trick. It is how a founder with twenty years of taste keeps pace with a community that expects this year’s site to exist while this year’s ideas are still being argued. I do not use the tools to invent a point of view. I use them to get the point of view in front of people while it is still useful.

Why this belongs on a hiring page

UX Brighton is the longest-running proof that I can hold design and product in one head. I pick the problem for the year. I design the experience of the day. I run the business that pays for both. Hiring managers who want a designer who understands a P&L, or a product manager who can still feel a room, already have the evidence. It has been public since 2008.

03

Rakuten Marketing

UX design lead · advertising platform

Rakuten Marketing had an advertising platform team that was shipping features. Users needed a product. I led UX, and I put user-centred product management underneath the design work so the practice would survive the next quarter. Pretty screens on top of a feature backlog are a costume. I wanted the team to be able to name the need, refuse work that did not serve it, and know when something was actually done.

Ad platforms are a special kind of mess. The user is often a professional trying to spend money well, inside a system that wants to show them every lever. If you design from the database out, you get a cockpit. If you design from the job out, you get a sequence: acquire, activate, understand, adjust. I pulled the work toward the second of those.

The problem under the backlog

A feature backlog feels responsible. It is a list, it has owners, it can be estimated. It is also how a team spends a year making the product harder to start. Nobody on that list is accountable for the user’s first successful hour. Everybody is accountable for their ticket. I have watched this from both consultancy and in-house seats. The fix is not a nicer Jira workflow. The fix is to change what the list is of.

The design practice

I ran journey mapping, contextual enquiry, and usability testing as the normal way of knowing things, not as a ceremony you book when a stakeholder is nervous. The point of the research was not a report. It was a shared picture of where people got stuck, so a designer and a developer could argue about the same moment.

I wrote the standard for what counted as done. New work could not ship because it compiled. It had to meet the bar we had said out loud: a task a real user could complete, with the rough edges named if we were shipping a slice. That sounds like process. It is design leadership. Without it, every review becomes taste, and taste loses to whoever is loudest near the release date.

I also trained full-time staff in the basics. A visiting lead who does beautiful work and leaves no one behind has only rented a capability. I would rather a quieter interface and a team that can keep raising the floor.

The operating system

I replaced the feature backlog with theme-based roadmapping, in the spirit of Amazon’s working-backwards style. Themes were user needs you could say in a sentence: acquisition, activation, the job of understanding whether spend was working. If we could not name the need, we did not build the screen. Alignment was the actual job. Design was how you could see whether you had it.

This is product management even when the badge says design lead. Someone has to protect the sequence. Someone has to say that a clever targeting control is later if the first-run still dumps people into a wall of settings. I was willing to be that person, and I was willing to put the evidence on the table so it was not a personality fight.

What stuck

The useful leftover is not a particular UI. It is a team that can tell a need from a ticket, and a definition of done that does not require me in the room. That is the only kind of design leadership I am interested in repeating. AI would have made the research-to-prototype loop faster — I do that now as a matter of course — but it would not have changed the call. Needs first. Features after. People on the team who can keep doing it.

04

York Instruments

Product designer · brain imaging startup

York Instruments built specialist hardware for looking at brains. Magnetoencephalography — MEG — is not a consumer app with a forgiving audience. The people on the other side of the glass scan brains for a living. They will not be impressed by a pitch-deck gradient. They will notice if the interface makes a careful job sloppy, or if it hides the thing they need to check before they trust the take.

I joined as a product designer. The work sat in that uncomfortable place between a machine, a clinical environment, and software that had to earn the right to be touched during a real session. You cannot A/B test your way through that. You have to sit with the people who already know, for a long time, and then make something they will argue with honestly.

Research before chrome

The early useful work was not a UI kit. It was getting close enough to the acquisition and validation job that we could see what “good” meant in their language. Before analysis there is a stretch where you need to know whether the data you are collecting is worth keeping: channels, timing, whether the spatial picture of the brain and the traces you are staring at are talking about the same moment. Experts already have a way of thinking about that. The interface’s job is to get out of the way of that thinking, then support it.

I used long co-design sessions, not a survey and a persona poster. These users will tell you when you are wrong, if you have given them something concrete enough to be wrong about. Sketches of a brain spatial view, a timeline, and a panel of controls that only appear when they have a reason — that is the sort of artefact that starts a real conversation. Abstract wireframes of “a dashboard” do not.

A system for a job that kits do not cover

Off-the-shelf design systems assume a browser, a mouse, and a user who can pause. A clinical environment assumes none of those comforts as a given. I worked on a design system for the interaction needs this product actually has: dense information that must stay calm, controls that stay contextual, a cross-platform interface that could survive next to hardware instead of pretending the hardware was a website.

I worked with developers as a peer, not as a person who throws pictures over a wall. In this kind of product the implementation is the design. If a control is a pixel off conceptually — if it invites an action at the wrong moment in a take — you have not “done the visuals.” You have introduced risk. The craft is in the pairing.

The pivot the research asked for

The research said something awkward for a hardware company: the durable value was not only the machine. It was the software clinicians would actually use, session after session, to acquire and trust data. That is a product decision. Hardware was the starting point. Becoming a medical software provider was the implication, if you believed the users.

I am not going to dress that up as a transformation programme I single-handedly ran. I will say this: I was in the room with the evidence, and I treated the evidence as something you change a company around, not something you file under “insights.” Plenty of design work dies because nobody will make the product call. This one existed to force the call.

What I took with me

Respect for specialised users, and a refusal to pretty-up a workflow I do not yet understand. Also a useful suspicion of “we are a hardware company” as a strategy. Sometimes you are, and the box is the product. Sometimes the box is how you got into the room, and the software is what they will still need when the next box arrives. You find that out by watching the work, not by updating the category on the website.

05

Attendance Allowance

Product and service design · Department for Work and Pensions

Attendance Allowance is a legacy government service. People do not opt into it the way they opt into a startup. If you need it, you need it, and the service has to work inside policy that was not written for a happy path on a phone. I worked on redesigning it from the ground up — product and service design together — in the Retirement, Bereavement and Care part of DWP, through Capgemini.

Public-sector work has a reputation for slowness. Some of that is real: statute, operational reality, the number of people who can say no. Some of it is a habit of deciding in documents. I am useful in that environment because I can hold the user need against the constraint, and because I prototype fast enough that the room is arguing with a service, not a workshop wall.

What “from the ground up” actually means

It does not mean a greenfield app with a new brand colour. It means looking at the whole service — the form, the wait, the letter, the person on the phone, the policy rule that makes a question exist — and then cutting a slice you can research. If you only redesign the screen, you have decorated the constraint. If you only write recommendations, you have given someone a PDF they can politely file.

I built code-based prototypes for research. Code, not a click-through that dies when a stakeholder asks “what if they say no here.” A prototype you can put in front of a user, and in front of policy, is a decision tool. I facilitated across roles so operations, policy, and design were looking at the same thing at the same time. That is the only way a recommendation survives contact with government.

Design inside a statute

The craft is making the constraint visible without making the user feel stupid. Attendance Allowance asks people about their lives at a moment when they may already be tired of proving things. A clean layout that still demands the impossible is not good design. A messy layout that lets someone finish is closer. I care about the finish.

Collaboration across roles is design work. If policy is not in the research session, you will invent a journey that cannot be live. If operations is not in the session, you will invent a journey nobody can staff. I would rather a plainer prototype that those people will correct than a polished one they only see in a readout.

Product management in a regulated room

Sequence the work. Hold the need. Prototype before the committee hardens around a guess. That is the job, whether or not anyone printed “product manager” on the contract. I have done the same pattern on GOV.UK’s Digital Engagement Platform — chat patterns and design principles for an interface meant to work across government — and on UK Trade Info, where the job was querying official trade statistics without drowning a human in big data.

Those three pieces of public work are one skill: make the system answer a question a person is actually asking, inside rules you do not get to delete. AI helps me get to the prototype sooner. It does not help me pretend the rule is gone. Hiring me for a regulated product means you get someone who will not sell you a fiction and then look surprised at legal.

The standard I keep

Can a person complete the thing they came to do, and can the institution live with how they did it? If both answers are yes, you are making progress. If only one is yes, you have either a demo or a bunker. I aim for the overlap. That is product design. It is also product management. On this page they are the same article.

Also in the mix

Change Grow Live — Top Tasks analysis and a playbook so a charity team could keep a user-focused site without me. Freybors — Lean Startup on a group-buying food app, Scrum then Kanban. Clients over the years include WHSmith, Gumtree, Sanyo, the V&A, and the Museum of London. I have taught usability and rapid prototyping as an associate tutor at the University of Sussex, and spoken on design programmes at Brighton, Sussex, and New Design University.

What that felt like to work with

Danny has a wealth of knowledge around UX and has helped to significantly up-skill my colleagues and I. We now have the tools and resources we need to ensure our website is user-focused. He is extremely passionate about what he does and really invested in us as a client.

Abi Cox, digital marketing lead and digital product owner, Change Grow Live

I'm left with no doubt whatsoever that Danny has done a sterling job and delivered more than what was required in the project proposal. Thanks for all the hard work. I really appreciate it and I've enjoyed the bits of the project where I worked with you.

Harry Brignull, project lead, taxonomy work with Gumtree

Danny is a practical and clear thinker and communicator: his work is based on real-life practice, collaboration, debate and extensive reading. He works in carefully considered iterations towards creating a finished thing — always with the aim of making sure users are getting what they need.

Ellen de Vries

Let’s talk about a role

If you need a product designer or a product manager who already has the scars, and who can use AI without forgetting how products actually get made, book a short call.

Book a call
danny.hope@gmail.com 07595 226 792 CV LinkedIn

Read it another way

Web index · Long-form PDF · Slide deck · Slide-deck PDF