Smile Solutions
Smile Solutions is a web portal that enables dental clinics to manage patient treatment progress and communicate with international patients throughout their care journey.
I inherited an early beta with fragmented patterns and underdeveloped workflows, then restructured the product based on user interviews and operational review to make it more consistent, usable, and ready for real clinic use.
Role
Product Designer
Timeline
Sep 2025 - Mar 2026
Scope
Product Strategy, UX/UI, User Interview, Quality Assurance
Smile Solutions deployed at iKang IDC DENTAL in Shanghai, China
OUTCOMES
3
Countries
23
Partner Clinics
6+
Treatment Offerings
RESEARCH
I approached the beta from two research angles: market context and real clinic feedback. Reviewing how existing dental SaaS tools balanced complexity and usability helped me clarify Smile Solutions’ positioning, while an in-depth interview with a partner clinic revealed where the experience still felt incomplete in practice.
Market Context
Dental SaaS tools are often feature-dense and operationally heavy. Products like Dentrix, Open Dental, and Dolphin support broad workflows, which often leads to dense interfaces.
Smile Solutions was positioned as a more focused and intuitive clinic tool. In its initial beta stage, however, this simplicity was mostly surface-level. The product’s underlying patterns were fragmented, and the core workflows weren't yet robust enough to handle the practical demands of a busy dental practice.
Dr. Yim | Seoul Clear Orthodontic Clinic
User Interview
To understand how the beta held up in real clinic settings, I conducted an in-depth interview with Dr. Yim, a partner clinic doctor. While he appreciated the product’s clean and approachable interface, especially compared with denser clinic management tools, the conversation also revealed two important gaps in the beta.
First, some clinic workflows depended too heavily on patient initiation. For example, clinics could not manually add patients from the B2B side and instead had to wait for patients to begin the process through the app. Second, although the company already had a B2C app, patient communication remained limited, with doctor notes reaching patients only at certain stages rather than supporting more continuous guidance throughout care.
Dr. Yim also suggested that the service would gain trust not simply by expanding to more clinics, but by becoming more dependable in everyday clinic practice. This made it clear that the B2B product needed to feel more operationally complete, supported by more useful patient communication through the connected app.
PROBLEM
Although the beta presented a clean and simplified interface, the interview revealed that several parts of the experience were not yet strong enough to support real adoption. Some workflows did not align naturally with existing clinic routines, the communication model did not fully reflect how clinics wanted to engage with patients, and the product’s simplified surface still lacked some of the operational structure needed to feel reliable in practice.
1. Clinic workflows depended heavily on patient initiation
Some core workflows were dependent on the patient side. In particular, clinics could not manually add patients from the B2B product and instead had to wait for patients to begin the process through the app. This made the workflow feel incomplete from the clinic’s perspective and reduced the product’s usefulness in day-to-day operations.
2. Patient communication was too limited to support ongoing care
Although the service already included a connected B2C app, doctor notes only reached patients at specific stages, which made the communication between clinics and patients uneven across the care journey. This limited the product’s ability to support patient care beyond individual visits and weakened the connection between the B2B and B2C experiences.
3. The product was not yet operationally complete
Treatment cards had to represent multiple note states and functions, yet were not always distinguished clearly enough. In addition, the appointments experience prioritized a simplified active view but did not fully support the broader scheduling context needed by staff or more complex clinic structures such as multi-doctor environments. As a result, the product felt visually clean, but not always dependable enough for real operational use.
How might we preserve the clarity of a simple interface while strengthening
the workflow logic, consistency, and operational depth behind it?
DESIGN STRATEGY
Make repeated patterns
more predictable and consistent
Some shared elements appeared across multiple pages in slightly different forms. I focused on aligning them more closely in both appearance and behavior to reduce relearning across screens and make the product feel more coherent as a system.
Keep the interface simple,
but not incomplete
A clean interface should not come at the cost of clarity. I focused on making the product feel lightweight without leaving gaps that made certain screens or content areas feel missing or unresolved.
Support different operational needs
without overcomplicating the UI
Doctors, staff, and clinic structures did not always require the same level of visibility or coordination. I focused on keeping the interface clear while allowing the product to support more complex operational needs when necessary.
Strengthen the product
beyond the UI layer
The beta’s issues were not only visible in the interface, but also in the underlying design structure. I aimed to clarify fragmented flows, resolve logic gaps, and build a more organized foundation for scalable design and cleaner handoff.
