Koristne informacije ...

Kako pripraviti funkcionalnosti spletne aplikacije

Spletna aplikacija redko propade zato, ker bi bila tehnologija napačna. Pogosteje se zaplete že prej: podjetje naroči seznam želja namesto jasnega odgovora, kaj mora uporabnik na aplikaciji dejansko opraviti. Zato vprašanje, kako pripraviti funkcionalnosti spletne aplikacije, ni administrativna podrobnost pred razvojem. Je trenutek, ko poslovno idejo pretvorite v rešitev, ki jo je mogoče načrtovati, razviti, testirati in kasneje nadgrajevati.

Dobra priprava ne pomeni dokumenta s stotimi stranmi. Pomeni, da razvojna ekipa in naročnik enako razumeta cilj, uporabnike, ključne procese in meje prve različice. Tako se izognete dragim popravkom v fazi, ko je aplikacija že zgrajena, pa ugotovite, da manjka korak pri oddaji naročila, potrjevanju dokumentov ali prenosu podatkov v računovodstvo.

Začnite s poslovnim problemom, ne z zasloni

Stavek »potrebujemo portal za stranke« še ni specifikacija. Je izhodišče za prava vprašanja: Kaj stranka danes ureja po e-pošti, telefonu ali v preglednicah? Kje zaposleni izgubljajo čas? Kateri podatek se prepisuje večkrat? Kaj mora biti po uvedbi aplikacije hitreje, bolj pregledno ali manj odvisno od ročnega dela?

Če na primer servisno podjetje potrebuje aplikacijo za prijavo intervencij, bistvo ni v obrazcu za oddajo zahtevka. Bistvo je v celotnem toku: stranka prijavi težavo, sistem določi odgovorno osebo, tehnik prejme obvestilo, doda zapis opravljenega dela, stranka pa vidi status in zgodovino posegov. Ko je tok jasen, je lažje določiti funkcionalnosti. Brez tega se pogosto razvije lep vmesnik, ki ne reši operativnega problema.

Za vsako pomembno funkcionalnost določite tudi merilo uspeha. To ni nujno zapletena analitika. Lahko pomeni manj klicev v podporo, krajši čas obdelave naročila, manj napak pri prenosu podatkov ali več oddanih povpraševanj. Merilo pomaga pri odločitvah, ko se pojavijo dodatne ideje in je treba presoditi, ali res sodijo v prvo fazo.

Kdo uporablja aplikacijo in kaj sme narediti

Aplikacija ni en uporabnik. V praksi imajo različne vloge različne potrebe, dostop in odgovornosti. Kupec želi hitro pregledati naročilo. Sodelavec v prodaji potrebuje vpogled v komunikacijo in status. Administrator upravlja uporabnike, vsebine in nastavitve. Zunanji partner morda vidi le del podatkov, ki so zanj relevantni.

Pri pripravi zato ne naštevajte le funkcij, temveč opišite vloge. Za vsako določite, kaj lahko vidi, ustvari, spremeni, potrdi ali izbriše. Posebej pomembno je, kdo lahko dostopa do cen, osebnih podatkov, dokumentov in poročil. Ta odločitev vpliva na uporabniško izkušnjo, varnost in obseg razvoja.

Dober opis je konkreten: »Prijavljena stranka lahko ustvari zahtevek, priloži fotografijo in spremlja status svojih zahtevkov.« Slab opis je: »Uporabniki upravljajo zahtevke.« V prvem primeru je jasno, kaj je treba izdelati. V drugem se ključne odločitve prestavijo v razvoj, kjer so spremembe dražje in počasnejše.

Kako pripraviti funkcionalnosti spletne aplikacije po uporabniških poteh

Najbolj uporaben način priprave je opis uporabniških poti. Ne začnite z menijem in posameznimi gumbi. Začnite s scenarijem, ki ima začetek, odločitve in jasen rezultat.

Pri B2B naročilnem portalu je lahko pot takšna: uporabnik se prijavi, poišče izdelek, preveri pogodbeno ceno, odda naročilo, prejme potrditev, spremlja dobavo in prenese račun. Pri tem hitro odkrijete vprašanja, ki jih seznam funkcij pogosto skrije. Ali se cene prikazujejo vsem enako? Kaj se zgodi, če izdelka ni na zalogi? Ali lahko uporabnik naročilo spremeni? Od kod pride podatek o statusu dobave?

Vsako pot razdelite na manjše korake in pri vsakem opišite pričakovano vedenje sistema. Zapišite tudi izjeme. Prav izjeme so pogosto razlog, da aplikacija v realnem delu ne deluje tako dobro, kot je delovala na predstavitvi. Kaj se zgodi, če uporabnik vnese nepopolne podatke, če plačilo ni uspešno ali če povezani sistem začasno ni dosegljiv?

Vizualni osnutki zaslonov so pri tem zelo koristni, vendar niso cilj sami po sebi. Preprost prikaz hitro pokaže, ali je pot smiselna, koliko podatkov uporabnik potrebuje in ali bo administracija pregledna. Dober dizajn ni okras po zaključku razvoja. Je način, da uporabnik hitreje in z manj napakami opravi nalogo.

Razlikujte med nujnim in zaželenim

Prva različica aplikacije mora rešiti glavni problem dovolj dobro, da jo ljudje začnejo uporabljati. Ne rabi pa v prvem dnevu pokriti vsakega posebnega primera, ki se je zgodil enkrat pred tremi leti. Preširok prvi obseg podraži projekt, podaljša čas do objave in poveča število nepreverjenih predpostavk.

Funkcionalnosti razdelite na tri ravni: nujne za zagon, pomembne za naslednjo fazo in ideje za kasnejši razvoj. V nujno skupino sodijo elementi, brez katerih ključna uporabniška pot ne more delovati. Če gradite sistem za rezervacije, so to lahko razpoložljivost terminov, vnos rezervacije, potrditev in osnovno upravljanje terminov. Napredna segmentacija strank, kompleksna poročila ali program zvestobe so lahko odlične nadgradnje, vendar ne smejo blokirati začetka.

To ne pomeni, da mora biti prva različica površna. Pomeni, da je premišljeno omejena. Jedro mora biti kakovostno: pregledno, varno, odzivno in pripravljeno na razširitve. Pri rešitvah po meri je mogoče arhitekturo načrtovati tako, da se pomembne funkcije kasneje dodajo brez rušenja že delujočega sistema.

Povezave z drugimi sistemi določite zgodaj

Veliko poslovnih aplikacij ni samostojnih otokov. Podatke potrebujejo iz računovodskega programa, skladišča, CRM-ja, plačilnega sistema, dostavne službe ali internega sistema podjetja. Povezava ni zgolj kljukica na seznamu. Treba je razumeti, kateri podatki se prenašajo, v katero smer, kako pogosto in kdo je odgovoren, če prenos ne uspe.

Če spletna aplikacija prikazuje zalogo, se odločite, ali zalogo prejema v realnem času ali se osvežuje periodično. Prva možnost daje natančnejšo informacijo, vendar je tehnično zahtevnejša in odvisna od zanesljivosti zunanjega sistema. Periodično osveževanje je lahko povsem primerna izbira, če poslovni proces dopušča nekaj zamika.

Prav tako določite vir resnice za posamezen podatek. Če se naslov stranke spremeni v CRM-ju, ali se samodejno spremeni tudi v aplikaciji? Ali ga lahko uporabnik spremeni sam? Brez jasnega odgovora se hitro pojavijo podvojeni, zastareli ali napačni podatki.

Ne pozabite na administracijo, varnost in vsakdanjo uporabo

Naročniki pogosto največ časa namenijo delu, ki ga vidi končni uporabnik, manj pa administrativnemu delu. Toda aplikacija mora ostati uporabna tudi za ekipo, ki bo urejala vsebine, potrjevala zahtevke, popravljala podatke in odgovarjala strankam. Če je administracija nepregledna, se bo operativno delo vrnilo v e-pošto in preglednice.

Pri pripravi definirajte, katere podatke lahko ekipa ureja sama, kateri procesi potrebujejo potrditev in katere spremembe morajo ostati zabeležene. Smiselni so tudi filtri, iskanje, izvozi in obvestila, vendar le tam, kjer res prihranijo čas. Administracija mora slediti delovnemu procesu podjetja, ne logiki generične predpripravljene platforme.

Varnost naj bo del funkcionalnih zahtev že na začetku. To vključuje prijavo uporabnikov, upravljanje gesel, ravni dostopa, zaščito osebnih podatkov, varnostne kopije in evidenco pomembnih dejanj. Natančen pristop je odvisen od vrste podatkov in tveganja. Portal z internimi dokumenti potrebuje drugačen nivo zaščite kot enostaven obrazec za povpraševanje, vendar nobena rešitev ne sme varnosti obravnavati kot naknadnega dodatka.

Pripravite odločitev, ne le želja

Pred začetkom razvoja naj bo za vsako ključno funkcionalnost jasno: komu je namenjena, kateri problem rešuje, kako poteka uporaba, od kod pridejo podatki, kaj se zgodi ob napaki in kako boste vedeli, da deluje. Ni treba, da vse pripravi naročnik sam. Dobra razvojna ekipa zna z usmerjenimi delavnicami iz nejasne ideje ustvariti izvedljiv načrt, postaviti prava vprašanja in opozoriti na posledice posameznih odločitev.

Pri Moxy Web takšno pripravo razumemo kot del kakovostne izvedbe, ne kot oviro pred njo. Ko so funkcionalnosti povezane s konkretnimi poslovnimi procesi, lahko nastane aplikacija, ki je estetsko dovršena, tehnično zanesljiva in prijetna za vsakdanjo uporabo.

Najboljša naslednja poteza je preprosta: izberite en proces, ki vam danes jemlje največ časa, ter ga opišite od prvega uporabnikovega koraka do končnega rezultata. Tam se običajno skriva pravo jedro spletne aplikacije.