Philips Worklist Module.
One modular worklist for more than ten products that each had their own.
All Philips work is under NDA. Screens are replaced by redrawn diagrams.
The problem
The worklist is where a clinician starts after logging in: patient records, exams, studies. In some products it behaves like the home page. More than ten Philips products had their own worklist, in different design languages and with different patterns.
The call
We documented every feature of every worklist as a user story and compared them side by side. Features were ranked by how many products used them, and not by who asked first. Data table and prioritization appeared in six of seven products, so they went first, with cards and filter. Building a list from scratch, rules, AI-made lists and mobile were real needs in fewer products, so they waited.
The module
A system built like bricks. A shared basics layer every worklist builds on, auxiliary components that move across domains, and custom components for one domain. A product uses the pieces it needs, and not the whole set.
How we validated it
The first pack of features came from a workflow common to ten products. Design review, then a workshop with internal validation, an iteration, a second validation round, and a report, over five months.
What stayed after
The module was built to be used without its author. Documentation lived on the official Philips design language hub, with a Sketch library on GitHub, collaborative documentation in Confluence, an interactive prototype, a video on how to combine components, and the validation reports, open to every designer. Every month designers from other products sent new requests, and the backlog was reprioritised by commonality and urgency.
