
Hospital Administration
As the main Product Designer at ConnectedCare, I led the design of the company's first web configuration system, giving hospitals a way to customize document requests and produce clear content for their patients. Since nothing like this existed yet, I owned the design strategy end to end: establishing the reusable patterns and architecture that later features would build on, and designing two distinct user flows, one for hospital staff, one for our internal content managers, that had to work together without stepping on each other.
- Company: BEWATEC ConnectedCare
- Role: Product Designer
- Timeline: April 2021
- Team: Product Manager, Product Designer, 3 Engineers, UX Researcher
Context & Problem
The core challenge of this project was to give hospitals and content managers configuration freedom (setting precedents for all future administrative tools) while ensuring patients encountered clear instructions.
The scope came with real limits: everything had to work without third-party integrations, support two languages from day one, and ship in two to three months. Given those constraints, I measured success simply: hitting the deadline, getting positive feedback from hospitals during beta, and keeping critical support tickets after launch as close to zero as possible.
User Research
Working with our UX researcher, I conducted stakeholder and customer interviews, identifying two primary user groups:
Hospital Administrative Staff
Front desk staff configuring patient document requests, often for the first time and without technical training. They needed to select the right documents and get through setup quickly, trusting they'd done it correctly, since a mistake here could delay a patient's admission. That's a lot of responsibility to hand someone during a rushed onboarding, which is exactly why keeping the interface simple mattered so much.
ConnectedCare Content Managers
Our internal team, responsible for translation and content accuracy across every hospital on the platform. Their problem was scale: reviewing documents efficiently across multiple hospitals, keeping a clear translation workflow, validating content before it ever reached a patient, and tracking which hospital was using which document version. Coordinating hospital-specific requirements while keeping translations accurate got harder with every new client we added.
Design Approach
Wireframing & Stakeholder Alignment
This feature required connecting our web application to our content management system (CMS), a technical challenge with multiple possible solutions, each affecting the UX differently. I realized right away that product, design, and engineering needed to align before we chose a path forward. I prepared a few wireframes and organized a workshop where we discussed competing priorities, reviewed user needs, evaluated the pros and cons of each approach, and agreed on a solution that worked for everyone.

I was particularly proud of this process as it not only solved the immediate challenge but established a cross-functional alignment framework we reused in future projects.
Design Critique

The technical solution enabled content managers to edit text directly in the web application, making the feature easy to find and use. However, managing multiple languages in a compact interface introduced risk of user error or confusion. To ensure I got this right, I brought the design team together for a thorough Design Critique session to establish interaction and navigation patterns that would scale across future features and prevent mistakes.
Final solution
The final design enabled hospitals to customize document requests without technical expertise while giving internal teams efficient tools to manage translations and content.
Configuration flow: it provided a clear entry point with on/off toggles, real-time patient preview, and confirmation steps to prevent errors.
Content management flow: it offered a dedicated translation tab with language selector, inline editing, character validation, and bulk actions for efficiency.
Key design principles: usage of scalable patterns for future features.

Results
The feature launched on schedule, and the response from hospital clients was positive both during beta and after release. The number I was proudest of was support tickets: zero critical tickets in the first 60 days. For a feature that put configuration in the hands of non-technical staff for the first time, that's the strongest signal I had that the simplicity we designed for actually worked.
What I Learned
- As this was the first configuration feature, every design decision carried extra weight. I learned the importance of thinking beyond the immediate feature to create patterns that would scale.
- The workshop format I developed proved highly effective at surfacing hidden constraints and building shared ownership. The key takeaway was that early and structured collaboration prevents expensive misalignment later.
- Our success metrics were relatively lightweight and very focused on launch timing and basic satisfaction. While we got positive outcomes, I saw the need for more rigorous UX metrics in future projects.