Frissítések értesítési rendszerének létrehozása és fejlesztése

Frissítési Rendszer magánügyfeleknek

A Frissítési Rendszer akkor hasznos, ha egy alkalmazásban, webes felületen vagy digitális szolgáltatásban a felhasználókat érthetően kell tájékoztatni az új verziókról, változásokról és fontos javításokról. A cél nem az, hogy minél több üzenet jelenjen meg. A jó megoldás inkább azt mutatja meg, mikor, kinek és milyen formában érdemes frissítési értesítést küldeni. Egy magánügyfél számára ez főleg akkor fontos, ha már van működő terméke, de a felhasználók nem veszik észre az új funkciókat, nem értik a változásokat, vagy lemaradnak a szükséges frissítésekről.

Én azt látom, hogy sok kisebb projektben a frissítési üzenetek későn kerülnek be a rendszerbe. Előbb elkészül az alkalmazás, aztán valaki rájön, hogy a felhasználónak is tudnia kellene, mi változott. Ilyenkor gyors megoldásként bekerül egy felugró ablak, egy hosszú szöveg vagy egy általános értesítés. Ez ritkán működik jól. A felhasználó vagy bezárja, vagy nem érti, miért kapta. Egy tapasztalt online szakember abban segít, hogy a frissítési értesítési rendszer logikája ne zavaró elem legyen, hanem a használat természetes része.

A Qjob.hu felületén olyan magánszakembert lehet keresni, aki távolról vállal alkalmazáslogikai, felhasználói felületi, szövegezési vagy tesztelési feladatokat. A munka többnyire online egyeztetéssel indul. A megbízó elküldi a jelenlegi képernyőket, a frissítési folyamat leírását, a problémákat és azt, hogy milyen eredményt vár. Ezután készülhet javaslat, működési terv, szöveglista, értesítési minta vagy fejlesztőnek átadható leírás.

Frissítési értesítési rendszer feladatai

Egy frissítési értesítési rendszer nem csak egy üzenetküldő rész. Több apró döntésből áll. Mikor jelenjen meg az értesítés. Mindenkinek látható legyen, vagy csak annak, akit érint. Egyszer kell megmutatni, vagy ismétlődhet. Kell-e külön rövid üzenet, részletes változáslista és visszajelzési lehetőség. Ezek a kérdések először egyszerűnek tűnnek, de rossz döntés esetén a rendszer fárasztóvá válik.

Sokan ott hibáznak, hogy minden frissítést egyformán kezelnek. Egy apró javítás nem ugyanaz, mint egy új fizetési mód, új belépési folyamat vagy fontos biztonsági változás. A felhasználó más hangnemet és más részletezést vár. Szerintem a legjobb megoldás az, ha a rendszer több szintet kezel. Lehet csendes háttérfrissítés, rövid információs üzenet, kötelező figyelmeztetés és részletes újdonságlista. Így nem lesz minden üzenet sürgősnek beállítva.

Távoli munka során a szakember általában a meglévő felületet elemzi, majd megtervezi az értesítési helyeket. Ide tartozhat a belépés utáni üzenet, az alkalmazáson belüli sáv, a profilban elérhető frissítési napló, az e-mailes tájékoztatás vagy a lekérhető verziótörténet. Nem minden projekthez kell minden elem. Egy egyszerű alkalmazásnál elég lehet egy rövid újdonságpanel. Egy összetettebb szolgáltatásnál már külön szabályrendszer kell.

Frissítési Rendszer árak

Az ár főleg attól függ, hogy csak tanácsadásra van szükség, vagy konkrét képernyőszövegek, működési logika és fejlesztői leírás is készül. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert kimaradnak a döntési helyzetek, a felhasználói állapotok és a kivételek. Tapasztalatom szerint egy jó szakember nem csak azt írja le, hogy legyen értesítés, hanem azt is, mikor ne legyen.

Az árakról érdemes már az elején pontosan beszélni. Nem elég annyit mondani, hogy kell egy frissítési rendszer. A szakembernek tudnia kell, hány felhasználói csoport van, milyen frissítések jelennek meg, van-e több nyelv, kell-e e-mail, alkalmazáson belüli üzenet vagy csak belső napló. A rövid leírás olcsóbb. A részletes tervezés drágább, de később kevesebb félreértést okoz.

Online szakember kiválasztása

Frissítési értesítésekhez nem mindig ugyanaz a szakember kell. Lehet, hogy felhasználói élményben jártas tervezőre van szükség. Máskor termékmenedzser, szövegíró, tesztelő vagy alkalmazásfejlesztő tud jobb segítséget adni. A választás attól függ, hol van a gond. Ha a rendszer működik, de a szöveg zavaros, akkor tartalmi szakember kell. Ha a logika hibás, akkor termékes vagy fejlesztői szemléletű magánszakember a jobb választás.

Érdemes portfóliót kérni, de nem csak szép képernyőket kell nézni. Fontosabb, hogy a szakember tudjon magyarázni. Miért ott jelenik meg az üzenet. Miért csak egyszer. Miért kapja meg az egyik felhasználó, és a másik miért nem. Aki ezekre röviden és tisztán válaszol, az valószínűleg érti a feladatot.

Szerintem az is fontos, hogy a megbízó ne csak árat hasonlítson. Egy frissítési értesítési rendszer sok apró részletből áll. Ha valaki túl gyorsan ad végleges árat úgy, hogy nem kérdez a felhasználói csoportokról, a meglévő hibákról és a frissítések gyakoriságáról, az kockázatot jelent. Nem biztos, hogy rossz szakember, de lehet, hogy még nem mérte fel a munka valódi méretét.

Frissítési rendszer online munkafolyamata

A távoli együttműködés általában rövid anyagküldéssel indul. A megbízó elküldi a képernyőképeket, a jelenlegi értesítéseket, a felhasználói panaszokat és a tervezett frissítéseket. Jó, ha van rövid leírás arról is, kik használják az alkalmazást. Nem kell hosszú dokumentum. De kell annyi háttér, hogy a szakember ne találgasson.

Ezután következik az elemzés. A szakember megnézi, hol akad meg a felhasználó, melyik üzenet túl hosszú, melyik hiányzik, és milyen helyzetekben kellene külön értesítés. Egy egyszerűbb feladatnál ez néhány nap alatt elkészülhet. Összetettebb rendszer esetén több kör egyeztetés kell, főleg akkor, ha több szerepkör, több fizetési állapot vagy több verzió érintett.

Volt olyan eset, amikor egy ügyfél csak egy rövid felugró ablakot szeretett volna az új funkcióhoz. A beszélgetés közben kiderült, hogy a felhasználók három különböző módon érkeznek a rendszerbe, és nem mindenkinek ugyanaz az újdonság fontos. Végül nem egyetlen üzenet készült, hanem három rövid szöveg és egy belső újdonságlista. Nem volt látványos megoldás, de működött. Kevesebb kérdés érkezett az ügyfélszolgálathoz.

A kész eredmény lehet szöveges dokumentum, táblázat, képernyőnkénti javaslat vagy fejlesztői feladatleírás. Egy jó átadásban szerepelnek a megjelenési szabályok, a szövegek, a kivételek, az ismétlési feltételek és a tesztelési pontok. Ez azért fontos, mert a fejlesztő csak azt tudja pontosan elkészíteni, ami le van írva.

Gyakori hibák frissítési értesítéseknél

A leggyakoribb hiba a túl sok értesítés. A felhasználó hamar megtanulja, hogy mindent be kell zárni. Onnantól a fontos üzenet sem kap figyelmet. A másik gond a túl technikai megfogalmazás. A verziószám, a belső modulnév és a fejlesztői kifejezés nem segít annak, aki csak használni szeretné a szolgáltatást.

Gyakori hiba az is, hogy nincs különbség tájékoztatás és cselekvést kérő üzenet között. Ha a felhasználónak csak tudnia kell valamit, elég egy rövid jelzés. Ha viszont be kell állítania valamit, mentenie kell az adatait vagy újra kell indítania az alkalmazást, akkor egyértelmű lépéseket kell kapnia. Ez apróságnak tűnik, de sok panasz innen indul.

A frissítési rendszer akkor gyenge, ha csak a fejlesztés végén gondolnak rá. Ilyenkor a szövegek kapkodva készülnek, a megjelenítés zavaró, és nem derül ki, hogy az üzenet egyszeri vagy ismétlődő. Én azt látom, hogy a jobb eredményhez már a frissítés tervezésekor érdemes eldönteni, hogyan kommunikálja majd a rendszer a változást.

Minőség és mérhető eredmény

A jó frissítési értesítési rendszer nem attól jó, hogy sok eleme van. Attól jó, hogy a felhasználó megérti, mi változott, és nem érzi felesleges megszakításnak. A minőség mérhető néhány egyszerű jel alapján. Kevesebb ismétlődő kérdés érkezik. Többen használják az új funkciót. Kevesebb panasz van a változások miatt. És a felhasználók nem hagyják figyelmen kívül az összes üzenetet.

Egy magánügyfélnek érdemes konkrét eredményt kérnie a szakembertől. Például javítási listát, képernyőnkénti ajánlást, kész szövegváltozatokat vagy fejlesztői átadót. Az általános tanács kevés. A használható munka olyan, amit tovább lehet adni, tesztelni lehet, majd be lehet építeni a termékbe.

A Frissítési Rendszer hosszabb távon akkor marad kezelhető, ha nem csak egyetlen frissítésre készül. Legyen benne ismételhető logika. Legyenek szövegminták. Legyen világos, melyik változás fontos, melyik csak háttérinformáció. Így a következő frissítésnél nem kell mindent elölről kitalálni.