Helping Link Workers turn scattered follow-up records into usable client context and dashboard-readable data.
OPENING FRAME — LinkLog reframed as a service workflow, not only a dashboard.
I made this video to explain how LinkLog fits into a Link Worker’s day: reviewing priority, preparing client context, documenting the conversation, and preserving follow-up history.
Client details and follow-up records could live across spreadsheets, paper forms, phone notes, staff notes, SurveyMonkey, and worker memory.
Link Workers needed to know who was due for 3-, 6-, and 12-month follow-ups, what happened last time, and what mattered before the next call.
The work shifted from building a static dashboard to preserving client context across follow-up moments and staff handoffs.
Takeaway: Link Workers did not simply need another place to enter data. They needed a way to preserve the narrative context behind follow-ups while still producing structured information for reporting.
In a team sprint, I focused on the bridge between workflow, data, prototype behavior, and demo communication.
Barriers, preferences, programs, notes, and history — surfaced when they matter.
Sample records and interaction logs organized into stable fields.
Field mapping, status display, context filtering, demo-ready interactions.
A video walkthrough framing LinkLog inside a Link Worker’s real day.
This project was designed for the people behind social prescribing. It was not a direct app for older adults; it was a backstage workflow for the staff who keep follow-up, context, and reporting connected.
The blueprint helped us see that follow-up was not just a reminder problem. It was a continuity problem across notes, staff memory, reporting tools, and client context.
EVIDENCE 01 — Cropped current service blueprint, focused on follow-up lanes, data touchpoints, and continuity gaps.
They help prevent clients from dropping through cracks, while also encouraging continued participation.
Spreadsheet rows can preserve fields, but they do not make rich client context easy to find before a call.
Success in social prescribing can include social connection, confidence, routine, and qualitative progress.
Current-state synthesis helped separate scattered data from usable follow-up context. That distinction shaped the prototype priorities: priority queue, profile context, structured logging, and data migration.
The service needed to help Link Workers know who to contact, understand why, document what happened, and preserve that history for future follow-ups and reporting.
SIMPLIFIED FUTURE WORKFLOW — built from the future blueprint and demo flow, grouped into the three moments of a follow-up day.
This 8-step storyboard is the portfolio-facing communication artifact: it shows how LinkLog fits into the service day, from opening the dashboard and checking priority to reviewing context, calling the client, documenting the conversation, and updating progress.
Process note: earlier sketch boards and workflow thumbnails helped us test the order of the story, but they are supporting evidence rather than the main artifact.
The dashboard is one touchpoint. The larger system connects priority, context, documentation, and migration from existing records.
Existing Link Worker templates
AI-assisted Python script
Client + interaction CSVs
LIVE PROTOTYPE — HTML/CSS/JavaScript demo with CSV sample data. Prototype data is simulated.
The prototype was tested with 3 participants who had contextual familiarity in social prescribing, community coordination, and the Links2Wellbeing ecosystem.
One date field carried two meanings, every client looked equally urgent, and the state after a call was invisible.
Due vs scheduled became separate labeled fields, urgency reads at row level, and every follow-up lands in an explicit state.
Participants could not tell which client needed attention first.
Urgency, overdue status, and due windows became scannable at row level.
One date carried two meanings: required follow-up and booked call.
Due date and scheduled date are now separate, labeled fields.
After a call, the journey state of the client was unclear.
Completed, upcoming, no-answer, rescheduled, and discontinued states added.
Logging and profile context asked for everything at once.
Profile and interaction fields reorganized around the follow-up task.
Test with a small sample of 5 SALCs, validate the concept with Link Workers, and confirm minimum required data fields.
Onboard participating SALCs, refine dashboard priority logic, and improve interaction logging and timeline states.
Explore deeper client insight questions and strengthen reporting continuity across SALCs and OACAO.
Final takeaway: Service design is not only about improving touchpoints. It also means designing the backstage conditions that allow a service to work: data migration, staff handoff, context preservation, and reporting continuity.
Peer feedback reinforced that my contribution sat between service concept and implementation: technical alternatives during ambiguity, data migration, prototype feasibility, and demo storytelling.
“Solved our huge client problem of data migration.”
Opening problem: how do you make a serious public-safety topic approachable for children and youth?
