Zakaj je ceneje 'pokvariti' Figmo kot SharePoint?
30.06.2026
Pri načrtovanju SharePoint intraneta pogosto prihaja do slabše uporabniške izkušnje zaradi neskladja med tehnično izvedbo in željami zaposlenih. Strokovnjaki iz podjetja Kompas Xnet ta problem rešujejo z UX/UI oblikovanjem klikabilnih Figma prototipov, ki omogočajo realistično testiranje pred začetkom razvoja. Zgodnje uporabniško testiranje in takojšnji popravki v Figmi znatno znižajo stroške programiranja ter drastično skrajšajo čas projektne izvedbe. Končni rezultat je intuitiven SharePoint portal po meri uporabnikov, ki povečuje produktivnost zaposlenih in učinkovito dosega poslovne cilje.
Kako s testiranjem v Figmi prihranimo čas, denar in živce?
Predstavljajte si klasičen scenarij: Po mesecih načrtovanja, sestankov in programiranja ponosno lansirate nov SharePoint intranet uporabnikom. Vse deluje tehnično brezhibno, toda že prvi teden na tehnično podporo prihajajo klici: "Kje najdem obrazec za dopust?", "Zakaj iskalnik ne najde ničesar?", "Novi portal je prekompliciran, raje bi uporabil starega." Kaj se je zgodilo? Zgodil se je razkorak med tehnično izvedbo in pričakovanji dejanskih uporabnikov.
V Kompas Xnetu se zavedamo, da je najboljši intranet tisti, ki ga zaposleni radi uporabljajo in se v njem tudi znajdejo. Zato v procesu UX/UI oblikovanja uporabljamo pristop prototipiranja, ki morda na začetku vzame nekaj ur več, a na koncu prihrani dodatne stroške in preglavice.

Uporabniško testiranje na klikabilnih Figma prototipih.
Kaj sploh je 'klikabilen' Figma prototip?
Ko naročniku pokažemo dizajn predloge portala, to ni le statična slika v formatu PNG ali JPEG. V Figmi pripravimo lahko nizkonatančen (low-fidelity) ali visokonatančen (high-fidelity) prototip, ki simulira resnično uporabniško izkušnjo, s katero se bodo srečali končni uporabniki portala.
Zahvaljujoč naprednim funkcijam Figme, kot so Prototyping Connections, Variables in Smart Animate, lahko ustvarimo izkušnjo, ki je na videz identična končnemu SharePoint portalu.
To pomeni:
• Gumbi so dejansko "klikabilni" in odprejo željene povezave
• Povezave v navigaciji delujejo in odpirajo podmenije
• Možno je drsanje po vsebini strani
• Vidimo lahko tudi, kako se portal obnaša na mobilnem telefonu
• Simuliramo animacije obvestil, zakasnitve prikaza vsebin, drsnike slik in več
Uporabnik, ki testira tak prototip, sploh ne opazi, da to ni prava aplikacija. In prav v tem je čar, da pridobimo prave “surove” informacije uporabnika, ki pokažejo ali je bila neka ideja, rešitev pravilno zastavljena in implementirana ali so potrebni še popravki.

Primer zagnanega protitpa v Figmi
Kako testiramo v praksi?
Uporabniško testiranje ni raketna znanost, zahteva pa disciplino in opazovanje. Proces testiranja poteka v treh ključnih korakih:
1. Priprava scenarija
- Z uporabnikom ne "klepetamo" o dizajnu. Namesto tega mu damo konkretne naloge:
o “Najdi podmesto – Arhiv novic in odpri eno od novic”
o ”Poglej vsebino sistemskega obvestila”
o "Najdi telefonski imenik zaposlenih”
o “Pojdi v dokumentno knjižnico in odpri dokument”
2. Opazovanje in beleženje
- Uporabnik klikne na prototip. Naša naloga je, da molčimo in opazujemo vedenje uporabnika. Kje se miška ustavi? Kje se uporabnik zmede? Kje klikne na element, ki ni gumb? Vsaka napaka uporabnika je zlata vredna informacija za nas, ki nam sporoči kje in kaj potrebujemo izpiliti, da se enaka akcija ne bo ponovila pri drugih uporabnikih.
3. Analiza in hitri popravki
- Če trije od petih uporabnikov ne najdejo navigacije, jo moramo spremeniti. Tukaj pride do izraza moč Figme, saj na primer popravek navigacije v Figmi traja nekje 15 minut, popravek iste navigacije v SharePointu pa razvijalcem lahko vzame dva dni, kar lahko povzroči dodatne stroške in podaljšanje trajanja projekta.

Primer osebnega testiranja protitipa in beleženja uporabnikovih odzivov, mnenj
Uporabniško testiranje v Figmi ni strošek, ampak je najboljša naložba v projekt in zagotovilo, da bo dejanski narisan prototip tudi v praksi resnično dosegel svoj namen. Naročnikom tovrstni pristop prinaša tri ključne prednosti:
1. Nižji stroški razvoja
- Razvijalci dobijo v roke dizajn, ki je že preverjen in potrjen. To pomeni manj dodatnih popravkov in posegov v procesu programiranja - razvoja gradnikov in manj dragih popravkov po lansiranju produkta.
2. Hitrejša pot od zasnove do postavitve
- Ker se napake odkrijejo in odpravijo zgodaj, projekt teče hitreje in brez nepotrebnih zastojev.
3. Zadovoljni končni uporabniki
- Najpomembnejše: portal je narejen po meri ljudi, ki ga bodo uporabljali vsak dan. To pomeni boljšo produktivnost in manj frustracij v podjetju.
Na koncu dneva dizajn ni le estetika, ampak orodje, ki mora služiti uporabnikom pri vsakodnevnih opravilih in poslovnim ciljem. V Kompas Xnetu ne rišemo le lepih slik, temveč gradimo digitalna okolja, ki so bila preizkušena v praksi - 'boju', še preden so ta zagledala luč sveta. Naš cilj je preprost: poskrbeti, da bo vaš naslednji SharePoint portal stičišče, kjer se bodo uporabniki počutili kot doma in ga z veseljem uporabljali, ne pa iskali izhode. Naslednjič, ko boste načrtovali in se odločali za nov ali prenovljen SharePoint portal, se vprašajte: “Si lahko privoščite, da ne bi prej testirali tega v Figmi?”

Do you have any additional questions?
For more information, we are always happy to assist you. Feel free to contact us at info@kompas-xnet.si or call us at 01 5136 990.
Contact usNovice
Naročite se na Xnet novice in ostanite na tekočem glede novih tečajev, seminarjev, možnosti pridobitve novih certificiranj in akcijskih cen.