Egy új funkciót könnyű felvenni a terméktervbe. Sokkal kevésbé láthatók a hozzá tartozó menük, adatmezők, hibaállapotok és támogatási esetek. A szoftver ezért gyakran egy hihető, de hiányos feltételezésből nő: több lehetőség automatikusan több értéket jelent.
A gyakorlatban az számít, hogy az ember gyorsan, érthetően és megbízhatóan be tudja-e fejezni a fő feladatot. A termékfókusz nem utasítja el az ötleteket, és nem tartja mesterségesen kicsiben az alkalmazást; minden bővítést a konkrét haszon és a felület mögötti tartós munka alapján mérlegel.
Röviden
- A funkciókat az elvégzett feladat alapján értékelje, ne a számuk szerint.
- Minden bővítés új adatokat, állapotokat, teszteket és tartós támogatási munkát hoz.
- A világos, őszintén elmagyarázott határok javítják a használhatóságot és a karbantarthatóságot.
A minőség az elvégzett feladatban mutatkozik meg
Az emberek ritkán töltenek le alkalmazást, mert bizonyos számú funkciója van. Jegyet akarnak felmutatni, kiadást rögzíteni, dokumentumot keresni, időpontot egyeztetni vagy információkat keresni. Ezért a termék szempontjából nem a funkciólista a legfontosabb mérőszám, hanem a teljes út az értelmes eredményhez.
Vegyünk egy egyszerű emlékeztető alkalmazást. Alapjához elegendő egy érthető cím, egy határidő, egy állapot és egy megbízható értesítés. A prioritási mátrix, a csapatszerepek, a chat, az időrögzítés és az automatikus szövegjavaslatok hasznosak lehetnek – de csak más vagy kiterjesztett feladatoknál. Ha egyértelmű használati forgatókönyv nélkül egészítik ki őket, akkor ugyanazon a felületen versenyeznek a tényleges céllal.
A fókuszált termék tehát három kérdéssel kezdődik: Ki használja? Milyen helyzetben? Melyik eredmény legyen jobb, mint korábban? „Mindenkinek, aki produktívabb akar lenni” nem válaszol ezekre a kérdésekre. „A magántulajdonosok a mérőállást dátummal és fényképpel akarják dokumentálni otthonuktól távol” – ezzel szemben egy ellenőrizhető feladatot ír le.
Mindegyik funkció kiterjeszti az egész rendszert
Egy új gomb ritkán csak egy új gomb. Adatok, állapotok, engedélyek és függőségek állnak mögötte. Egy exportfunkcióhoz például kijelölés, fájlformátum, hibakezelés, mentési vagy megosztási párbeszédablak, adatvédelmi döntések és több operációsrendszer-verzión végzett tesztek kellenek. A funkciónak az adatmodell későbbi változásaival is működnie kell, és érthetően le kell írni a súgóban.
Hasonló a helyzet a fiókokkal és a szinkronizálással. A látható bejelentkezés csak a kezdet. Ehhez társul az identitáskezelés, a helyreállítás, az ütközések feloldása, a szerver üzemeltetése, a biztonsági intézkedések, a törlési folyamatok és az elveszett hozzáférés támogatása. Minderre szükség lehet egy együttműködésre épülő terméknél. Egy többeszközös használatot nem igénylő személyes eszköznél ugyanez az architektúra aránytalan teher lehet.
Az Android alkalmazásarchitektúra-útmutató világos felelősségi határokat, egyetlen hiteles adatforrást és a lehető legkisebb gyakorlati összekapcsoltságot ajánlja. Ezek az alapelvek a karbantarthatóságot szolgálják, és egy termékigazságra is rámutatnak: minél több egymástól függő képességet tartalmaz a rendszer, annál több kapcsolatot kell megérteni és tartósan fenntartani.
Az egyértelműség tudatos elhagyásból is fakad
Az érthető felület támpontokat ad anélkül, hogy az embereknek a működtetésén kellene gondolkodniuk. A vizuális hierarchia, a következetesség és az ismert platformminták segítenek. Az Apple Human Interface Guidelines pontosan ezeket a szempontokat hangsúlyozza. Könnyebben megvalósíthatók, ha egy nézetnek felismerhető feladata van.
A funkciótúlterhelés gyakran nem nyilvánvaló káoszként jelenik meg. Apró döntésekkel kezdődik: egy újabb ikon a navigációs sávban, egy további szűrő a menüben, egy újabb állapot a listában. Minden kiegészítés önmagában észszerűnek tűnhet. Együtt azonban növelik a tényleges művelet előtt meghozandó döntések számát.
Ez a hatás különösen okostelefonon látható. A hely korlátozott, a használat gyakran megszakad, a figyelem pedig nem mindig osztatlan. Aki egy mérő előtt áll, vagy az ajtóban keres foglalási adatot, annak megbízható folyamatra van szüksége, nem a teljes termék bemutatására. A jó mobilfelület ezért a következő értelmes lépést helyezi előtérbe, a ritkán szükséges beállításokat pedig úgy sorolja hátrébb, hogy közben nem rejti el őket.
A szűkebb hatókör nem szünteti meg a hibákat, de lehetővé teszi az összpontosítást
A kisebb szoftver önmagában még nem megbízható. Egyetlen funkció is lehet rosszul megtervezett vagy hiányosan tesztelt. A korlátozott funkciókör azonban jobb feltételeket teremt a fontos esetek alapos kezeléséhez.
A teljes folyamat nemcsak az ideális kezdést és a sikeres befejezést foglalja magában. Mi történik, ha hiányzik egy engedély? Megmarad a már beírt adat, ha valaki megszakítja a műveletet? Újraindítás után is elérhető az eredmény? Javítható a hibás bejegyzés? Mit lát a felhasználó egy üres listán? Hogyan viselkedik az alkalmazás nagyobb betűmérettel vagy hálózati kapcsolat nélkül?
Ezek a kérdések időt igényelnek. Ha egy csapat ugyanazt az időt egyre több funkció között osztja fel, csökken az egyes folyamatokra fordítható figyelem mélysége. Az összpontosítás ezért a minőségre fordítható költségkeretről szóló döntés is: melyik az a néhány folyamat, amely különösen alapos hibakezelést, jó visszajelzést és valószerű adatokkal végzett teszteket érdemel?
A termékhatároknak egyértelműnek kell lenniük
A korlát csak akkor segít, ha nem tűnik rejtett hiányosságnak. Egy személyes eszköznek világosan jeleznie kell, ha nem támogat csapatmunkát. Egy offline alkalmazásnak el kell magyaráznia a biztonsági mentés és az eszközcsere működését. A dokumentumtároló nem keltheti módosításbiztos archívum benyomását. Az őszinte elhatárolás véd a téves elvárásoktól, és azokhoz juttatja el a terméket, akiknek valóban megfelel.
Az „Ez a funkció hiányzik” egy befejezetlen listára utal. Az „Az alkalmazás egyetlen személy számára készült egy eszközön” ezzel szemben termékdöntést és annak következményeit írja le. A határ ugyanaz marad, de a használati forgatókönyv révén érthetővé válik.
A jó hatókörnek összefüggőnek is kell maradnia. Nem kell minden elképzelhető funkciót tartalmaznia, de a meglévő adatoknak értelmesen együtt kell működniük. Egy feladat akkor hasznosabb, ha egyértelmű, mihez kapcsolódik; egy dokumentum értékét is növeli a megfelelő hozzárendelés. A fókusz tehát nem elszigetelt minialkalmazások építését jelenti, hanem egy kicsi, mégis teljes rendszert.
Amikor valóban van értelme a bővítésnek
Nem minden új ötlet jelent funkciótúlterhelést. A termékeknek tanulniuk és fejlődniük kell. Hasznosak azok a szempontok, amelyek ellenőrizhetővé teszik a bővítést:
- Megoldja a világosan megnevezett célcsoport visszatérő problémáját.
- Ahelyett, hogy önálló termékágat nyitna, egy meglévő alapfolyamatot erősít meg.
- Sikere jobb eredménnyel írható le, nem csupán az új gomb használatával.
- Az adatkövetelmények, az engedélyek és a hibaviselkedés ésszerűek.
- A funkció akadálymentesen, érthetően és a megfelelő eszközökön valósítható meg.
- A fejlesztés, a tesztelés, az üzemeltetés és a későbbi változtatások fenntarthatók.
Különösen fontos megvizsgálni, mi történik a bővítés nélkül. Ma az alkalmazáson kívül kell rögtönözniük a felhasználóknak egy központi lépést? Akkor valódi hiány lehet a termékben. Ha az új funkció csupán kényelmi elem, miközben az alapfolyamat már teljesen működik, más minőségi fejlesztésekkel együtt kell mérlegelni.
Egy rendezett ötletlista gyakran jobb az automatikus igennél vagy nemnél. Lehetővé teszi, hogy a csapat megfigyeléseket gyűjtsön, összevonja a hasonló igényeket, és először a valódi okot értse meg. A „több szűrő” kérése valójában rossz elnevezésekre utalhat, a „modellel támogatott keresés” pedig egyszerűen egy jól strukturált helyi teljes szöveges keresés iránti igényt jelezhet.
A fókusz nem egyszeri MVP döntés
Az úgynevezett Minimum Viable Product fogalmát néha úgy értelmezik félre, mint a lehető legkisebb első változatot, amely később elkerülhetetlenül átfogó rendszerré nő. A termékfókusz ennél hosszabb távú. Egy bevett eszköznél is rendszeresen ellenőrizni kell, hogy a funkciók hozzájárulnak-e a célhoz.
Ez jelentheti a ritkán használt változatok egységesítését, a homályos beállítások eltávolítását vagy egy összetett integráció megszüntetését. Az ilyen döntések alapos megfigyelést és a meglévő felhasználók körültekintő kezelését igénylik. Nehezebbek, mint újabb elemet tenni az ütemtervbe, de jelentősen javíthatják a terméket.
A karbantarthatóság itt központi szerepet játszik. A világos modulok és felelősségek megkönnyítik a tesztelést és a változtatásokat. Még fontosabb az egyértelmű szakterületi szerkezet: a kifejezések legyenek következetesek, ugyanazt az adatot ne tartsák karban több helyen eltérően, a munkafolyamatok pedig ne függjenek véletlen mellékhatásoktól. A műszaki architektúra nem mentheti meg a tisztázatlan termékkört, de fenntarthatóvá teheti a világos hatókört.
Az akadálymentesítés profitál a korai döntésekből
Az akadálymentesítés jó példa arra, hogy a minőséget miért nem szabad későbbi kiegészítő funkcióként kezelni. A W3C WAI azt javasolja, hogy az akadálymentesítést korán és ismételten vegyék bele a tervezésbe, megvalósításba és értékelésbe. A megfelelő kontraszt, érthető kifejezések, nagyobb betűméret, billentyűzet vagy képernyőolvasó használat befolyásolja a termék alapformáját.
Túlterhelt felületen ezek a követelmények költségesebbé válnak. A több interakció több fókuszsorrendet, címkét, állapotot és tesztelendő kombinációt jelent. A világos struktúra önmagában nem teszi akadálymentessé a terméket, de teret teremt arra, hogy az akadálymentesítést minden alapfolyamat részeként kezeljék.
Ugyanez vonatkozik az adatvédelemre és a biztonságra. Ha egy funkciót csak a felületén keresztül vizsgálnak, a szükséges engedélyek, adatfolyamok és törlési szabályok későn derülnek ki. A funkció teljes termékdöntésként való értékelése megmutathatja, hogy egy egyszerűbb, hagyományos megoldás ugyanazt az előnyt kevesebb kockázattal éri el.
A legjobb funkciólistának világos indokai vannak
Nincs ideális funkciószám. Az számít, hogy minden elemnek világos szerepe legyen, a termék pedig érthető, tesztelhető és fenntartható maradjon. A növekedés csak akkor haladás, ha valóban erősíti a fő feladatot.
Egy jó alkalmazásnak nem kell mindent tudnia. Világosan meg kell mutatnia a célját, végig kell támogatnia a megfelelő folyamatot, és őszintén kell közölnie a határait. Ez az egyértelműség gyakran többet mond a termék minőségéről, mint a leghosszabb összehasonlító táblázat.
Források és további olvasnivalók
- Apple Human Interface Guidelines – a hierarchia, a konzisztencia és a platformnak megfelelő tervezés elvei.
- Android Fejlesztők: Útmutató az alkalmazásarchitektúrához – felelősségi határok, adatmodellek, tesztelhetőség és karbantarthatóság.
- W3C WAI: A webes akadálymentesítés tervezése és kezelése – az akadálymentesítés mint a termékfejlesztés folyamatos része.
