Our approach

Start with the problem.
Stay with the detail.

We bring design and engineering together to build useful software. That means understanding the task, questioning the unnecessary steps and caring about the things that happen beneath the surface.

The studio

Practical problems.
Considered products.

House Medical builds software for business and public-service problems. Our interest is in the everyday work that could be clearer: the calculation that needs an explanation, the repeated request for information, or the service that is difficult to navigate.

We see the experience and the engineering as parts of the same job. A clear screen needs sound rules underneath it. A capable system needs an interface people can understand.

Our starting point is the outcome someone needs to reach. The product takes shape around that.

Understand.

Look beyond the screen.

Start with the person and the task. What are they trying to do? What information do they have? Where do they need help, and what would a useful outcome look like?

It is also important to understand the rules, constraints and existing tools around the task. A product can only simplify a process properly when the important details are understood.

The people involved and the decisions they need to make.
The current journey, including work that happens outside the software.
Important assumptions, dependencies and open questions.

What this clarifies The problem worth solving and the conditions a useful solution must meet.

Simplify.

Make the next step feel obvious.

Turn the problem into a journey that makes sense. Put information in the order it is needed, ask questions people can answer and explain decisions at the point they matter.

Simplicity is not achieved by hiding everything. Sometimes the most helpful design is an extra explanation, a visible assumption or a chance to check an answer before continuing.

A clear sequence of actions and information.
Plain language and a useful hierarchy of detail.
Early consideration of small screens and different access needs.

What this clarifies How someone will move from a starting point to a meaningful result.

Build.

Care about what happens underneath.

Bring the interface, business rules and connections together. Inputs need to be handled carefully, calculations need to behave as intended and important actions need the right checks.

The less obvious cases matter too: missing information, invalid values, an unavailable service or a task that is interrupted. Useful software gives people a way to understand and recover from those situations.

Working behaviour that follows the agreed purpose.
Validation, permissions and appropriate handling of information.
Checks proportionate to the risk and consequences of the change.

What this clarifies Whether the product behaves usefully and what needs attention before release.

Refine.

Learn from the moments that matter.

Real use reveals questions that a specification cannot anticipate. Where do people hesitate? Which errors recur? What information do they still need after reaching the result?

Improvement should be directed at those practical problems. A small change to wording, a default or the order of a journey can be more useful than adding another feature.

Feedback and patterns in the difficulties people encounter.
Changes that improve a specific part of the experience.
Attention to the product’s dependencies and future maintainability.

What this clarifies The next improvement that would make a real difference.

Our point of view

Good software respects
people’s time.

It makes the important things clear, handles the complexity it can and helps people keep moving. A polished surface is valuable when the experience underneath it is just as considered.

What good looks like

Judge the result
by the task it improves.

The right measures depend on the product. These are useful questions to ask when deciding whether an experience is working.

Can people finish?

Task completion and where people stop can reveal an unclear step or an unnecessary obstacle.

How much effort does it take?

Time, repeated inputs and avoidable handovers can show where the process asks too much of the person using it.

Can they trust and correct the result?

Clear assumptions, understandable outputs and useful error recovery matter alongside accuracy.

Who can use it?

Keyboard access, readable content, responsive layouts and different needs should inform the assessment.

Can it keep improving?

A product needs a structure that people can understand, support and change without unnecessary difficulty.

Start with the problem.Stay with the detail.

Practical problems.Considered products.