© 2017 UXStratégia. Majd lesz rendes is :)

  • Facebook - Grey Circle
  • LinkedIn - Grey Circle
  • Google+ - Grey Circle

PROBLÉMA

Tervezzünk egy olyan web-alapú orvosi ügyviteli rendszert, amely megfelel az összes szabályozásnak és az orvosok jelentős része hajlandó lenne feladni a mostani szoftverét ezért cserébe. 

KONTEXTUS

Ahhoz, hogy egy orvosi szoftver legálisan működjön, meg kell felelnie az OEP, a NAV, a KSH, az ÁNTSZ, az OÉGYI és a többi rövidítésszervezet összes törvényi rendelkezésének. A szoftverek hibái súlyos pénzbüntetéssel járnak.

Egy orvosi rendelőben nincs olyan, hogy ez a funkcionalitás jelenleg nincs kész: több mint 40 modulnak kell az első perctől naprakészen működnie, hisz bármikor beeshet bárki egy ritka betegséggel, heti szinten alakul ki vészhelyzet és az időnyomás hatalmas.

1/3
1. KUTATÁS

Több tucat orvost látogattunk meg rendelés után, érdeklődve hogy zajlott a nap, mik voltak a főbb esetek.

Letöltöttünk minden elérhető kézikönyvet és próbaváltozatot a hasonló szoftverekről, átolvastunk minden jogszabályt, jelentési "rekordképet" (API-t) és összegyűjtöttük az összes űrlapot.

Ezekből kiderült, milyen modulokat kell építenünk. Minden modulnál megkérdeztük az orvosokat az elmélet és a gyakorlat közti különbségekről, ha valami nem volt egyértelmű, rákérdeztünk, miért van, mire való, és példákat kértünk konkrét esetekről. 

2. TERVEZÉS

A kutatások alapján modulról modulra haladva 2 hetes szakaszokban elkészítettük az összes kulcsképernyőt.

Az, hogy milyen feladatok vannak az orvosok történeteiből raktuk össze. Az információs felépítés alapja a jogszabályok voltak.

Elemeztük a konkurenciát hogy megtudjuk, mit szeretnek az egyes termékekben az orvosok, de ugyanakkor modern, felhasználóbarát felületet szerettünk volna: végül életünk eddigi legkomplexebb UI rendszerét alkottuk meg, amely rengeteg információt ad kattintásra.

Ha elkészült egy modul interaktív prototípusa amely képes volt pár feladat ellátására, megkértünk egy orvost, használja, mintha igazi terméket tartana a kezében.

Bármi, ami nem sikerült elsőre az először felkért orvosnak kijavításra került, mielőtt odaadtuk volna egy következőnek, remélve, neki már könnyebb lesz kezelni a rendszert.

Minden modul legalább 3 orvos látott így egymás után, folyamatosan javítva, mielőtt véglegesítettük volna, mit is kell lefejleszteni. 

3. TESZTELÉS

4. SPECIFIKÁLÁS

Miután a modulok átmentek a teszteken, specifikációt írtunk amikből a fejlesztők dolgozhatnak.

A user story-kat az orvosok tényleges gyakorlatára építettük. Forgatókönyveket írtunk, így minden történet lépésről-lépésre lejátszható, így elképzelhető és tesztelhető lett.

Meghatároztunk minden adatmezőt: nevüket, típusokat, miért szmítanak, mi az alapértékük és értékkészletük, és kellenek-e valamilyen törvény, rendelkezés, vagy API betartásához.

A felületet komponensekre bontottuk, egyesével definiálva viselkedésüket és tartalmukat, részletezve a szélsőeseteket.

FOLYAMAT

Healcloud háziorvosi ügyviteli rendszer

ELSŐRE HASZNÁLHATÓ ORVOSI SZOFTVER

Az egyik nap egy új munkatárs kezdett a cégnél: megkértük, írjon fel magának egy doboz algopirint a szoftver segítségével. Ez másfél perc alatt mindenféle segítség nélkül sikerült.

EREDMÉNY

Az egyik nap egy új munkatárs kezdett a cégnél: megkértük, írjon fel magának egy doboz algopirint a szoftver segítségével. Ez másfél perc alatt mindenféle segítség nélkül sikerült.

A fejlesztők a projekt fél éves fejlesztése alatt kevesebb, mint 10 kérdést tettek fel nekünk, ami a dokumentumokból nem volt kiolvasható.

 Egy olyan rendszert sikerült tervezni, amely 21. századi konkurenciája a piacvezető megoldásoknak.