Approach
Seven stages for practical improvement.
ANSK4's approach is organised around seven stages: understand the work, examine the need, test a response and learn from the result. Technology has a role where it helps the work.
The process
Continuous Improvement and Lean thinking guide the process: identify unnecessary effort, question assumptions, test changes and use evidence to keep improving. The stages below give that approach a practical structure.
Understand
Begin with a problem statement, not a feature list. Map how the work actually happens, identify where information is fragmented or effort is repeated, and record the constraints — regulatory, technical and practical — that any solution has to live inside. The focus at this stage is understanding the work.
Research
We examine existing approaches, available data and technology options, and we look honestly at why previous attempts in a space have succeeded or stalled. Research is used to narrow the problem, not to justify a predetermined answer.
Validate
Before committing to a change, we test whether the problem is significant, recurring and worth addressing for the people who have it. Where validation is weak, the concept should be reconsidered, paused or dropped.
Design
Design work focuses on structure and clarity: the right information at the right moment, with as little surface area as possible. We prefer a small number of well-executed functions to a wide but shallow set of options, and we treat accessibility as a design requirement rather than a review activity.
Build
Where the response involves software, engineering should support long-term ownership — readable code, sensible architecture, tested behaviour and clear documentation. Data protection, security and reliability belong in the development plan, with changes small enough to examine.
Measure
Once a change is in use, look at how it affects the work and where it falls short. Keep measurement deliberately modest: a small number of meaningful signals, collected with a clear purpose and with respect for the people doing the work.
Improve
Findings feed back into the next change. Some confirm the direction; others change it. A response that does not improve the work should be reconsidered, refined or set aside. Improvement continues as understanding develops.
Standing principles
Four rules that survive contact with a deadline.
The problem is the brief
A product idea is not a brief. Before anything is designed, there has to be a written statement of the problem, who has it, how often they have it, and what they do about it today. If that statement cannot be written clearly, the concept is not ready.
Validation is allowed to stop things
Research should leave room to change direction. A concept that does not survive validation can be paused or dropped; that is a useful outcome, not a reason to build anyway.
Smaller surface, deeper execution
A focused response should address the problem clearly. Where software is appropriate, the aim is to do the necessary things well and avoid adding complexity to the work.
Ownership after launch
A product needs care beyond its first release. Architecture, documentation and data decisions should make continued maintenance and improvement possible.
Published honestly
Every product is shown at the stage it has reached.
The process above is also the reason product statuses exist. A concept in research and a product available today are different things, and the website says which one it is describing.
- Status: Research
Early research and problem discovery. Not available today.
- Status: In development
Currently being developed. Not available today.
- Status: Available
Available to use today.
Working with ANSK4
Bring a problem, not a specification.
If you are dealing with a problem that fits this description — fragmented information, repeated effort, decisions made without good data — that is a good starting point for a conversation.