Un schimb de ture pe care îl urmăresc ambele părți.

Provocarea

Am lucrat ca barista, iar cafeneaua în care eram angajată își făcea programul cum și-l fac multe locuri mici: într-un tabel, trimis echipei ca o captură de ecran. Turele dintr-o cafenea se schimbă tot timpul, pentru că cineva e bolnav, cineva are examen sau o livrare se mută dimineața, așa că un simplu schimb de ture devenea un șir de mesaje, un manager care verifica de mână orele de odihnă și o captură nouă, ușor de ratat. De acolo a pornit Tura.

Am vrut să proiectez tot circuitul, nu doar un ecran din el: persoana care nu poate veni la o tură, colegul care o preia și managerul care o aprobă fără să încalce regulile despre odihnă sau orele din contract. Un astfel de instrument funcționează doar dacă ambele părți au încredere în ce văd, așa că partea care m-a interesat cel mai mult a fost momentul în care cele două se întâlnesc.

Rolul meu

Tura e proiectul meu, așa că am făcut totul: identitatea vizuală și cele două ecrane principale în Figma (Turele mele din aplicația angajaților și planificatorul de ture al managerului), restul ecranelor direct în cod pornind de la aceleași elemente, și prototipul în React și TypeScript. Ce poți încerca aici este doar prototipul: nu are încă backend, așa că totul rulează în browser, pe o cafenea inventată, Café Molotov din Cluj-Napoca, cu șase oameni și două săptămâni de ture. Aplicația reală, cu backend, e în lucru.

Decizii cheie

• Regulile sunt verificate înainte ca managerul să decidă, nu după. Fiecare cerere ajunge în inbox cu verificarea deja făcută: unsprezece ore de odihnă păstrate, nimeni programat de două ori, orele din contract respectate și efectul asupra costului cu personalul. Decizia rămâne a Biancăi, dar nu mai trebuie să facă ea calculele.
• Un conflict vine cu o soluție. Planificatorul marchează cu roșu un conflict legat de odihnă, iar fereastra care se deschide propune o rezolvare concretă, nu doar un avertisment. Prima mea idee a fost să schimb tura cu alt coleg, dar și așa îi rămâneau doar nouă ore de odihnă, de aceea soluția îl mută pe tura liberă de seară, care îi păstrează numărul de ore și îi lasă șaptesprezece ore libere.
• Căutarea unui înlocuitor începe cu cine poate chiar să vină. Când Ana nu poate ajunge la o tură, aplicația sugerează colegi care sunt liberi în ziua aceea, au același rol și nu își depășesc orele din contract, și explică de ce l-a ales pe fiecare. Dacă nu se potrivește nimeni, Ana poate oferi tura întregii echipe.
• Animație doar acolo unde explică ceva. Cea mai mare parte a interfeței e calmă. Singurul loc unde animația are voie să iasă în evidență e Auto-fill, unde programul săptămânii următoare se completează zi cu zi, pentru că acela e momentul în care aplicația îi scutește managerului o seară de muncă. Orice acțiune pornită de la tastatură se întâmplă instant.

Încearcă: o tură, ambele părți

Rezultat

Aplicația reală nu e lansată încă, așa că nu am utilizatori sau cifre de raportat. Ce arată prototipul este schimbul complet, din ambele părți: Ana își cedează tura de joi, Mihai acceptă, Bianca aprobă cu regulile deja verificate, tura se mută în planificare și telefonul Anei confirmă.

Pentru că l-am construit în cod și nu ca ecrane Figma legate între ele, fiecare cifră de pe ecran e calculată din aceleași date, așa că costul cu personalul, orele și conflictele se potrivesc mereu între ele, lucru pe care un prototip static nu îl poate promite. M-a obligat și să proiectez stările pe care un flux în Figma le sare de obicei, cum ar fi o cerere care sosește în timp ce managerul e pe alt ecran.

Ce aș face mai departe

Următorul pas e aplicația reală, care e în lucru. În paralel, ce lipsește evident sunt testele cu oameni reali: aș da aplicația angajaților câtorva echipe din cafenele și restaurante, ca să văd dacă sugestiile de înlocuire se potrivesc cu felul în care chiar aleg pe cine să roage, pentru că într-o echipă mică asta ține adesea de cine cui îi datorează o favoare, lucru pe care nicio regulă nu îl poate prinde.

Pe partea managerului, Auto-fill construiește săptămâna doar din disponibilitate și orele din contract; ar trebui să învețe și din modificările pe care managerul le face de mână după aceea. Aș adăuga și pontajele, pe care le-am lăsat intenționat în afara prototipului, ca nimic de pe ecran să nu fie un buton care nu funcționează.