Jones Radiology is a doctor-owned Adelaide radiology practice running clinics across metropolitan Adelaide, the Adelaide CBD, regional South Australia and Alice Springs, offering diagnostic and interventional imaging from X-ray and ultrasound through to MRI, nuclear medicine and PET. Giving referrers a single place to track requests and receive reports and imaging touches clinical workflow and patient data, which makes it an expensive thing to get wrong. The product model had to be settled before a production build, and several of the data integrations it would eventually depend on were not yet available.
Jones Radiology
A working prototype first, so the hard decisions were made before the expensive ones.
Proving the product before committing to it
Jones Radiology set out to give referring clinicians and practices a clearer view of the imaging they order. PixelForce delivered the engagement in two deliberate stages - a clickable desktop prototype running on simulated data, then a proof of concept wired to real back-end integrations - so the product model could be tested and corrected before a full production build was committed to.
Delivery stages 2
MVP scope 6 feature areas
Alongside the build 2 documents
The Problem
The Solution
PixelForce structured the work as a prototyping stage followed by a proof of concept. The first stage produced a clickable, production-like desktop interface driven entirely by simulated data responses, which let the whole minimum viable product scope be walked through and reviewed without waiting on integrations. The second stage built the back-end behind that interface, ingesting Jones Radiology data and implementing the API calls and business rules the front end needed.
The Outcome
Jones Radiology finished the engagement with a reviewed and iterated prototype, a working proof of concept on real data, a phased product roadmap for the releases beyond the MVP, and a technical security review covering the recommended security layers and how to test and maintain them over the product's life. The value of the sequence is that the design direction and the scope were both argued out against something clickable rather than against a document.
Why this was built in two stages
Jones Radiology is doctor owned and operated, based in Adelaide, and provides a comprehensive range of diagnostic and interventional radiology from clinics across metropolitan Adelaide, the Adelaide CBD, regional South Australia and Alice Springs. Its referrers are general practitioners, specialists and practices who order imaging and then need to know where each request is up to and to get the report and images back promptly. The ambition was a digital product that made that whole loop more transparent for the referrer and, through them, for the patient.
The difficulty was not the interface. It was that a product of this kind sits on top of clinical systems and patient data, and at the point the engagement began several of the integrations it would ultimately rely on were not available to build against. Committing straight to a production build would have meant making the important product decisions on paper and discovering the consequences late. PixelForce proposed the opposite order: build something clickable that behaves like the real product, use it to settle the scope and the design direction, and only then build the back-end underneath it.
A high-consequence domain
The product sits on clinical workflow and patient data. Getting the model wrong is not a cosmetic problem, so it needed to be tested before it was committed to.
Integrations were not ready
Several of the data integrations the product would depend on were unavailable at the start. The prototype ran on simulated responses so scope review did not have to wait for them.
Desktop only, on purpose
Referrers work at a workstation. Tablet and mobile responsiveness was deliberately excluded from these stages so the core model could be proven without spreading the scope.
Decisions needed a target
Design direction was signed off against high-fidelity concepts with a set allowance of revision rounds, rather than being negotiated indefinitely during the build.
Both organisations are Adelaide based, and the engagement ran with a named project manager on each side. Because clinical products attract a wide stakeholder group, the schedule gave each deliverable a start date, a due date and an owner, and review was scheduled as a defined window rather than left open. Changes were handled through an explicit process: PixelForce assessed each request against plan and budget, said plainly whether it was absorbable or impactful, and did no work on an impactful change until Jones Radiology had decided whether to proceed or park it.
Hinney Lo Founder & CEO, PixelForce
A prototype is not a picture of the product, it is an argument about the product that somebody can push back on. Spending four weeks making that argument clickable is far cheaper than discovering halfway through a production build that the model was wrong.
Swipe to explore
How the engagement ran
The engagement opened with design and scope finalisation. PixelForce produced additional high-fidelity dashboard concepts specifically to test whether the proposed design direction was the right one, and that direction was signed off with a defined allowance of two revision rounds before any build work started. The Statement of Work was signed off in the same stage, alongside tech stack documentation. This is the same discipline the development side of the business runs on - the blueprint is agreed before the build, and no build estimate is issued without one.
Stage two produced the prototype: a clickable, front-end-driven desktop interface covering the full agreed MVP scope. That scope was specific - onboarding for both clinicians and practices, landing pages for users, tracking requests for services, delivery of reports and imaging, exception handling, and an internal Jones Radiology dashboard with user and practice management. Because there was no database or live integration behind it, interactions returned simulated data responses, which is what allowed a production-like walkthrough while the real integrations were still pending. Desktop-only was a deliberate scope decision rather than an omission: referrers do this work at a workstation, and tablet and mobile responsiveness was explicitly held out of this stage so the core model could be proven first.
Stage three turned it into a proof of concept. PixelForce built the back-end elements, ingested the Jones Radiology data needed to drive the product, implemented the API calls supporting the front-end display, and applied the business rules for the defined scope. It then moved through visual, functional and regression testing, followed by a user acceptance testing period in which Jones Radiology raised defects and enhancements that were prioritised and actioned jointly. Two further documents were delivered alongside the build for internal Jones Radiology use: a phased product roadmap for the functional uplifts to follow as data and integrations became available, and a technical security review setting out the recommended security layers and how security should be tested and maintained across the life of the product.
Prototype, then proof of concept
One agreed scope across both stages.
Simulated data first. Real integrations second. Production decisions last.
- Design direction
- Clickable prototype
- Proof of concept
- Testing and acceptance
- Product roadmap
- Technical security review
01 06
Design direction
Additional dashboard screens were uplifted into high fidelity for the specific purpose of testing whether the design direction was right. Sign-off came with a defined allowance of two revision rounds, so the decision had a boundary.
02 06
Clickable prototype
A production-like desktop interface covering the whole agreed MVP scope, driven by the front end. User interactions returned simulated data responses, with no database or live API behind them, which is what let it be reviewed while integrations were still pending.
03 06
Proof of concept
The back-end behind the prototype: ingesting the Jones Radiology data needed to drive the product, API development for the calls the interface required, and applying the business rules for the defined scope.
04 06
Testing and acceptance
Structured quality assurance across three passes: visual testing against the design, functional testing against expected behaviour, and regression testing to protect existing features. Jones Radiology then ran a user acceptance window, raising defects and enhancements that were prioritised and actioned together.
05 06
Product roadmap
A phased view of the releases beyond the MVP, sequencing functional uplifts against the point at which data and integrations would realistically become available. Delivered as an internal planning document.
06 06
Technical security review
A document setting out the security layers PixelForce recommended for the product, its environments and the underlying data, together with recommendations on how security should be tested and maintained over the life of the product.
Services in the Jones Radiology engagement
Frequently Asked Questions
Two build stages and two documents. A clickable desktop prototype covering the agreed MVP scope on simulated data, then a proof of concept with the back-end integrations, API calls and business rules behind it. Alongside those, a phased product roadmap and a technical security review, both for internal Jones Radiology use.
A prototype demonstrates the interface and the flow. It looks and behaves like the product but the data is simulated, so it answers questions about the design and the scope. A proof of concept puts real working machinery behind that interface - data ingestion, API calls, business rules - so it answers whether the thing can actually be built and behave correctly on real data.
Because changing a decision in a prototype costs a fraction of changing it mid-build. Making the interface clickable turns the scope into something a stakeholder can push back on, which surfaces disagreement early. For a product touching clinical workflow, that is the cheapest risk reduction available.
By simulating the responses. The prototype was driven from the front end and returned mocked data for each user-driven interaction, with no database or live API behind it. That decoupling meant the product model could be reviewed and corrected on schedule rather than waiting on third-party integration availability.
It was a deliberate scope decision. Referring clinicians and practice staff do this work at a workstation, so desktop was where the model needed to be proven. Tablet and mobile responsiveness was explicitly excluded from these stages so effort went into the core product rather than into breadth.
Security is documented as a deliverable rather than assumed. This engagement included a technical security review covering the layers recommended to prevent unauthorised access to the product, its technical environments and the underlying data, plus recommendations for how security should be tested and maintained as the product changes over time.
The roadmap takes over. The proof of concept establishes the foundation and proves the model on real data, and the phased roadmap sequences the functional uplifts that follow as further data and integrations become available, informed by user feedback from the acceptance stage.
Up next
More products we have designed, built and launched end to end.
Move With Us From Technical Debt to a Platform Built to Scale
PixelForce rescued and modernised Move With Us, Rachel Dillon's cross-platform fitness app, reducing technical debt for a faster, more stable platform.
Traininpink Italy's number one, built for women
PixelForce built Traininpink, Italy's number one female-focused Pilates and fitness app, serving over 182,000 women and 40,000+ paying subscribers since 2021.