Imserv

IMServ as a compressed Critical Systems Design case

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

In the IMServ engagement, Creative Navy's Critical Systems Design method was compressed into an unusual shape: a one-week build sprint for a deliberately disposable, buyer-facing prototype, followed by a roughly 7-month Implementation Partnership after IMServ reported winning the tender. This case is not a measured-outcome redesign case. It is evidence that the phases of Critical Systems Design can remain recognisable under extreme time compression and inverted engagement conditions.

Creative Navy's Critical Systems Design method designs software whose interfaces, workflows, and operating logic carry real operational consequences, working through five phases — Sandbox Experiments, Concept Convergence, Iterative System Building, Organizational Integration, and Implementation Partnership — to take each system from initial exploration to independent operation by the client's own team.

IMServ's operational capability lacked a product surface for the SSE tender

IMServ is a UK energy data services company that collects, processes and presents energy usage data for large B2B portfolios. At the time of the engagement, IMServ was appointed across more than 24,000 meter points for one supplier's portfolio alone.

IMServ had deep operational capability in data collection and fault resolution, but it did not have a product that made that capability visible to a supplier. In IMServ's own framing, what existed was "nothing, just a verbal description." The immediate business need was a competitive tender with SSE, an energy supplier.

The required instrument was an interactive, clickable prototype of an energy meter management portal. The audience was SSE's commercial buyers, not end users. The prototype's role was persuasion: to make IMServ's operational capability legible and credible to people who understand energy settlement deeply enough to assess the proposed service.

The prototype was buyer-facing, deliberately disposable, and constrained by a fixed demo date

Creative Navy's design work for IMServ was shaped by a constraint that is not typical of a full product engagement. The kickoff framing was explicit that the artefact was "just about winning a deal" and could be discarded afterwards. The prototype therefore had to show operational credibility in a pitch setting rather than prove usability in deployment.

The engagement followed a 24 June kickoff and an 8 July demo. Creative Navy-recorded engagement facts describe a one-week active build sprint after requirements settled, not a full fortnight of uninterrupted design time. The delivery team was a UX designer, a UI designer, a product designer and a project manager.

Thirteen screens were designed as a single navigable demo flow. Scope discipline was part of the work: HSE, Cost Management and Asset Performance detail were marked "Not for demo"; self-serve screens were marked "If time"; ticketing was treated as sacrificable; and meter faults were selected as the only stage to drill down into so that design similarities could be reused under the deadline.

Creative Navy translated unstructured buyer anxiety into a five-stage meter journey

Creative Navy's design contribution began from material that was not a conventional requirements specification. The tender strategy material was written from the perspective of an SSE commercial buyer and included a section titled "the value drivers that keep me up all night," followed by more than fifteen "I need to…" statements.

Those statements covered concerns such as trusting the agent, being prompted before issues occur, making ownership unambiguous, keeping cost-to-serve low, proving security and making transition invisible to customers. The blanks phenomenon appeared at the structural level: content and operational anxiety existed, but the product structure that could make that material navigable did not.

Creative Navy converted that unstructured material into a five-stage flow: Agent appointed → Meter installed → Meter health → Data retrieval → Settlement processing. The five-stage journey was grounded in operational practice through the kickoff and tender input. It was not based on Creative Navy-observed field research.

The same operational backbone carried the thirteen-screen demo flow

Creative Navy reused the same five-stage meter journey across the management dashboard, portfolio health check, customer and MPAN lists, and single-meter issue views. This reuse made the thirteen-screen prototype coherent under a one-week build sprint because each screen used the same domain-accurate structure rather than a different generic dashboard pattern.

The domain learning required to make the flow credible happened at speed. Creative Navy absorbed enough UK energy-settlement terminology and operational logic — including MHHS, settlement runs SF/R1/RF, MPAN, ADS/SDS/UMSDS markets, and multi-party fault resolution — to structure a flow for domain-expert buyers.

The case evidence does not support a claim that Creative Navy conducted field observation or formal user research. Two informal conversations with meter practitioners were directional context only and are not presented as user research.

Ownership mapping made multi-party accountability visible at several levels

Creative Navy's design work addressed a multi-party accountability problem: in a portfolio of thousands of meters, the buyer needed to see whose action was blocking progress and whether that action was being chased. The prototype attributed each blockage to an owner across a six-party set: IMServ DC, IMServ MOP, Supplier, End User, Other Agent and Other Party.

The idea of making ownership unmistakable was Creative Navy's proposal. The final ownership mapping detail was optimised by IMServ. The design placed self-serve actions against the owner who could clear the blockage, making accountability visible at portfolio, customer and single-meter levels.

The status colours carried operational meaning rather than generic severity. Red meant the issue was causing the current collection or settlement problem. Amber meant the issue was not blocking now but could later, such as a missing site contact on a functioning meter. Green meant no current issue. Stages were visually ranked by settlement-performance impact without reordering the journey.

The per-MPAN risk percentage, such as a 74% robustness signal, compressed a meter's historical first-time read success or failure into one signal. That risk score was specified by IMServ, not by Creative Navy.

Option space mapping and constraint respecting forced fast convergence

Creative Navy's Critical Systems Design method appeared in compressed form through option space mapping, tension-driven reasoning and constraint respecting. The team explored dashboard layout, dark and light UI directions, featured statistics, assistant placement and login before convergence.

The active tensions were practical rather than abstract. The prototype needed broad screen coverage within a one-week sprint. The portfolio-tree component needed to work both as a hierarchy visualisation and as a navigation mechanism. The demo needed to show credible operational depth without attempting full product completeness.

The dark UI became the primary demo path. The documented driver was deadline pressure to commit to one direction, not a substantive aesthetic rationale. The assistant in the prototype was a help or chat assistant, not an AI feature; this case is therefore not evidence of AI product design.

Critical Systems Design phases remained recognisable under compression

Creative Navy's Critical Systems Design method was compressed rather than replaced in the IMServ engagement. Sandbox Experiments appeared as rapid domain learning and option space mapping across energy settlement concepts, dashboard structure, UI direction, assistant placement and login.

Concept Convergence appeared in the accelerated approval of the information hierarchy, the five-stage backbone, the dark UI path and the thirteen-screen demo scope against the 8 July deadline. Iterative System Building appeared in the navigable prototype, the repeated domain-accurate backbone across screens and the refinement of microinteractions.

Organizational Integration is the thinnest documented phase in this case. The case evidence refers to design-education rationale accompanying presentations and early recommendations on information hierarchy and main navigation, but it does not provide a concrete attributable example. Implementation Partnership is stronger: after the client-reported tender win, IMServ created an internal design team and Creative Navy supported that team over roughly 7 months toward independent operation.

Client-reported tender success and internal design capability followed the prototype

The known outcomes in the IMServ case are not measured user outcomes. Creative Navy-recorded engagement facts state that a clickable 13-screen prototype was delivered through a one-week build sprint after requirements settled. IMServ reported that it won the SSE tender; this tender outcome is client-reported and not independently verified in the case evidence.

After the tender, IMServ created an internal design team to build the real product. Creative Navy supported that team over a roughly 7-month Implementation Partnership. Peter McFord, product manager at IMServ, said: "Creative Navy have a solid foundation to build this ourselves now." The quote is client-reported, attributable by name and used here as evidence that the partnership reached the endpoint of independent operation by the client's own team, not as a quantified outcome metric.

Evidence boundaries for the IMServ case

The IMServ case should be read as a method-adaptability case with limited evidential weight compared with operational-redesign work that includes measured deployment or user outcomes. No usability testing was conducted. The prototype audience was buyers, not end users. The case evidence does not establish operational performance improvement in deployment.

The five-stage meter journey is domain-accurate and grounded in operational practice through kickoff and tender input, but it was not Creative Navy-observed field research. The ownership mapping combines a Creative Navy design proposal with IMServ-optimised detail. The per-MPAN risk score was client-specified. The client-reported tender win is not independently verified.

This case does not belong in AI product design clusters. The assistant in the prototype was a help or chat assistant, not an AI feature.