Why a general patient profile is not enough

In a typical medical record, the primary object is often a diagnosis or a visit. In dentistry, clinicians work within a different coordinate system: a specific tooth, its surfaces, its condition, completed treatment, and the next planned action.

Without a dedicated module, this information becomes text notes or separate records that are difficult to connect back to the patient’s actual dental condition. I therefore structured the concept around the odontogram—the natural entry point into a dentist’s clinical workflow.

From the visual map to clinical detail

Selecting a tooth opens its context: condition, diagnoses, planned procedures, and treatment history. For cases where the exact location of a condition or intervention matters, the interface supports work with tooth surfaces—buccal, mesial, distal, palatal, and others.

This lets clinicians move quickly from the overall dental picture to an accurate clinical record without losing the connection between data and the specific treatment target.

A treatment plan that remains connected to history

Dental treatment often happens in stages: some conditions are monitored, some procedures are planned, and others have already been completed. The concept separates these states into clear blocks—Monitoring, Planned, and Treatment Plan.

Clinicians can see which actions relate to a particular tooth, what has already been prescribed, and where the treatment currently stands. This supports both accurate documentation and continuity of care during follow-up appointments.

Linking the clinical workflow to daily clinic operations

The module goes beyond the odontogram. The concept also covers scheduling, patient lists, the service register, treatment plans, invoices, and access to DICOM data. This connects the clinical record with the day-to-day tasks of a dental practice: appointments, services delivered, imaging, and billing.

The goal was not to create a separate system inside the EHR, but to embed the dental workflow into the familiar structure of medical documentation.

Outcome

I created a design concept that gave the ARMED development team a direction for a future dental module. Rather than adapting a generic patient page, it proposes a professional workflow built around how dentists actually assess, plan, and document treatment.

‍

Context

Treatment protocols are the standard doctors are meant to follow for a given diagnosis. They used to be drafted and approved centrally, distributed as documents, and doctors had to follow them from memory or with the document on hand. Good idea, weak execution: there's no realistic way to verify protocol compliance across thousands of doctors by hand.

The problem

Digitizing protocols usually solved the wrong problem. Drafting, approval, and distribution turned into an archive of doc files — the same hassle as paper, just in a different format. And even a finished protocol stayed a document full of text and diagrams, hard to parse quickly during an appointment where a decision needs to happen in a couple of minutes, let alone memorize.

But the real gap wasn't the document format — it was oversight. Whether a doctor actually follows a protocol tends to surface only after the fact, and usually only in severe cases, once a deviation has already harmed a patient. The rest of the time, every doctor treats however they see fit in the moment, and there's simply no statistics on how well any given protocol actually performs. Add navigation on top of that — finding the right protocol among hundreds of published ones — and you get a system with rules that exist, but with no way to check whether they're followed or improve them based on data.

‍

‍

The solution — a protocol becomes a condition, not a document

The EMR already logs everything happening to a patient: labs, measurements, medications, procedures. That made it possible to build a protocol not as text to read, but as a sequence of steps, each of which can be checked automatically — whether a patient's indicator falls inside the required range or not. The solution has two connected scenarios — building a protocol and searching for one — plus a third layer, compliance tracking, which runs statistics based on what actually happens to real patients.

Building: diagnosis, metrics, activation conditions

A specialist starts by picking a diagnosis. On the right, a list of relevant patient indicators appears — AI suggests the metrics most relevant to that diagnosis, while the doctor still enters the actual threshold values. You can also search for an indicator manually if it's not among the suggestions.

On the left, alongside the primary diagnosis, you can add a secondary one and set a demographic group — because the same diagnosis is treated differently in an infant, an elderly patient, or a pregnant woman, and some protocols simply shouldn't trigger at all — for men, for instance.

The point of this step isn't just a checklist of indicators. The chosen metrics become the condition under which a specific protocol activates for a patient in the system. Roughly: if temperature is above 38 and AST is above a set value, the system will surface protocol #X, stage Y, variant Z to the doctor — not some other one. The protocol finds the patient, not the other way around.

‍

Treatment plan: a step builder

Next, the specialist assembles the plan itself via "Add Item" — step by step, of any type: medication, procedure, measurement, note. Each step has a type (color-coded for quick visual scanning), a sequence number, and a trigger condition — run at the same time as another step, or a set number of days after it.

If a step is a measurement, it has a separate toggle: on — the result of that measurement becomes a condition for continuing the plan (or for breaking it off, if the result falls outside the range); off — the measurement just needs to be taken as part of the protocol, but doesn't affect the course of treatment.

At the top of the builder, the whole plan is shown as a visual timeline: while the details of each step are configured below, the overview above shows at a glance what follows what and how it all connects. Once the plan is ready, the protocol gets published and goes into moderation — faster than the old path through ministry approval, but essentially the same check before it becomes available to doctors.

‍

Search: find a protocol by parameters, not by browsing an archive

The second scenario is finding the right protocol among the ones already published, without digging through the whole database. Pick a diagnosis, and every protocol and treatment stage for it appears on the right. To narrow things down, specific patient or case parameters can be set on the left — the more parameters entered, the more precise the result. It also works the other way: enter a patient's indicators and see which protocols match them.

Inside each protocol found this way is the same visual timeline on top, and a detailed, non-editable list of steps below, laid out for quick reading during an appointment.

‍

Compliance — the whole point of building this

This part isn't in the mockups — it lives in other modules of the system — but it's what makes the rest of it meaningful. Since every protocol step is a checkable condition, the system generates statistics: how effective a given treatment plan actually is, and how quickly that becomes clear — not through slow bureaucratic cycles, but close to real time.

Second, it produces data on adherence: if a protocol calls for paracetamol at a given step, and a doctor consistently prescribes ibuprofen instead, that gets logged as a mismatch. A one-off deviation is just a doctor's judgment call in the moment. A systematic deviation at the same step across many doctors is a signal that the problem isn't the doctor — it's the protocol itself, and it's worth revisiting.

Versioning is built so it doesn't put patients already in treatment at risk: if a protocol is updated, a patient already on the old version stays on it — the new version only picks up new patients going forward. And because this operates at the national level, roles and access rights — who drafts, who approves, who moderates publication — are all handled inside the platform itself; the entire approval cycle for a protocol never leaves the system.

‍

Context

I spent several years designing Armenia's national EMR system. Project under NDA, below are a few modules from that project that out of NDA.

Epicrisis — by clicking, not typing

A unique solution: the doctor builds an epicrisis document by clicking through pre-set options instead of typing it out by hand — saving time at every appointment.

‍

Medical history

Medical history is organized as a lifetime list for the patient, filterable by keyword, period, specialty, and medical institution. Any visit can be expanded to view attached documents, or a new one added — to the current visit or a past one.

Patient snapshot

One screen brings together the essentials: allergies, current medications, chronic conditions, vaccination status, tasks, and upcoming visits — no need to jump between sections to get the full picture.

Insurance integration

The system integrates directly with insurance companies: insurers have their own portal within the system, where they can see request status and diagnosis.

‍

Context

This is the second version of the medical history module for the same national EMR. The first one (see the companion case) covered the basics — showing patient data the familiar way: lists, documents, filters. Nothing wrong with that approach, except it has a ceiling: a doctor will conscientiously read the last 2-3 records, and then either the appointment runs out of time, or they start skimming on the assumption that "there's probably nothing important further back."

The problem — overview, not storage

EMR systems got pretty good at storing data — everything digitized, structured, filed away. Managing that pile, and actually reviewing it, turned out to be just as impossible as it was with paper charts. The issue isn't a lack of data. It's that after a few years there's so much of it that seeing the full picture means paging through a thick folder cover to cover.

Which leads to the second half of the problem: something from a patient's past can genuinely affect what's happening now — and nobody will spot the connection if it's buried on page forty of the chart. The patient might not mention it (forgot, didn't think it mattered), and the doctor won't ask, because there's no cue to ask about. A simple example: a patient comes in with knee arthritis, and a few years earlier had an injury or surgery on that same knee. The connection is obvious to a doctor — if they know about it. If not, it just doesn't happen.

And separately — there's no way to see chronic conditions in motion over time. Which is a problem, because a condition is chronic precisely because it plays out over years; without a way to trace that arc, tracking it in the first place loses its point.

‍

The solution — a screen that works both up close and from a distance

The timeline works as a single tool with variable zoom: collapse several years into an overview, or expand a single day into an hour-by-hour breakdown of a visit. Spot a pattern — zoom in. Need a specific hour — you're there, no screens in between.

Chronic diagnoses surface on their own

This is a national EMR — by law, every encounter runs through the system with an ICD-10/11 diagnosis attached. If the diagnosis is chronic, everything tied to it — labs, prescriptions, follow-up visits — automatically lands on that condition's timeline. The doctor doesn't have to look for anything; the system already gathered it. Need an indicator outside the context of a chronic diagnosis? Add it manually — everything done without a diagnosis attached sits in its own feed below.

Lab data — its own territory

Lab indicators live below the main event feed, not mixed in with visits and prescriptions, because they follow a different logic. A doctor can stack several indicators at once and watch whether they correlate, when tests are regular and the condition is chronic. An arrow marks a deviation from the norm; a click expands into a trend graph.

Medication — on request, not by default

Hidden behind a toggle. Not because it doesn't matter, but because most of the time a doctor needs to know what's going on with the patient now, not the list of what they've been taking. But if you want to see whether a treatment worked, or line up a medication against lab results — one click, and it sits right next to the rest of the data.

‍

‍

Context: CME should fit into clinical life

Continuing Medical Education is necessary for maintaining professional qualifications, but traditional formats - courses, tests, online lectures, or conferences - often require dedicated time and attention outside clinical work.

The goal was to create a flexible platform that could adapt to different markets. Doctors should be able to learn in short sessions, focus on relevant specialties, and work toward their required CME credits at their own pace.

The challenge: make learning valuable without making it overwhelming

The core UX challenge was finding the right balance. If the experience is too simple, medical learning becomes a superficial quiz. If it is too complex, it becomes difficult to use regularly on a mobile device.

The solution was to gradually increase independence: first, the system helps doctors understand a diagnostic path; then it lets them assess their knowledge in conditions closer to real clinical decision-making.

Learning through clinical reasoning, not content consumption

In Education Mode, doctors work with a virtual patient: they review symptoms, select examinations, and form diagnostic hypotheses. The AI guides them through the case, explaining which actions are more informative and why.

This mode does not award CME credits. Its purpose is to build confidence and understanding before users move to assessment. Doctors unlock Examination Mode after completing ten learning cases.

Incorrect diagnoses from Examination Mode are saved as weak areas. Doctors can return to them later and practise similar scenarios, turning mistakes into targeted learning opportunities.

‍

Assessment with adjustable levels of challenge

Examination Mode turns learning into an independent knowledge check. Before starting a case, doctors choose a difficulty level, which determines the amount of system guidance and the potential reward.

In Easy Mode, the AI provides detailed hints and shows the priority of available actions. In Normal Mode, doctors see the available options but must decide which examination will move them closer to a diagnosis. In Professional Mode, there are no hints: doctors independently select the next diagnostic step from the full range of options.

Difficulty is therefore not a hidden barrier, but an intentional choice. Doctors can begin with support, gradually become more independent, and earn more points for successfully completing harder cases.

Progress connected to a professional goal

The platform connects every practice session to visible progress. Doctors set the number of CME credits they need, earn points through examination cases, and convert those points into credits.

Once they have reached their goal, they can request official confirmation through an accredited organisation, which issues the CME certificate.

The home screen brings the full journey together: completed learning and examination cases, earned points, CME credits, and progress toward the goal.

‍

‍

What makes the solution different

The product does not treat CME as a separate administrative task or a sequence of quick tests. It makes clinical reasoning the central learning mechanism: every case is built around decisions, consequences, and explanations.

With AI-guided scenarios, specialty-based learning, weak-area practice, and adjustable independence levels, CME becomes a recurring clinical practice rather than an obligation doctors need to make extra time for.

‍

Context

The mobile app for patients is part of a larger telemedicine platform project. This case study focuses solely on the patient-facing, B2C component; the doctor-facing side operates quite differently (via WhatsApp, without a separate app—more on that below) and is not included in this case study.

Problem

The first appointment with a doctor usually doesn’t solve the problem itself—it’s about gathering information and ordering tests, while the actual work on the diagnosis begins at the second visit. Time is wasted traveling to and waiting for the first appointment, and this appointment generally does not yield a specific result. Meanwhile, the doctor’s time between appointments and outside of working hours goes unused, even though it could be generating revenue.

Value Goes Beyond the First Visit

For the patient, this isn’t just a “consultation without a visit”—it’s also about finding the right doctor from the very first step. If a patient isn’t sure which specialist they need, an AI questionnaire based on symptom descriptions automatically determines the specialty—allowing them to see the right doctor right away, bypassing the general practitioner as an intermediary who is usually needed only for a referral.

For the clinic and the doctor, the benefits work both ways. First, monetizing downtime—free hours between appointments or outside of working hours—turns into additional income without having to install any software. Second—and this applies to regular in-person visits as well—the same AI questionnaire, completed in advance, shortens a typical appointment by 20–30 minutes: the doctor doesn’t waste time on basic questions but gets straight to the details. This means more patients in the same amount of time and a higher-quality consultation—the doctor focuses on diagnosis rather than asking questions.

‍

Three entry points, one and the same preparation

A patient may not know which doctor they need—in that case, the AI uses the questionnaire to determine the necessary specialty and compiles a list of suitable doctors. If they know exactly which doctor they want to see, they can select a doctor directly from the directory, but the AI still collects the same questionnaire before the conversation begins. And if the patient is already physically at the clinic—they scan a QR code at the reception desk, enter their appointment number, and complete the same questionnaire while waiting for their turn—and by the time of the in-person appointment, the doctor already has the prepared summary in front of them.

Next comes the request to the doctor, confirmation from the doctor, payment, and access to the chat is granted. Intermediate states (waiting for confirmation, waiting for payment, payment failed, doctor not found in the system) are handled as separate statuses that are clear to the patient.

The doctor is on WhatsApp, not in a separate app

Doctors don’t install this app at all: all requests come to them via a WhatsApp bot. This is a deliberate decision—clinics typically dislike the idea of implementing new software or paying for integration, and a familiar messaging app completely removes this barrier. All the clinic needs to do is provide doctors with a link—once they’ve filled out their profile, they can start working right away, without needing to integrate with the clinic’s EMR/EHR system (and every clinic has its own unique mix of such systems). We charge a percentage of each visit, rather than a setup fee.

Consultations with a Clear End Point

A doctor can request photos or documents from a patient directly in the chat, ask follow-up questions, and order additional tests. Upon completion, the patient receives two documents: the Clinical Summary—a comprehensive clinical version for the medical record—and the Patient Summary—the same information in plain language, including test results. Plus, the final diagnosis, prescribed treatment, and a downloadable PDF note.

After that, a countdown begins; once it ends, the session cannot be continued with a new question. There is also a separate assessment of the doctor’s response speed—in an asynchronous text format, this is the only tangible quality metric that would otherwise go unnoticed.

‍

Context

A telehealth platform: patients get asynchronous consultations through a mobile app, doctors work out of a WhatsApp bot. This part of the project is what sits behind the scenes and makes the business manageable.

How the franchise works

Master registrant — the company that owns the product. Provides the software and the environment, takes a percentage.

Local registrant — a partner in a specific country. Signs an agreement, gets a dashboard, and from there finds and onboards clinics in their own market. Lives off a percentage of their visits.

Network — a clinic or a group of clinics with branches. Brings on its own doctors, earns from consultations.

Money travels up the same ladder. And that's where the real problem starts: all three tiers have completely different motivations, and one interface has to serve all of them without turning into three separate products.

Each tier asks a different question

The product owner doesn't need to manage doctors — they need to know which partners are growing and which are stalling and need attention. It's a "where is my business working, and where isn't it" question, at the scale of countries and networks.

The local partner looks at the same data with a different interest: they want to earn more. So what's front and center for them isn't just cash flow, but the things that directly drive their income — which networks are underperforming and need help, and which specialties are missing, so patients don't leave without finding the right doctor.

Hence the decision to put a network's performance right next to its revenue and commission, and to lift quick filters ("needs attention", "top performers") above the table rather than burying them in reports. A partner loses money alongside a clinic that signed up and never took off — so "who needs help" has to be as visible as "who's paying".

The same logic applies to specialty coverage: uncovered specialties are flagged explicitly against the system's fixed directory of sixteen, because every one of those gaps is a patient who couldn't find a doctor and left. For a partner, that's literally a list of who to recruit next.

A clinic isn't going to live in this interface — it has its own EMR, its own processes, its own working day. It'll log in once a month. And that single visit has to land.

So the scenario everything is built around is fairly blunt: log in, see that the app is actually bringing in money (which you half-doubted when you signed the agreement). Drill into the doctors section, notice one doctor with a poor rating and slow response times — meaning the network isn't earning on them. Draw conclusions.

That's where the decisions in the doctor list come from: average response time sits at list level alongside revenue (in an asynchronous format, it's the primary signal of quality), and the view itself toggles between cards and a table — cards when you're looking at specific people, a table when there are many doctors and the job is to compare and sort.

‍

‍

Zero implementation

The core condition of the whole model: the clinic implements nothing. No integration with whatever EMR the network already runs — and they all run different ones. Doctors install no apps: the clinic enters a phone number, the doctor gets a WhatsApp link, fills in their own profile, and shows up in the admin panel with their data already in place. No manager has to fill it in for them or reconcile it afterward.

For the QR-code-at-the-front-desk scenario, a receptionist account is set up separately with the same bot attached — again, no extra software inside the clinic.

‍

Context

By that point, Klinika already had an ecosystem: an EMR system used by clinics and a mobile application for patients. The app had become outdated — I designed it more than five years ago, and the product had outgrown it. The decision was to build a web version of the marketplace with a redesigned UX, then use it as the basis for a PWA and replace the old app entirely.

So this is a web case designed as a mobile product from day one.

‍

Finding and booking a doctor

Three appointment formats — in-clinic, at home, telehealth — are chosen through a single tab above the results, not three separate sections. Inside: specialties, promoted doctor slots, a doctor list with price and nearest slot, and a filter panel on the right for specialty, gender, rating, and appointment time.

A single booking row surfaces several decision points at once: doctor name, clinic, price, rating, and nearest available time — so the patient compares options across every factor that matters right there in the list, without opening each doctor's card individually. That matters especially on desktop, where the screen allows a dozen options to stay in view at once, instead of being paged through one at a time as in the mobile app.

Laboratory: local shortages get solved on the spot

The tension. A smaller city may have few tests and clinics available, and a rigid tie to the current city leaves the patient staring at an empty result set.

The decision. The system defaults to results in the patient's own city — searching the whole country is usually overkill — but when supply is thin, it offers a quick switch to a neighboring city through a single popup: "show results for Riyadh?", without forcing the patient to reconfigure the search from scratch.

What the business gets. A patient in a smaller city doesn't hit a dead end and leave the platform — they get a choice, stay local or widen the search, while staying inside the product either way.

Separately, there are two distinct browsing modes within this one vertical: individual tests go into a cart (the same "list first, clinic second" logic as before), while packages are browsed differently — as a card with an expandable parameter list and a visible price and count of matching clinics right away ("from 323 SAR," "select clinic (9)"). That's a deliberate split: a package gets decided on price and composition alone, while individual tests only get decided once the patient sees which clinic covers their full list.

Offers: a revenue tool for the clinic, not just a discount feed

A full offers page with filters by category, city, age, gender, and price — and a dedicated detail card showing the full composition of an offer (lab tests, an in-clinic visit, nursing services), broken down by category with the total savings shown.

The point of this section isn't the discount itself, but that it gives the clinic a revenue tool: bundling services at a discount sells more per patient visit than separate bookings would — the same mechanic that already worked in the mobile app, now carried over to the web with desktop search traffic in mind, where offers compete not with other app screens but with Google results.

Personal account: visit status visible without opening anything

The visit list shows status right in the row, with no need to open each entry: paid, "call starts in 12 hours," a countdown while waiting for the doctor, "doctor was unable to connect" with a direct link to reschedule, a "join video call" button exactly when it's relevant. Past visits offer a review right from the list.

Lab results are consolidated into a table with city/clinic/date columns and a deviation status — normal, minor, major, no data — and a single indicator can be tracked over time even if it was taken at different clinics. The medication section separates active prescriptions (with a "start intake" button) from history, without mixing the two.

Privacy and control: clinic access is the patient's call

Information Permissions — a dedicated screen where the patient toggles a specific clinic's access to their data, one switch per clinic. This came as a regulatory requirement rather than a product initiative, but it's built so the patient controls access granularly, rather than choosing between "allow everyone" or "don't use the service."

Notifications carry actions, not just text. A clinic rescheduled the visit — accept or decline right in the notification card. A visit wasn't paid and got cancelled — the status is visible immediately. This turns the notification feed into a working list of decisions rather than an archive of things that already happened without the patient's input.

Separately, chat with doctors and the patient's own review list sit in the same account section as settings: both the conversation and the feedback stay part of the personal space, rather than a separate module reached through another menu.

An entry point for clinics, sitting inside patient traffic

The tension. The classic way to bring clinics on board is a separate landing page and a separate marketing campaign — one that never overlaps with the traffic the platform is already getting from patients.

The decision. The "become a partner" form is embedded directly into consumer-facing pages — the homepage and category pages — rather than hidden away on a separate B2B site.

What the business gets. Every patient who scrolls to the bottom of a page is a potential lead for clinic signups: staff at a clinic who happen to search for a doctor through the marketplace themselves see the signup form right there. No separate marketing budget is needed to acquire clinics — B2C traffic drives B2B conversion for free.

‍

A clinic gets a website, not a listing

A typical marketplace gives a seller a profile inside itself: photo, description, reviews, and that's it. A clinic that already runs its own website either maintains two places at once, or, if it has no site at all, has nowhere to present itself beyond a card in a general list.

The solution here works differently: a clinic's page is generated automatically from a template, using the same data already in the system — services, doctors, offers, branches, a map. And if the clinic is a client of the product, this page can serve as its own website: all booking, live data, and integrations pull directly from the core platform, with no separate development on the clinic's side.

This changes the economics of the offer for a clinic: signing up with Klinika delivers not just a sales channel, but a ready website that doesn't need separate upkeep. For the marketplace, it's a strong argument when selling the connection — not "list with us," but "get a website for free along with the signup."

Inside the page, the same principles apply as everywhere else in the product: filters by age, gender, rating, and price work the same whether searching for a doctor or for a service within a specific clinic, and the service-type switcher (laboratory, test packages, radiology, nursing, physical therapy) behaves like a self-contained mini-catalog within one clinic.

In summary

The web platform reuses the same data and booking logic that already worked in the mobile app, but adds what a mobile format couldn't deliver in principle: a full website for every clinic, lead generation built into consumer traffic, and responsiveness across three device classes from a single design codebase.

‍

What the client brought in

The idea was simple: show ads on the lock screen through wallpapers the user installs, and pay them for it.

The analysis: why the idea didn't work

I broke the proposal down and found two problems that made it unviable as a business.

First, showing ads on the lock screen depends on OS-level behavior — something the platform doesn't control and that Apple or Android can restrict with any update. Building a business model on access that isn't yours to guarantee is risky from day one.

Second, and this was a separate, standalone pain point: wallpapers have to be installed manually, and the platform has no way to verify whether they stay active after installation, let alone control it. Changing a wallpaper isn't the kind of action a person will repeat regularly for a modest reward.

The solution: a new channel instead of a fixed format

I proposed the client sell the same product — advertising with a user reward — through a different channel: an interactive widget on the phone's home screen.

The widget solved both problems at once. It doesn't depend on system permissions that can disappear with an OS update, unlike the lock screen. And it doesn't require a repeated manual action — install it once and it just runs, unlike swapping wallpapers. For the user, it's a clear activation point: install it, test it, see whether it's active. For the platform, it's a manageable and far more reliable signal than a one-time wallpaper install.

The presentation: to make the idea tangible

Before getting into technical detail, I put together a presentation that frames the solution as a story, not a feature list: what's wrong with traditional advertising (banner blindness, ads that get skipped and never seen), and what the alternative looks like — advertising as part of the experience, something the user gets value for, instead of a fight for attention everyone already hates. This was needed so the client and their team bought into the idea itself before digging into how it worked underneath.

Functional maps: a development plan, not a feature list

Next I broke the product down by stage — from what could be tested cheaply to the full vision.

PoC — a version to test the hypothesis itself, before any production code: just two roles, Stakeholder and User. The user installs the widget and gets paid out to their card once a month. The stakeholder manually offers the new format to an advertiser for free, collects the materials, assembles the ad themselves in their own panel, and after the campaign ends, reports back and gathers feedback — signing an agreement only if the advertiser is happy with the results. A cheap way to find out whether advertisers would even pay for a channel like this.

MVP — the next stage, meant to bring in first revenue without overspending on development. The same functional map, but with an explicit note on every block: what gets simplified, and what doesn't make it into this version at all.

‍

Full Scale Solution — the plan to work toward: widget customization, A/B testing for ads, fraud detection, automated pre-moderation.

For every block, I explained why it didn't belong at that stage — and that's what gave the client the sense of an actual development plan, not just a pretty picture of the maximum possible. Separately on the map is an Ideas: how can be improved block, where every future feature comes with a stated "why" attached, so it doesn't read as a wishlist.

User flows: so the client could see the future processes

Before drawing a single screen, I wrote out step-by-step scenarios for all four roles — four to five flows per role.

For the user — registration and widget setup, earning and requesting a payout, interacting with a specific ad, customization, contacting support. For the advertiser — creating a campaign, monitoring performance, editing an active campaign, managing team access.

The moderator and the stakeholder got the same level of detail as the user. Moderator: reviewing a new ad submission, answering an advertiser's question about a rejection, flagging suspicious activity (15,000 impressions in one hour from a single user, a clear bot signal), a future scenario for bulk approval through automated moderation. Stakeholder: adding a client, reviewing overdue payments, processing payouts in batches, assessing business growth, and — tellingly — backup moderation, where the stakeholder clears the queue themselves if the moderator falls behind.

Without these flows, the client would have seen only a nice-looking app for the user — and a two-sided advertising marketplace with underdeveloped internal processes doesn't work, no matter how much money goes into it.

‍

Mockups: visual support, not final design

Only after all of this did I move to screens. In a workshop setting, I always keep mockups detailed but simple — their job is to convey the idea, not look like a finished product. For PoC and MVP purposes, that's enough.

The one screen showing the product from the user's side — because the goal wasn't to design a consumer app, it was to prove the model works. Onboarding, widget setup, "active" / "wallpaper not set" states, a wallet with balance and payout history, kept separate from free, non-monetized wallpapers.

‍

Most of the mockup work went to the advertiser side — without a manageable tool for them, the whole marketplace turns into a black box nobody will trust with their money. A dashboard with spend, impressions, clicks, CTR, and a list of active campaigns.

‍

Creating a campaign is a step-by-step builder. Step one — ad content, with separate uploads for the basic and premium widget and a live preview on Android and iPhone side by side.

Step two — selecting the lock-screen wallpaper, previewed in the actual context of a lock screen.

Targeting and budget. An AI suggestion flags an audience that's too narrow and offers to widen the range. Budget is calculated line by line, with the total visible right at the planning stage.

Payment and moderation status on one screen. This is also where the revision cycle lives: if a moderator rejects content, the advertiser gets a specific list of reasons with a recommendation, not a rejection into thin air.

‍

The moderator dashboard — a queue of submissions with statuses and a detailed view of each campaign, where content and wallpaper are reviewed separately, with previews across OS types and a comment attached to any rejection. This role was built into the model from day one of the workshop, because without it, the entire trust structure between users and advertisers doesn't hold.

Outcome

The client left satisfied — with an actual plan their team took into development. The main contribution wasn't the mockups; it was everything that came before them: turning a technically fragile idea into a model that could be explained, justified on cost and timeline, and built up gradually — from a cheap hypothesis test to a full product.

‍

The market

Saudi Arabia has spent recent years restructuring healthcare from the top down under Vision 2030. The sector transformation program targets digitizing 70% of patient activity by 2030 and expanding telemedicine, with over one and a half billion dollars allocated to healthcare IT infrastructure. The digital health market was valued at roughly 2.4 billion dollars in 2024 and is projected to grow several times over, with telemedicine as its largest segment.

For a private player, that means two things. First, demand is already created by the state — you don't have to explain to a patient what an online consultation is. Second, the competition isn't over the idea. It's over execution.

‍

The business model

KLINIKA earns from four directions: a percentage of every visit, offers, paid promotion for clinics and doctors, and sales of the EMR/CRM system to clinics.

This matters for the decisions below. The app isn't a "service for patients" here — it's the top of the funnel for several revenue streams at once, and nearly every decision in it runs into the same question: how to earn without breaking the reason the patient opened the app in the first place.

The brief

Build out the patient side to cover the full path — from "something hurts" to a paid, completed visit — across every vertical at once: doctors in three appointment formats, laboratory, radiology, nursing services, physical therapy, rehabilitation, offers, and packages.

Each vertical books by its own logic. And the app isn't really competing with the clinic down the street — it's competing with the habit of just calling reception.

The constraints I had to work inside

Regulatory and industry. Healthcare is a regulated field, and some decisions are dictated not by product logic but by rules on how medical data and services can and cannot be handled.

Cultural. For a significant share of the audience, the gender of the medical professional is a deciding factor — and that has to live in the availability logic itself, not in fine print.

Technical. A noticeable share of users are on mid-range devices. An extra section on the home screen isn't "a bit cluttered" — it's a real obstacle to reaching what you came for.

Business. Features need to ship, not be polished. Expensive development kills time-to-market, and I held that constraint alongside the user-facing ones.

‍

‍

Scale

This is only the visible part of the product. The full project map — Login/Reg, Basic flow, Clinic page, Visits with payment states, Offers, Nursing/Lab/Radiology, Profile, Telehealth, Dashboard — runs into the hundreds of screens. Below are specific decisions from six sections of that map.

‍

‍

Basic flow: booking a doctor

Tension. An in-person visit, a home visit, and an online consultation are essentially three different products with different payment and preparation logic. Splitting them into three separate sections would force the patient to decide how they want to be treated before they've even chosen a doctor.

Solution. The visit format is a toggle inside a single booking card, not a separate entry point in the app. Doctor, clinic, date — all chosen in one flow, while "in person or call" gets decided in the moment of booking, not in advance.

What this gives the business. The patient doesn't have to guess the format before seeing the price and schedule of a specific doctor — so they don't drop off at a fork they'd have invented for themselves.

Before payment, there's a short block of questions about the patient's condition (medications, risk factors, chronic conditions) and a free-text description of the problem with a voice message and file attachments. The AI pre-visit quiz is optional — there's a "do it later" button, and booking isn't blocked if the patient doesn't want to go through it right now. That's the difference between a useful option and a barrier to purchase.

Payment is broken down into service cost and VAT, with a choice between "pay at the clinic" and "pay online": part of the audience in this market still doesn't trust prepaying an unfamiliar clinic, and hard-requiring it means losing those people.

‍

‍

Fast online consultation with an AI pre-visit quiz

Tension. Free-text input from a patient is an unreliable source — two phrasings can mean different things, and interpreting them automatically without verification risks routing the person to the wrong doctor.

Solution. The system pulls specific symptoms out of the text and shows them to the patient as a list to confirm, along with a duration clarifier ("just started" / "ongoing for a while"), before moving forward. The patient can add a symptom the AI missed.

What this gives the business. A misread complaint is costly — the wrong doctor gets picked, money is spent on a consultation that misses the mark. The confirmation step is the point where the patient catches an error before it turns into wasted money.

Next come clarifying questions one at a time, each with a "?" icon explaining why it's being asked — some of them, tied to specific indicators, are asked by Dr. Lex, a separately branded assistant inside this step. The choice of doctor's gender comes at the very end, after the full clinical context has been gathered, rather than at the start as a general filter — because up to that point it doesn't yet mean anything for the matching.

At the end, there are three consultation tiers at different price points (GP, Specialist, Consultant), and the AI-recommended tier is already checked — a suggestion, not an auto-selection; the decision stays with the patient. The request isn't confirmed instantly: the screen honestly states that the case is being reviewed, rather than pretending a doctor has already been assigned.

Lab tests and lab packages

Tension. The test catalog is huge and split into categories that mean nothing to a patient without a medical background. On top of that, the complex filter (gender, age, city, keyword) is easy to lose track of when moving between screens.

Solution. Each test has an icon explaining what it shows and why it's needed, right at the moment of selection. The active filter stays visible as a chip on every following screen, instead of requiring the panel to be reopened and the search re-remembered.

What this gives the business. Someone who doesn't understand what they're buying either doesn't buy at all, or calls support afterward with questions. An in-interface explanation removes both scenarios.

When choosing a clinic, the patient sees not an abstract coverage percentage but an exact number and a specific list of missing tests — "3 of 4 available," naming what's not covered. This is a direct extension of the decision from the core flow: the patient sees exactly where the full list is covered and where it isn't, and makes an informed choice instead of guessing.

Offers

Tension. An offer as a single discount on a single service is something every competitor already has. Value needed to be created where separate visits are usually booked individually.

Solution. An offer is assembled as a bundled package — lab tests, an in-person visit, nursing procedures inside one card, each category with its own price and total savings. A countdown timer with a progress bar pushes toward a "now" decision rather than "I'll come back to this."

What this gives the business. A bundled offer sells several visits in a single action — more revenue per user session than three separate bookings. When booking an offer, the patient goes through the same health questionnaire as with a regular appointment: a promotion doesn't fall out of the general context-gathering logic for the doctor just because it's a discount.

Personal area and medical data

Tension. A marketplace gets used occasionally. Between visits there's nothing to open — so the app gets forgotten, and the next time it's needed, the patient chooses again, often based on a competitor's price.

Solution. Medication intake is shown not as a list but as a tracker: what's been taken, what's been missed, what becomes active in 12 days, with adherence indicator dots across the full course and a doctor's note ("take 30 minutes after eating"). The metrics section places numbers next to the normal range — blood pressure and pulse on a chart with a shaded normal-range band, weight with a status ("Underweight") and a goal. Separately, there's an exercise-intensity recommendation for pregnancy tailored to a specific week — the system doesn't just record the state, it gives a contextual prompt based on it.

What this gives the business. A daily reason to open the app with no purchase involved — and data the doctor sees at the next visit, something no competing marketplace can offer without an EMR underneath.

The medical record is filterable by type and year, and lab results carry a color-coded deviation flag at the level of each individual indicator within one test, not one overall verdict for the whole panel. Notifications require an explicit decision wherever money and health matter — confirming a rescheduled visit, accepting or declining a change to a booking — rather than just informing.

Telehealth

Tension. Online appointments break down regularly: connection issues, camera permissions, the doctor not connecting. Every such case is already money spent, and the risk that the person never opens the app again.

Solution. The visits list shows several real states side by side: somewhere device permission needs to be granted in advance, somewhere a countdown to the call is running, somewhere the doctor failed to connect — and in that case the patient sees not "error" but an explanation: "our team has already been notified and is looking into why this happened," plus a payment status and a link to the invoice. During the call, there's a timer for remaining time and a chat next to the video in case the connection is poor.

What this gives the business. A failure explained in plain language with a clear money status doesn't turn into a deleted app. Silence does.

The chat doesn't close along with the call — the doctor can send a document after the conversation, and the exchange continues without video. Feedback is split into two separate ratings — for the doctor and for the clinic — with an option to stay anonymous, and at the end there's a suggestion to book with another specialist for a second opinion if doubts remain after the consultation. A second opinion is another paid visit, not an admission that the first one was bad.

Summary

The product covers the entire patient journey — from an undefined symptom to a paid visit in any of three formats — and stays useful between visits through the medical record, medication tracker, and health metrics.

‍

Patient overview: what affects the decision right now

The chart's first tab isn't a medical history — it's a summary of the patient's state at the moment of the visit.

On the left, the blocks a doctor reads before saying a word: current medications with dosage and days remaining, risk factors, allergies, chronic conditions. Every entry carries a status — active or not — because "had an allergy last year" and "has an allergy now" call for different things.

Risk factors aren't checkboxes from a reference list but plain-language entries with the doctor's note. Private notes hold the same kind of thing for internal use: "occasionally takes antibiotics without a prescription", "doesn't always take prescribed medication". You can't pick that from a dropdown, and it's exactly what changes the approach.

On the right — physical measurements, blood pressure, pregnancy with gestational age and a progress bar to the due date, upcoming appointments.

And the recommended metrics block: the doctor picks what the patient will track themselves through the mobile app, and for how long. Below it, charts of what the patient has already submitted — blood pressure, weight, blood sugar. Assign monitoring, see the results in the same chart.

Doctor's dashboard: the day, not a metrics showcase

A three-day or weekly schedule, filtered by visit type — in-clinic, home visit, telehealth. Statuses by color: confirmed, current, cancelled, follow-up, form not filled.

Below — appointment statistics for the period, personal figures for the month (visits, rating, reviews, days off), and recent patient reviews flagged with which ones the doctor has already answered.

Two decisions worth noting.

Doctors set their own days off — pick a period, give a reason, and the slots close. No request to a manager, no back-and-forth.

Role switching sits at the top. A doctor may work across several clinics and in different roles — a therapist in one, a clinic admin in another. It happens in practice, and switching shouldn't mean logging in again.

‍

The appointment: one flow from complaints to prescription

The core screen of the flow. Everything the doctor does during a visit runs top to bottom without navigation.

It starts with what the patient sent in advance: written complaints, attached files and images, and an audio recording — for those who find it easier to talk than to type. The doctor opens the appointment already knowing what they're dealing with.

Then symptoms and signs, and the diagnosis coded in ICPC-2 — marked "preliminary" if the doctor isn't ready to commit. There can be several diagnoses.

Recommendations through templates. A note is saved under a name and reused; the system warns if a template with that name already exists and offers to replace it.

On the right — prescribing with context checks. The system shows what the patient is already taking and separately flags: the patient is pregnant, keep it in mind. Drug interactions are a real risk, and no doctor can hold a full history in their head.

At the bottom — future visits as a sequence in time: a service or a set of lab tests, and when to carry it out — from the beginning, alongside the previous one, after ten days. Treatment stops being a list of recommendations and becomes a schedule the system surfaces to the patient itself.

And the final toggle — open a chat with the patient for a month. The doctor's call for that specific case: a dose was prescribed, and in a week you need to know whether it's working.

‍

History: a slice matched to the task, not a full dump

A patient's history can accumulate for years. Show all of it and the doctor drowns; show too little and they decide without something important.

So the filters sit in a panel on the right and work together: keyword, period, specialty, visit type, and case area — respiratory, gastrointestinal, cardiovascular, skin, ENT. A gastroenterologist doesn't need ten years of ophthalmology at this appointment.

Records are collapsed to a single line with the diagnosis, date, and visit count. Expand one and you get the full report from that visit: complaints, symptoms, services, prescriptions, medications, attached files.

‍

‍

A completed appointment switches to read mode, but with an editing window: a timer shows how long is left to correct what was entered. After that, the record is locked.

Telemedicine: the same workspace, a different channel

An online appointment isn't a separate product but another tab of the same chart. The doctor sees the history, assigns the diagnosis, and prescribes using the same tools.

What was designed separately is everything that breaks. Camera and microphone checks before the call — not at the moment the patient is already on the line. A waiting timer with a "patient didn't come" button — the doctor records the no-show themselves instead of sitting and waiting indefinitely.

The chat runs alongside the video and stays available before, during, and after the call — a file can go there if the connection is poor and talking isn't working.

‍

Labs, medications, and the log: three tables, three different questions

Laboratory results. Rows group by test name — the same analysis taken at different clinics on different dates collapses into one expandable record with a counter. Inside, each result is color-flagged: normal, minor deviations, major deviations, no data. The doctor sees the deviation before opening the file.

Medications. A prescription history with frequency, dose, duration, start and end dates, and status — active, finished, cancelled. A separate column for who added it: prescriptions from other doctors and entries the patient created themselves sit in one list but stay distinguishable.

Log. Who changed what in the chart, and when. In a medical system this isn't housekeeping: edits to patient data have to be traceable after the fact.

‍

‍

Three devices, two scenarios

On tablet the experience is complete, same as desktop: the doctor runs the appointment as usual, the menu collapses into a burger, blocks restack into a column.

The mobile version was built for one specific scenario — doctors who make home visits. On the road, the essentials need to be at hand: schedule, notifications, messages, profile. Carrying a tablet and a laptop for that makes no sense.

‍

Reception: the clinic's day and getting the patient in

Reception is the point the entire patient flow passes through, so this dashboard is built as a control panel for the current day rather than as analytics.

At the top, the month's figures: appointments, patient satisfaction, a breakdown by status, telehealth calls.

The conflicts block sits right beneath the metrics. These are bookings that collided with a doctor's time off or a schedule change — each needs a decision: cancel, reschedule, contact the patient. Until a conflict is resolved, someone is going to arrive at a closed door.

Below — utilization in two views. By doctor within each specialty, and separately for the lab, imaging, and nursing services including home visits. What's visible isn't "a lot of appointments" but how filled the time the clinic already pays for actually is.

Then the appointment list filtered by service line, attendance confirmations, doctor license expiry with a countdown and a renewal button, reviews, and chats with doctors.

This is also where a patient is registered from scratch. An open slot, a service, a phone number. If the patient isn't in the system, a code is sent to them: they consent to the processing of their personal data on their own side, the administrator enters the code and continues. Details that aren't at hand can be filled in later — the form doesn't block the booking over an empty field.

‍

Laboratory: a different flow for a different job

The lab doesn't work through the appointment screen: its job isn't to reach a diagnosis but to move patients through collection and issue results.

The screen is built around the queue — booked, currently in line, awaiting results. The list is split into clinic visits and home visits, with the address visible right away for the latter. For each patient — the ordered tests and the next-step button: start, waiting, enter results.

During collection, the technician enters a barcode per parameter — that's what ties the tube to a specific person and a specific test.

When issuing results, there's a deviation flag per parameter and a "one file for all results" toggle. The real-world use is forwarding everything to the doctor or patient at once, not assembling six attachments.

Statuses in the list show partial readiness: "2 of 3". Results don't arrive simultaneously, and the patient has to be moved along without waiting for the last one.

‍

Dashboard: a business summary, not a showcase of charts

The first screen is built around what the owner tracks regularly.

Revenue — for the current month with a trend against the previous one, per clinic and across the whole network. Appointments — year-over-year, closed and cancelled, with growth percentages. New and returning patients, top-5 services by revenue, patient gender split, clinic ratings and reviews.

Two blocks stand apart, and I consider them the key ones for this role.

Income channels. How many appointments came through the mobile app versus outside it. The clinic pays the platform a percentage for its marketplace connection, and this is a direct answer to whether that connection pays off — not a guess.

Planned vs. actual utilization in hours. The planned number of hours is calculated from the doctors' schedules automatically — it's the sum of their working time. The actual is compared against it. The owner sees not "many or few appointments", but how filled the time they already pay salaries for actually is. Those are different questions, and the second one matters more.

Here too are tasks with owners and deadlines. A task manager looks out of place in a medical system until you see the scenario: the owner spotted a problem on a walkthrough, assigned someone, set a deadline — and it didn't get lost in conversation.

‍

‍

Clinic management: one card for everything the patient and the regulator see

The clinic profile is both internal data and what goes out to the marketplace: name and description in two languages, logo and cover with safe zones marked for the required size, address, photos, phone numbers.

A separate block is the insurance companies the clinic works with. This isn't cosmetic: it determines which patients the clinic is even shown to in the app, and whether someone shows up with a policy that isn't accepted here.

‍

‍

The densest part here is working hours split by service type. The clinic, the lab, the nursing service, and home visits each have their own schedules by day of week. Plus, separately, non-working days and public holidays for the year ahead.

The reason is that this isn't one facility with one schedule but several parallel streams: the lab can run after the doctors have left, and home visits follow their own windows. Collapsing that into a single calendar breaks booking.

‍

‍

Service management: the network standard and the branch's exceptions

The clinic maintains its service catalog and pricing, including for lab tests. Services can be created as custom ones — for whatever isn't in the shared reference list.

The key mechanic is the balance between a single network standard and the reality of an individual branch. By default, services and packages are synchronized across all clinics in the network: keeping one price list is simpler and more correct. But a branch can create a unique package that doesn't synchronize — if it's the only one that runs a given test, or a manager noticed patients constantly asking to add a couple of items to the standard set.

Without that exception, branches would start keeping part of their pricing outside the system, and marketplace data would drift from reality.

Services are also assigned to specific staff here — which determines what a specialist can even select during an appointment. And in the pricing sections, saving requires confirming responsibility for the changes, with actions written to a log: a service's price and composition affect already-placed orders, and an accidental edit has to be traceable.

‍

‍

Patient list

The clinic's patient base: name, contacts, first and last visit dates, status. In the card — details, insurance with validity check, whether the mobile app is installed, history.

This section is reference-only — the owner needs it not to work with an individual patient, but to see the base as an asset: how many people, how many active, how many returned.

‍

‍

Offer management: a storefront under moderation

Everything the patient sees in the app as promotions is assembled here. An offer is a set of services and lab tests with a two-language description, cover, discount, and a countdown deadline.

There's a targeting layer: the clinic sets a target audience and ties the offer to specific specialists. There's a top position — the offer is raised above the others; the number of such positions is capped by the platform, and the arrangement itself runs through an offline contract.

Offers come with statistics — views, orders, conversion, the most effective categories. This shows the owner what promotion actually sells and what just takes up space.

And since the patient sees a storefront under the platform's brand, offers go through moderation with a moderator's response — a rejection comes with a reason, not silence.

‍

Staff management: onboarding without manual busywork

Doctors, medical staff, and administrative employees are managed in one section with different fields. Statuses reflect the real onboarding path: invitation sent, awaiting verification, license uploaded, deactivated.

Assignment to clinics happens in bulk. In a network of a dozen branches, doctors work in several, and assigning them one by one when a new clinic joins turns into a day of manual work. Services a doctor is allowed to provide are assigned here too.

Separately — doctor license expiry with a countdown. An expired license means a doctor who can't be put on the schedule, and complaints from the regulator. It has to surface a month ahead, not on the day patients are already booked with them.

‍

‍

Roles: a builder instead of fixed positions

This is probably the most important decision in the entire owner flow.

Permissions are structured not as a list of positions but as an assembled matrix. For each section of the system, an access level is set: CREATE, EDIT, READ, or NONE. A group is assembled from these accesses, and users are assigned to the group.

Why not fixed roles. Clinics are organized differently: in one, reception runs the schedule; in another, the manager does; in a third, the owner themselves. A rigid list of roles would have to be rewritten for every clinic and every expansion of the system. A flexible matrix survives both without a rebuild.

Hence a consequence that would otherwise look odd: the same action is performed by people with different job titles across different clinics. It's not about the title, but about the access granted.

A group is tied to a country and a list of cities — a Riyadh content manager doesn't touch Jeddah — and can span several clinics at once.

‍

Feedback: a public reply and an internal debrief

Reviews are visible in the app and influence the choice of doctor — that is, directly affect revenue. The section holds the rating distribution, separate averages by doctor, service, and clinic, the share of answered reviews, and scoring on two axes: professionalism and communication.

The key decision is two levels of response. A review can be answered publicly, or a comment can be left visible to staff only. A debrief with a doctor ("be more polite next time") and a reply to the patient are different conversations; in a single field they eventually get mixed up, and an internal complaint ends up going public.

‍

‍

Invoices

Issuing invoices with VAT and discounts per local requirements — numbers, dates, payment methods, clinic and patient details, a breakdown by service. The section covers the clinic's financial reporting without requiring a separate accounting system.

In summary

The owner flow covers managing a clinic as a business: money and utilization, the composition and pricing of services, promotions, staff with licenses and permissions, feedback, and invoices. At varying depth, but from one place and under one logic — the management question first, the data beneath it.

‍

From a company description to a development proposition

The landing page is built around the idea that Starlife Group is not simply selling square metres. It presents an integrated model of urban development: from land strategy and construction to capital and long-term district value.

This allowed the site to begin with a clear business message instead of a generic corporate introduction.

‍

‍

‍

Making the scale understandable

Numbers and project facts are used as a compact proof layer: development pipeline, residential units, international capital reach and team experience. Rather than placing them in a conventional statistics block, the information is paired with architectural forms to keep the page visual and memorable.

‍

‍

‍

Giving the flagship project enough space

The 21 Hollywood project receives its own editorial section with a large visual, key specifications, awards and a concise project snapshot. This makes it easier for visitors to understand both the scale of the development and the level of ambition behind it.

‍

‍

‍

Full View

‍

‍

‍

‍

Context

Premium car rental usually focuses on one transaction: choose a vehicle, pay for it, pick it up, and return it.

This product follows a different model. The customer rents an SUV together with a professional driver, often for several days, so the service has to support the entire period of interaction rather than only the initial booking.

The driver becomes an important part of the experience. The customer needs to know who they are choosing, what languages they speak, what their background is, and whether they fit the type of journey. After the booking, the app also has to coordinate pickup details, special requests, communication, and additional services.

The result is closer to a managed mobility service than a conventional car-rental flow.

‍

‍

Vehicle Selection

The booking starts with the vehicle. Users can browse premium SUVs, view large vehicle imagery and key specifications, and select the car that fits their trip. The booking interface also makes the rental period explicit, so the user sees the dates and total duration before moving forward.

‍

‍

‍

Driver Selection

The driver is presented as a first-class part of the product rather than an invisible operational detail.

Users can browse different drivers and open a detailed profile with name, age, languages, experience, personal description, and interests. This allows the choice to be based on more than availability. A business traveller may prefer a driver who speaks several languages, while another customer may care more about experience or personal interests.

‍

The Driver Becomes Part of the Product

In most mobility products, the driver is a temporary identity attached to a trip. Here, the driver is part of what the customer is paying for.

That changes the information hierarchy. A name and rating are not enough. The profile needs to communicate personality and suitability: languages, age, experience, background, interests, and a short personal introduction.

The selection process therefore works more like choosing a service professional than assigning an anonymous driver.

‍

‍

Additional Services

The ride can be extended with additional services such as an incognito ride, bodyguard, personal concierge, secretary, translator, or ride sharing.

Services are added directly to the booking and reflected in the final calculation, so the customer can understand exactly what is included before paying.

‍

Checkout and Payment

The checkout combines all booking information in one place: selected driver, vehicle, rental period, location, additional services, discount, VAT, and available bonuses.

The user can apply existing bonuses, see the bonuses earned from the current ride, and choose between saved cards, Apple Pay, Google Pay, or another payment method.

The goal was to keep a complex premium purchase understandable without hiding the details that affect the final price.

‍

‍

What Is Interesting Here from a Design Perspective

The Booking Continues After Payment

The moment of payment is not the end of the flow.

After the reservation is confirmed, the user still needs to specify the exact pickup time, location, and special instructions. In the example flow, the customer can specify a precise airport pickup point and add instructions such as meeting at a particular lounge.

The product therefore treats the booking as a lifecycle:

reservation → pickup details → driver preparation → arrival → ride

This prevents important operational information from being buried inside the initial checkout.

From Driver to Personal Concierge

The most distinctive part of the product is the Personal Concierge.

The customer can assign tasks to the driver across several categories: restaurants, shopping, daily routine, entertainment, and VIP places. Instead of forcing users to formulate every request from scratch, the interface first organizes possible tasks into recognizable groups.

For example, a user can request a table with a city view, arrange shopping, organize a dinner, book a spa appointment, or ask the driver to deliver documents to another address.

The interaction becomes a task-management layer built on top of the ride itself.

‍

Structured Tasks Instead of an Open-Ended Request

The concierge experience does not stop at a text field.

A task can contain a specific request, date and time, requirements, and additional notes. Once assigned, it becomes an active task that can be reviewed and discussed with the driver.

This creates a clear transition from an abstract request to an actionable job:

request → requirements → driver → confirmation → completion

The customer always knows what was requested and what the driver is expected to do.

‍

‍

Other

Communication Is Built into the Service

Once a ride or concierge task is active, communication becomes part of the product rather than an external channel.

The customer can see that the driver has received the instructions, monitor their arrival, contact them directly, and communicate about individual tasks.

For pickup, the interface exposes the driver's status and estimated arrival time, while actions such as “Pick me up” and calling the driver remain immediately available.

One Booking, Many Price Components

Premium services often become difficult to understand when multiple extras are added.

The checkout separates the rental price, additional services, VAT, discount, and bonus usage before showing the final total. Each service remains identifiable rather than being collapsed into a single unexplained amount.

This is especially important when services such as a bodyguard, translator, secretary, and concierge can all be combined in one reservation.

After the Ride Starts

The experience continues after the customer has booked everything.

The interface communicates that the driver has received the instructions, shows the current status, and provides an approximate arrival time. At the pickup stage, the customer gets direct actions instead of having to navigate back through the booking.

The same logic is used for concierge tasks: pending work, confirmed tasks, requirements, and communication remain visible as the service progresses.

A Premium Experience Without Hiding the Mechanics

The visual language is deliberately minimal and image-led, but the underlying interaction is highly structured.

The product has to manage luxury positioning without sacrificing operational clarity: which car, which driver, which dates, which services, where to meet, what was requested, how much it costs, and what happens next.

The design keeps those details available without making the experience feel like an administrative dashboard.

Development Handoff

[IMAGE: component / state documentation]

The product contains several interconnected flows, so consistency between booking, ride management, driver profiles, payments, and concierge tasks was essential.

The interface was built around reusable patterns for cards, service selections, task states, navigation, payment methods, and ride-status components. Different states were treated as part of the product rather than as exceptions to the main flow.

The result is a mobile experience where the same visual language follows the customer from the first SUV selection all the way through an active ride and the completion of personal tasks.

‍

Context: color is one of the biggest barriers to buying paint online

In a typical paint and coatings store, a customer sees color as a small square in a catalogue. But a shade looks different across a large surface, in different lighting, and within a specific interior.

For an e-commerce business, this creates a conversion problem at the point of choice. A customer may:

• postpone the purchase because they are unsure about the color;
• buy multiple samples without knowing which shade will work;
• go offline to see physical color samples;
• struggle to understand which paint base and tinting system are required for a selected shade.

The goal was not simply to display a palette. The module needed to give customers enough confidence to place an order and directly connect color selection with paint and tinting-service purchase.

‍

‍

Real catalogues instead of an abstract palette

The module is built around imported paint and tinting catalogues from popular manufacturers. Users choose a specific catalogue shade—not a generic blue or green.

The complexity of compatibility remains inside the product. The system accounts for cross-references and links each shade to the appropriate paint base, so customers do not need to understand tinting technology to place a correct order.

This turns the module from an inspirational color picker into a commercial tool that can lead to a real purchase.

‍

‍

Interior visualisation helps customers make a decision

Rather than attempting to simulate an unlimited number of user interiors, I designed a set of pre-rendered scenes. Each room type includes dedicated interiors and 10–12 renders with different lighting conditions and viewpoints.

Customers can apply colors to the walls and see how they work alongside furniture, doors, flooring, and décor. A day/night switch is also included, as the same shade can look noticeably different depending on the light.

Importantly, the module does not promise perfect digital color accuracy. It is a tool for narrowing down and comparing options, so the interface includes a disclaimer explaining the difference between an on-screen preview and the actual painted result.

‍

Comparing several shades instead of trying to remember them

Paint selection rarely happens with one click. People usually keep several close options in mind and try to remember how one blue differs from another.

The module allows users to collect several shades and compare them directly within an interior. Comparing four or five colors was the most practical use case, but the product did not impose a hard limit.

Selected colors remain visible in a bottom panel, allowing users to return to them, remove options, add new ones, and retain context while exploring a large palette.

‍

‍

‍

‍

Samples reduce risk, while paint purchase completes the journey

Once a user has narrowed down their choice, the module offers a meaningful next step: order small sample pots or add paint with a tinting service directly to the cart.

This supports different levels of confidence:

• customers who want to check a shade physically can order samples;
• customers who have decided can choose the required paint volume immediately;
• the store gets a connected journey from color selection to purchase, rather than a standalone visual service without a commercial outcome.

The tinting service is added to the order together with the paint, making the selected color part of a correct product configuration rather than a note the customer needs to explain manually to a seller.

‍

‍

‍

‍

Saved sets turn a one-off purchase into a repeat order

Color selection often does not end with one order. Paint can run out, a renovation can continue in stages, or a chosen shade may need to be repeated months later.

Users can therefore sign in and save selected or previously purchased colors to their account. This supports several repeat-use scenarios:

• quickly reorder the same shade when more paint is needed;
• return to a saved set during the next stage of renovation;
• share a selection with another person by link.

The last scenario is particularly valuable for shared decision-making. For example, one person can select colors visually, while another opens the same collection through a link—without exchanging color codes or trying to explain “which beige” they mean.

‍

‍

‍

An embedded module designed to grow e-commerce sales

RoboTint is designed not as a standalone paint store but as a module that can be embedded into a paint and coatings e-commerce experience.

For customers, it is a familiar in-store journey: choose a color, check it in an interior, select a product, and place an order. For the retailer, it is a way to reduce uncertainty before purchase, offer samples as an intermediate step, and increase the likelihood of selling the required volume of paint together with the tinting service.

My responsibility covered the UX, interface design, and prototyping of the entire module—from catalogue selection and visual comparison to purchasing, saving, and repeat-order scenarios.

‍

‍

‍

‍

‍

‍

The problem: data existed, but the management view did not

For a field team, it is not enough to know who started a route or how many locations they visited. Managers need to quickly identify missed visits, routes falling behind plan, in-store execution issues, and situations that require action.

The audit highlighted the need to rebuild the information hierarchy: separate high-level oversight from detailed data, make statuses easier to scan, and reduce the effort required to move between a route, an employee, and a retail location.

‍

‍

A dashboard for operational control, not a collection of widgets

The concept dashboard brings together the map, visit list, employee statuses, route progress, and messages from the field. A manager can start with the overall picture of the day and quickly move to a specific issue or retail location.

I used different ways of representing the same information—map, table, and cards—because each supports a different task. Maps make geography easier to understand, tables support progress comparison, and cards provide faster context for an individual visit.

‍

‍

‍

Filters and presets designed for real operational work

In products like this, users rarely need to review the entire dataset at once. More often, they need a specific slice: a particular company, city, team, date range, visit type, or completion status.

Filtering was therefore designed as part of the main workflow, not as a secondary setting. Saved presets make recurring views reusable without rebuilding conditions every time—for example, when monitoring a specific client or region.

‍

‍

‍

‍

The retail-location page: from checking data to taking action

At the store level, I consolidated data on visits, attendance, check-ins, product availability, planograms, RTV, and individual sections. Instead of moving through disconnected areas, managers get one coherent view of a location and can understand what requires attention.

This shifts the experience from reviewing reports to working with exceptions: not simply seeing a completion percentage, but understanding why it changed and what needs to happen next.

‍

‍

‍

Outcome

I prepared a design concept and presentation for IPC that connected the audit findings to specific interface decisions. It provided a direction for evolving the product: from a system that records field activity into a tool that helps teams actively manage it.

‍

The challenge: make a complex admissions journey manageable

International admissions are not a single application. One student may have several programmes and institutions, supporting documents, offer conditions, changed dates, payments, and multiple people involved on the agency side. When all of this lives as separate fields and screens, a CRM may store data but does not actively support the work.

The goal was to present more than a database record. Staff needed to see the current picture at a glance: what is happening now, who is responsible, which programmes are in progress, and what requires the next action.

‍

‍

From a student list to the team’s working queue

The My Students area was designed as an operational queue rather than a passive directory. Search works not only by name, but also by contact details, passport number, and date of birth; filters and sorting help staff quickly find the right cases. Urgent tasks and reminders stay visible.

This reduces the time spent locating a case and makes distributed team work more transparent: each team member can immediately see which students need attention first.

‍

‍

The student profile as a single workspace

Within the profile, I brought together the essential context: student information, the responsible manager, current status, programmes, documents, invoices, and activity timeline.

The programme structure was particularly important. Each programme shows the institution, campus, admission stage, cost, start date, and changes to its conditions. Staff do not need to reconstruct the application history from messages or search for the reason a status changed.

‍

‍

‍

History and documents as part of the workflow, not an archive

For applications involving multiple people, it is essential to understand what has already happened. The concept therefore includes an activity log for programme creation and changes, status updates, document uploads, and other actions. Documents are organised into categories to make them easier to review and hand over to the next person in the process.

This turns the CRM from a place that merely stores information into the team’s shared operational memory.

‍

‍

Outcome

I created a clear design direction for IGEC’s internal team: an interface where a student’s complex admissions journey reads as a coherent process rather than a collection of disconnected CRM fields. The concept can serve as a foundation for developing the rest of the system.

‍

‍

♡

‍

Context: professional communication in healthcare is usually fragmented

Healthcare professionals receive pharmaceutical materials through one channel, participate in learning through another, and look for events and vacancies elsewhere. Medical representatives build relationships with HCPs through in-person meetings, calls, chats, and separate corporate tools.

MedReach already addressed the functional side of this problem by bringing communication, learning, content, and professional opportunities together. The next challenge was to make the ecosystem feel alive - not just a place users visit to complete one task, but a professional space they want to return to.

‍

‍

‍

Social layer: give the community a shared professional context

The social experience is built around a feed containing materials from pharmaceutical companies and the medical community. In one stream, users can follow industry updates, educational content, cases, events, and posts from colleagues.

The goal was not to copy a mainstream social network. Here, content exists not for reach or entertainment, but for professional value: new knowledge, communication, career development, and interaction with the industry.

Each participant - a doctor, representative, or company - has a different role in the system, but shared mechanics for viewing, reacting, discussing, and following create one common language of interaction.

‍

‍

Gamification: make professional progress visible

In an ecosystem with a large number of materials, courses, and professional activities, it is easy to lose the sense of progress. Gamification was therefore needed not as a decorative layer of medals, but as a way to make user contribution visible.

Points, levels, badges, and achievements help capture participation in the life of the platform. Users see not only individual actions, but also their accumulated journey: how actively they explore content, participate in the community, and develop their professional presence.

This approach is particularly important in a professional product: rewards should not diminish medical expertise. They should support regular, meaningful activity rather than turn the application into a game for its own sake.

‍

‍

Profile as the centre of professional identity

The profile brings together what users do across different parts of MedReach: professional information, community activity, achievements, and connections.

For a doctor, it is a way to establish a presence in the professional community. For a medical representative, it makes their activity and interaction results visible. For companies, it enables interaction with a verified community of specialists rather than an anonymous audience.

The profile connects content, learning, and interaction: a published post, completed course, or earned reward no longer remains an isolated action.

‍

‍

Social mechanics support the whole product, not a separate feature

The feed and gamification do not exist separately from the rest of the platform. They help users discover learning materials, return to courses, notice events, maintain professional connections, and stay informed about the industry.

For pharmaceutical companies, this creates a more active and sustainable communication channel with HCPs than a one-time mailing or single meeting. For specialists, it provides one environment where useful content, professional communication, and development do not require switching between multiple services.

‍

What makes the solution different

MedReach does not use social mechanics as a superficial way to increase engagement. The social and gamification layer connects the platform’s existing functions into one professional experience.

Users receive more than a feed and a collection of rewards. They get a visible path within the community: learning, participating in a professional environment, building reputation, and returning to the product with clear personal value.

‍

Context: a professional brokerage interface does not work for a mass audience

A brokerage account already existed, but it was designed for people who understood how exchange trading works. For an everyday bank customer, this created a high barrier to entry: before making a first investment, they needed to understand market terminology, account types, orders, available balance, and a large number of financial indicators.

The new section needed to become an accessible entry point to investment products for the bank’s existing audience—people without prior investment experience. The goal was not to hide financial complexity, but to reveal it at the moment when it was genuinely relevant to the user.

‍

The portfolio as the first point of orientation

The main page is built around answers to the user’s most basic questions:

• What are my investments worth now?
• How much have I invested?
• What is my overall result and performance over time?
• Which accounts hold my cash and assets?
• Which securities do I already own?

Instead of separating every account into its own isolated view, users receive a unified overview of their brokerage account and Individual Investment Account (IIA). Key metrics appear in the top section, while the asset list remains available below, with the number of securities, current value, and performance.

This sequence helps users understand their overall financial situation before going deeper into individual instruments and trades.

‍

‍

‍

The catalogue and investment ideas help users move from browsing to action

For a user without investment experience, investing does not start with a ticker symbol. It starts with a question: “What is available, and how do I choose?”

The product therefore includes two related scenarios:

• a catalogue of financial instruments, with filters by markets and product types;
• investment ideas that provide a more approachable entry point through a company, industry, potential horizon, and expected outcome.

Investment ideas do not replace the user’s own decision. Their role is to reduce cognitive barriers and help people begin exploring instead of leaving them alone with a long list of unfamiliar securities.

‍

‍

‍

The trade order makes the consequences of a decision visible in advance

The highest-risk part of the experience is the moment of buying or selling. It is not enough to show input fields and a confirmation button: users need to understand what kind of order they are creating, how much it will cost, and whether their balance is sufficient.

The transaction flow includes:

• a choice between market and limit orders;
• an explanation of how a limit order works;
• controls for lot quantity and price;
• commission and total calculation;
• available-funds information;
• a clear state when there is not enough money for the transaction;
• account selection for the trade.

Users see the financial consequences of their actions before confirmation, rather than discovering constraints after attempting to submit an order.

‍

‍

‍

‍

Funding and withdrawals are part of the investment experience, not an external process

Investing does not end with buying an instrument. Users move money between the bank and their brokerage account, so funding and withdrawal need to be a natural part of the account experience.

The product includes flows for adding funds, withdrawing money, and saving bank details. Users can see where funds will be transferred, add a new withdrawal account, and use saved details in the future.

This reduces manual errors and makes repeat financial operations faster.

‍

‍

‍

Designing within a large financial specification

The project was built from a substantial requirements specification covering the system and many mandatory scenarios. My responsibility was to design the complete UX and interface of the investment section: from the first portfolio overview to trading operations, money management, and account closure.

The central principle was to make an investment service accessible to an everyday bank customer without turning financial logic into a set of simplified and opaque actions.

‍

‍

‍

Mobile property search should not feel like a shrunken desktop catalogue

Most real estate websites follow the same pattern: filters, grids of static cards, long detail pages, and a separate path to contact an agent. On a phone, this creates too much switching and too little sense of the actual property.

The goal was not a cosmetic redesign of a typical real estate website, but a more natural way to explore property on a mobile device.

See the space first, then explore the details

The primary mode is a vertical property feed, using a familiar social-media interaction pattern. Users scroll through short videos while essential information - the property name and price - remains visible on top of the content.

Video is not intended to replace all property information. It is the fastest way to create a first impression, showing scale, interiors, views, surroundings, and atmosphere before the user opens the full property details.

‍

‍

Expand the details without breaking the browsing flow

Once a property catches the user’s attention, its details expand in a bottom sheet instead of opening a separate, heavy page. The same context includes area, number of bedrooms and bathrooms, a description, interior gallery, building and neighbourhood imagery, floor plans, property features, and location on a map.

This allows users to move from an emotional first impression to a rational review of details without losing the property or returning to the catalogue.

‍

‍

‍

‍

Change the way people search, not the product they are using

Different moments in the search process require different tools. The feed is designed for fast discovery. List mode supports reviewing properties as comparable cards. Map mode becomes essential when the decision is driven by neighbourhood, proximity to work, infrastructure, or a specific area of the city.

These modes are connected through one navigation system and one inventory of properties. Users change their view, not the product.

‍

‍

‍

Turn property interest into a conversation

Once users have watched a property and reviewed its details, they should not need to search for the agency contact details or move to a separate form. The property view provides direct access to a conversation with the assigned agent.

This makes the contact point timely and contextual: users can clarify details, request another video, discuss VIP services, or arrange a viewing without having to explain which property they mean.

‍

What makes the solution different

The concept moves real estate discovery beyond the era of listing catalogues and towards a mobile-native pattern of consuming visual content. Instead of asking users to begin with filters and text-heavy cards, the product lets them see a space first, explore the relevant details quickly, and start a conversation immediately.

‍

Context: young people can struggle to feel connected to their city and community

Even in a familiar city, people often do not know which places are nearby, what they can do in their free time, or how to meet new people beyond their usual circle.

For YMCA, this was an opportunity to create a digital entry point into local life: helping young people find activities, learn more about their neighbourhood, and become involved in interest-based communities.

A key part of the idea was connecting digital and offline experience. The app was not intended to keep people on a screen—its purpose was to help them choose an activity and go out into the real city.

‍

‍

A route is more than a list of places on a map

The core experience is built around themed local routes led by volunteers. They can combine landmarks, cultural places, natural locations, or points connected by a specific topic and participants’ interests.

Within the interface, each route is presented as an understandable activity. Users can see its theme, format, level of difficulty or expected involvement, and decide whether it is the right way for them to spend their time.

This approach makes local exploration more accessible for people who are not used to planning outings on their own or do not know where to start.

‍

‍

Interests help users move from finding places to finding their people

One walk does not always create a lasting connection to a community. The product therefore includes interest-based groups where users can find like-minded people and discover activities connected to the topics that matter to them.

This changes the product logic: Exploring Path does not end when a route is completed. A participant can join a group, follow upcoming events, and return to the platform as a source of local social life.

Activists get a way to gather an audience around an initiative

The platform also supports people who are already active in city life: volunteers, local activists, and event organisers.

They can propose activities for specific groups and interests, while participants can discover them in one place alongside routes and other events. This reduces the gap between an initiative that exists in the local community and people who could join it but simply do not know it exists.

A unified experience for moving from online to offline

The main UX principle was not to turn the app into a social network designed purely for feed consumption and screen time. Each key section should help users take their next offline step:

• choose a route;
• join a group;
• find an event;
• discover a local initiative;
• take part in an activity.

This brings several fragmented ways of discovering a city and community into one clear user journey.

‍

My role

This was a real client project for YMCA. I was responsible for the mobile app design: the visual language, interfaces for key user scenarios, and prototyping.

The design challenge was to make the product’s social idea accessible and appealing to a young audience: avoiding information overload while giving people enough context to choose an activity, feel interested, and move toward real-world participation.

‍

‍

A complex case cannot be solved with one local appointment

A patient may need care that is unavailable in their city: a rare specialist, complex diagnostics, surgery or treatment at a specialised clinic. In these situations, finding care becomes a major project where medical and logistical decisions are closely connected.

‍

‍

A personalised package instead of planning a medical trip alone

Users can explore relevant treatment options, clinics or specialists, while the service builds one coordinated offer. The package may include consultations, procedures, diagnostics, flights, accommodation and other supporting services.

This reduces cognitive load at a time when patients already need to make difficult medical decisions.

‍

‍

‍

Compare medical options before committing

Doctor, clinic and service profiles give patients enough context to understand the differences between options: specialty, experience, what is included, price and conditions.

The interface is designed to make a complex offer transparent rather than hiding important details behind one package price.

‍

‍

‍

Complete the journey as one decision

After choosing an option, users do not have to switch between multiple services. They can arrange their treatment journey in the app and use one space to manage documents, statuses and trip-related details.

‍

‍

‍