What we do, and how.
digitalMood is a product design and engineering company. This page explains how the work is done: what product definition, design and engineering each cover, how they depend on each other, how work runs on a new product and on a platform already in use, and what the work requires.
The disciplines are the same in both cases. A new product and a platform an organization already runs on are different starting points for the same kind of work: software people depend on, built to keep working and to keep evolving.
One kind of work, three connected parts.
We treat the software as a product — something with people who use it, roles, a lifecycle — whether it is being built from nothing or has been running in an organization for years. That is the thinking behind the work. The work itself has three parts: product definition, design and engineering. They stay connected throughout, rather than being treated as separate handoffs.
Product definition — what the software has to do, for whom, under which constraints — tells design what to make and for whom, and tells engineering what must exist and what must not change.
Design is done knowing how the software will be built and maintained. It returns to product definition what the interface reveals: roles that were missing, workflows that do not fit, edge cases nobody had described.
Engineering is done knowing who will use the software and why. It returns feasibility, constraints and the cost of change to design and to product definition — before decisions harden, not after.
The software in use — and its next version — sends new needs and platform constraints back to product definition and to engineering. This is what built to keep evolving means in practice: not a phase after launch, but a loop that runs as long as the software matters.
There is no fixed entry point and no fixed end point. Work can start with a problem that is not defined, with a design that has to be built, with a platform that has to do more, or with software that has to stay compatible with the next version of its platform. It ends where the engagement ends: a first version, an added capability, a product others can rely on, a platform that keeps evolving.
Product definition
What the software has to do, for whom, and under which constraints — before and during the build. We work through the problem, the people who will use the software, their workflows as they actually run, and the constraints around them: technical, organizational, regulatory. Technical analysis, feasibility and implementation planning are part of this work, not a separate engagement.
It gives design what to make and for whom, and gives engineering what must exist and what must not change. It needs back what the interface reveals, what is feasible and what a change would cost.
It leads when the need is clear and what should be built is not defined yet — and, with engineering, when something that already works has to become a product other people can rely on.
It ends in decided things — a scope for a first version, requirements that reflect how work is done, and the product's architecture: its roles, its editions or boundaries, its data — and in the build that follows, not in a document that someone else has to turn into software.
Design
The interfaces and workflows the software's roles will use: UX and UI, interaction, design systems, interfaces that work on any screen, prototypes where a decision needs one. Several roles inside one product usually means several views of the same data, designed for what each role has to do — not one interface with permissions bolted on.
Design is done knowing how the software will be built and maintained: it needs from engineering what is feasible and what a change would cost, and gives product definition back what only the interface reveals — the role nobody had named, the workflow that does not fit, the edge case that changes the model.
It leads, with the other two, when a new product — or a major part of one — has to be defined, designed and built as one piece of work. It shapes the interfaces when working software becomes a product. On a platform already in use, it designs for the people who already use it, inside the platform's own conventions rather than against them.
Our design work is described here and not yet publicly shown. This website is one example of it.
Engineering
Front-end and backend engineering, APIs and integrations, software architecture — and product engineering: releases, compatibility with the versions the software runs on, and its operation over time. On a platform an organization already runs on, this is platform evolution: a new capability, an extension or an integration built inside the platform — its accounts, roles, permissions and conventions — with privacy obligations handled inside it too: export, erasure, retention.
Engineering is done knowing who will use the software and why. It needs from product definition what must exist and what must not change, and from design the interfaces to build; it gives both of them feasibility, constraints and the cost of change.
It leads when the platform has to do something it does not do today, inside the platform; when what you run has to exchange data with the systems around it; and when what was built on the platform has to keep working through its next version. With product definition, it leads when working software has to become a product: releases, documentation, a support path.
Extensions and integrations are verified against each supported platform version before a release, and integrations are built so that the people who run the system can see what was delivered, what failed and what was retried.
Moodle is the platform where this work is publicly documented. Work
Publicly shown on Moodle; no attributable example on another platform yet. No attributable upgrade project is publicly shown.
How work runs
There is no fixed sequence. What follows are the four things that come up in almost every piece of work, described as they happen — not as stages.
How we start
Work starts from the problem, not from a specification — when there is one, from the problem behind it. When the need is clear but what to build is not, understanding the problem — and what a first version has to do to be useful — is the whole of the first phase; when a design or a platform already exists, the phase is shorter, but it does not disappear.
The people doing this are the people who will design and build the software, and what the phase produces is decided — scope, requirements, architecture direction — so that the build can start.
No client definition phase is publicly shown.
Design and engineering together
Design decisions and engineering decisions are taken at the same table, by people who hold both. A screen is not designed and then handed over to be built: the data it needs, the permissions behind it, the states it can be in and what it costs to change later are on the table while it is being designed — and an architecture is not decided without the roles and workflows it has to serve.
Where such decisions are documented for our own product, they are shown as decisions; where they are not, we say so rather than reconstruct them.
It ends in software that could be built as designed, and used as built.
Working on a platform in use
A platform people log in to every day cannot be stopped for the work, and it will have a next version. Whatever is added has to work with the versions the platform actually runs, keep working through the next upgrade, and respect what the organization has already decided about accounts, roles and data.
No attributable client platform is shown; no attributable upgrade project is publicly shown.
Handover and evolution
Work is done in a repository from the start and documented as it is built: decisions and constraints are recorded while they are being made, not reconstructed afterwards. When the engagement includes a handover, there is a handover step, so that the client's team — or whoever they choose — can understand, maintain and extend the software.
This matters most when the people who built something are no longer around.
It ends in software that someone other than us can run and change.
We designed and built this website ourselves — its design system and the code behind it. It is one example of the way of working described above, not the centerpiece of it.
What the work requires
The work stays tied to the software being built or evolved. Product definition, design and engineering inform one another inside the same piece of work, and decisions are made against the constraints the software actually has: the platform it runs on, the people who use it, what already exists, what a change would cost.
We have also worked on other kinds of platforms — portals, case management, member systems. That work is not publicly shown.
Start a conversation
Tell us about the product or the platform: what it has to do, what it runs on, what is in the way.
Start a conversation