Egy mobilalkalmazás weboldalának nem az a feladata, hogy egy nagyobb képernyőn lemásolja magát az appot. Sokkal nehezebb dolga van: ugyanazt a márkát és termékélményt kell közvetítenie úgy, hogy közben weboldalként is önállóan működjön.
A Szumma esetében pontosan ez volt a kiindulópont. Egy már létező, karakteres digitális pénzügyi termékhez kellett olyan weboldalt készítenünk, amely nem egy általános fintech-sablonra hasonlít, hanem már az első képernyőn egyértelműen a Szumma világát folytatja.
Ehhez végül nem vásároltunk kész WordPress-sablont, és page buildert sem használtunk. Az alkalmazás vizuális rendszeréből kiindulva saját webes designrendszert terveztünk, majd ehhez teljesen egyedi WordPress-témát és külön funkcionális plugint fejlesztettünk.
A kiindulási helyzet: egy digitális terméknek kellett webes arcot adni
A Szumma egy digitális pénzügyi asszisztens, amelynek célja, hogy átláthatóbbá tegye a felhasználó pénzügyeit. Összekapcsolja és rendszerezi a pénzmozgásokat, segít értelmezni a kiadásokat, támogatja a keretek követését, megtakarítási lehetőségeket jelez, és több olyan funkciót fog össze, amelyeket egy hagyományos pénzügyi alkalmazásban külön-külön kellene keresni.
Amikor elkezdtük a weboldal tervezését, maga az alkalmazás és annak vizuális identitása már létezett. Rendelkezésünkre állt a logó, az app valódi képernyőképei, a meglévő arculat, a funkciók részletes leírása, a jóváhagyott oldal- és blogszövegek, a GYIK, a jogi anyagok és a műszaki specifikáció.
Ez egy fontos keretet is adott a munkának.
Nem az volt a feladatunk, hogy átírjuk a már jóváhagyott kommunikációt, hanem az, hogy megteremtsük hozzá azt az információs és vizuális rendszert, amelyben ezek a tartalmak weben is jól működnek.
Miért mondtunk nemet a fintech WordPress-sablonokra?
A projekt elején teljesen reális lehetőségként merült fel egy kész, Envato-előfizetésből elérhető fintech WordPress-sablon használata.
Technikailag ez lett volna a gyorsabb út.
A Szumma esetében azonban hamar kiderült, hogy egy sablon használatával valójában többet veszítenénk, mint amennyit nyernénk.
A fintech-sablonok jelentős része ugyanabból a vizuális készletből dolgozik: kék-lila gradiensek, generikus dashboardok, feature-kártyák, lebegő bankkártyák, 3D érmék, glassmorphism és olyan komponensek, amelyek szinte bármelyik pénzügyi startup oldalán megjelenhetnének.
A Szummának viszont már volt saját vizuális világa.
Ezért végül abból az alapelvből indultunk ki, hogy a látogatónak lehetőleg már a logó elolvasása előtt éreznie kelljen: ez a Szumma weboldala.
Nem egy sablont próbáltunk tehát a márkához igazítani. Megfordítottuk a folyamatot: először feltérképeztük a termék vizuális nyelvét, és ebből terveztünk önálló webes rendszert.
Az alkalmazásból vezettük le a weboldal designrendszerét
A legerősebb vizuális referenciáink nem más fintech weboldalak voltak, hanem a Szumma saját alkalmazásképernyői.
Ezekből vezettük le a weboldal alapvető vizuális szabályait: a mély Szumma-kék felületeket, a narancssárga kiemeléseket, a cián adatvizualizációt, a pozitív pénzügyi visszajelzések zöld színét, a nagyméretű fehér tipográfiát és a lekerekített, világos alkalmazásfelületeket.
A Montserrat betűcsaládot önhostolt formában használtuk, a kompozícióknál pedig tudatosan eltértünk a klasszikus, egymás alá rakott háromoszlopos SaaS-szekcióktól.
A weboldal így nem próbál úgy tenni, mintha maga lenne az alkalmazás. Ugyanazt a vizuális nyelvet beszéli, de webes eszközökkel.
A pénzügyi jelút: egy grafikai elem, amely végigmeséli az oldalt
A projekt egyik legfontosabb egyedi vizuális ötlete egy egyszerű vonalból indult.
Az alkalmazás egyenleg- és budgetgrafikonjai adták az inspirációt ahhoz a motívumhoz, amelyet végül pénzügyi jelútnak neveztünk.
Nem dekorációként akartuk használni.
A jelút megjelenik a hero szekcióban, később összekapcsolja a pénzügyi folyamat egyes állomásait, idővonallá és szekcióhatárrá alakul, budgetskálaként működik, csomópontokat képez, végül pedig a fontos CTA-k irányába vezeti tovább a figyelmet.
Így a weboldal különálló blokkjai vizuálisan is összetartoznak.
A kezdőlap ezért nem egyszerűen feature-ek felsorolása. Van egy dramaturgiája: az első appélménytől eljutunk az összekapcsoláson és rendszerezésen keresztül a konkrét funkciókig, majd a technológiai és biztonsági háttérig.
Valódi appképernyők, nem kitalált fintech dashboardok
Egy alkalmazást bemutató weboldalnál könnyű belecsúszni abba, hogy a látvány kedvéért olyan dashboardokat, grafikonokat és interfészeket készítünk, amelyek valójában nem léteznek a termékben.
Ezt tudatosan kerültük.
A Szumma oldalán látható telefonmockupokban a megrendelőtől kapott valódi alkalmazásképernyőket használtuk. A webdesign feladata az volt, hogy ezeket a megfelelő környezetbe helyezze, ne pedig az, hogy egy fiktív terméket találjon ki köréjük.
Ez különösen fontos egy pénzügyi szolgáltatásnál, ahol a vizuális hitelesség közvetlenül befolyásolja a termékkel szembeni bizalmat.
A kezdőlap hero része ezért valódi appképernyőt, rövid videót és poszterképet kombinál. A mozgás nem öncélú: csökkentett mozgást kérő felhasználóknál statikus alternatíva marad, a videó pedig nem töltődik le szükségtelenül minden helyzetben.
Egy weboldal helyett saját WordPress-rendszert építettünk
A végleges megoldás két jól elkülönített saját fejlesztésű rétegből áll.
Egyedi Szumma WordPress-téma
A téma kezeli a teljes megjelenítési réteget:
- a fejlécet és a navigációt;
- a kezdőlapot;
- a funkcióoldalakat;
- a blogot;
- a GYIK-et;
- a kapcsolat- és jogi oldalakat;
- az animációkat;
- az alkalmazásképernyők kompozícióit;
- valamint a reszponzív és akadálymentes működést.
Saját Szumma Core plugin
Az üzleti és tartalomkezelési funkciókat tudatosan nem a témába építettük.
Külön plugin felel többek között:
- a Funkciók egyedi tartalomtípusért;
- a GYIK kezeléséért;
- a kapcsolati üzenetekért;
- a központi beállításokért;
- az alkalmazás-áruházi linkekért;
- a saját kapcsolatfelvételi rendszerért;
- a strukturált adatokért;
- valamint több SEO- és tartalomkezelési integrációért.
Ennek a szétválasztásnak hosszú távú oka van: a weboldal üzleti funkcionalitása nem válik egy adott vizuális témától függővé.
A rendszer nem használ Elementort, Divit vagy más általános page buildert. Nem azért, mert ezek önmagukban rossz megoldások lennének, hanem mert ennél a projektnél a teljesen egyedi komponensrendszer és a pontos technikai kontroll többet adott.
A tartalomnak a fejlesztési környezetek között is reprodukálhatónak kellett maradnia
A projektben nemcsak sablonokat és komponenseket készítettünk.
A jóváhagyott dokumentumokból strukturált tartalom készült, amelyet egy idempotens WordPress seed folyamat képes betölteni.
Ez létrehozza vagy frissíti az oldalakat, funkciókat, GYIK-elemeket, blogbejegyzéseket és menüket, valamint hozzárendeli a szükséges képeket.
Az „idempotens” itt egyszerűen azt jelenti, hogy a folyamat többször is biztonságosan lefuttatható anélkül, hogy minden futás után újabb duplikált tartalmak jelennének meg.
Ez elsőre láthatatlan technikai részletnek tűnhet, de a local fejlesztés, az éles környezet és később az angol verzió kialakításakor komoly előnyt jelentett.
Kétnyelvű weboldal, külön kezelt SEO-val
A Szumma magyar és angol nyelven is elkészült.
A kétnyelvűség Polylang-alapokon működik, de önmagában egy fordítóplugin telepítése még nem jelent jól felépített többnyelvű oldalt.
Külön kellett foglalkoznunk az angol funkcióútvonalakkal, a magyar és angol tartalmak összekapcsolásával, valamint néhány hibás canonical URL-lel is.
A technikai SEO során oldalankénti title és meta description, canonical URL-ek, XML sitemap, közösségi megosztási metaadatok, kép-altok és szemantikus címsorstruktúra készült.
A strukturált adatok között az adott tartalomtól függően Article, SoftwareApplication, Organization és FAQ schema is megjelenik.
A Google Analytics 4 és a Search Console az ügyfél saját Google-fiókjába került, hogy a weboldallal együtt az adatok tulajdonjoga is a megrendelőnél maradjon.
Saját kapcsolatfelvételi rendszer biztonsági rétegekkel
A kapcsolatfelvételi űrlapnál sem egy általános form plugint használtunk.
A saját megoldás WordPress nonce-ot, szerveroldali validációt, honeypot mezőt, beküldési időellenőrzést, átmeneti IP-alapú rate limitet, bemeneti adattisztítást és biztonságos kimenetkezelést alkalmaz.
Az üzenet először privát kapcsolati bejegyzésként a WordPressben is eltárolódik, így egy átmeneti e-mail-kézbesítési probléma önmagában nem jelenti azt, hogy az érdeklődés elveszik.
A hozzájáruláskezelési rendszert szintén a weboldal tényleges működéséhez igazítottuk. A Google Maps, a reCAPTCHA és a mérési funkciók betöltése a megfelelő hozzájárulási állapothoz igazodik.
Ez nem „GDPR-tanúsítvány”, és nem is így kommunikáljuk. A cél egy, a weboldal valós adatkezeléséhez illeszkedő technikai és tájékoztatási rendszer kialakítása volt.
Reszponzivitás és akadálymentesség nem a projekt végén került elő
A weboldalt 375, 768, 1024, 1440 és 1920 pixeles szélességeken is terveztük és ellenőriztük.
A billentyűzettel használható navigáció, a jól látható fókuszállapotok, a skip link, a megfelelő címsorstruktúra, az alternatív képszövegek és a prefers-reduced-motion támogatás már a megvalósítás részét képezték.
A fejlesztés során több olyan problémát is javítottunk, amely csak valós tartalommal vagy konkrét eszközméreten vált láthatóvá: mobilon levágott címsorokat, túl nagy blogcímeket, kontrasztproblémákat, széteső cookie-táblázatot vagy éppen túlzsúfolt funkcióblokkokat.
Ezért számunkra egy egyedi weboldal fejlesztése nem ér véget azzal, hogy egy Figma-tervet pixelekre pontosan lekódolunk.
A végleges felület a valós tartalom, a valódi eszközök és az ügyfél-visszajelzések találkozásából alakul ki.
Az ügyfél-visszajelzés nem hibajegy, hanem a fejlesztési folyamat része
A Szumma több finomhangolási körön ment keresztül.
Változott többek között a blogoldalak tipográfiája, a kezdőlapi idővonal, a mobil hero, a GYIK vizuális egyensúlya, a biztonsági szekció kontrasztja, a cashback-kalkulátor mérete, egyes appképernyők elhelyezése és az angol URL-struktúra.
Ezeknek a módosításoknak jelentős része nem azért született, mert az első verzió „rossz” volt.
Azért készültek, mert egy weboldalt nem statikus látványként kezelünk. Megnézzük valós tartalommal, valódi viewportokon, a megrendelő saját termékismeretével együtt, majd finomítjuk.
A projekt végén a megrendelő a weboldalt jóváhagyta és élesítésre alkalmasnak minősítette.
A pályázati projektben a weboldalon túl az átadásnak is rendben kellett lennie
A projekt pályázati elszámoláshoz kapcsolódott, ezért az átadásnak olyan adminisztratív és dokumentációs követelményeknek is meg kellett felelnie, amelyek egy hagyományos webprojektben nem feltétlenül jelennek meg.
Elkészült többek között az angol oldalváltozat, a szükséges támogatási kommunikáció, az analitikai és Search Console-integráció, a CMS-kezelési dokumentáció, az arculati összefoglaló és a technikai bizonyítóanyagok.
A Szummának már volt saját alkalmazásarculata, ezért nem állítjuk, hogy új márkaidentitást terveztünk.
A feladatunk az volt, hogy a meglévő alkalmazásarculatból következetes, önálló webes designrendszert vezessünk le.
Amikor egy egyszerű fejlesztési kérésre a helyes válasz nem az, hogy „megcsináljuk”
A weboldal elkészülte után egy újabb fejlesztéssel folytatódott az együttműködés.
Egy belső befektetési javaslatkészítő rendszer, a Szumma Signal esetében az eredeti kérés lényegében két statikus HTML-fájl elhelyezése volt.
Technikailag ezt gyorsan meg lehetett volna oldani.
A szó szerinti megvalósítás azonban nyilvánosan elérhető tanácsadói felületet, kliensoldalon látható webhookokat, URL-be kerülő személyes adatokat és hozzáférés-kezelés nélküli működést eredményezett volna.
Ezért nem ezt valósítottuk meg.
Külön WordPress-plugin készült saját tanácsadói jogosultságokkal, szerveroldali webhook-kommunikációval, rövid élettartamú visszaigazoló tokenekkel és olyan biztonsági korlátozásokkal, amelyek mellett a tanácsadóknak a WordPress adminisztrációhoz sincs szükségük hozzáférésre.
Számomra ez jól példázza az egyedi fejlesztés egyik kevésbé látványos, de fontos részét:
nem mindig az ügyfél által elsőként megfogalmazott technikai megoldást kell kivitelezni. Először azt kell megérteni, milyen problémát szeretne megoldani – és fel kell ismerni azt is, ha a legegyszerűbb út biztonsági vagy adatvédelmi kockázatot teremtene.
Mi lett a Szumma projekt eredménye?
A projekt végére nem egy módosított fintech WordPress-sablon született.
Elkészült egy teljesen egyedi, page builder nélküli WordPress-rendszer, saját témával és funkcionális pluginnal, magyar és angol tartalommal, részletes funkcióoldalakkal, bloggal, GYIK-rendszerrel, interaktív cashback-kalkulátorral, saját kapcsolatfelvételi megoldással, technikai SEO-val és hozzájárulás-alapú külső integrációkkal.
Később ehhez kapcsolódott a Szumma Signal védett belső rendszere is.
Mégsem a technológiai lista a projekt legfontosabb eredménye.
A lényeg számomra az, hogy a weboldal nem külön identitást kapott a termék mellé.
Ugyanazt a vizuális nyelvet beszéli, mint az alkalmazás – csak weben.
Ez az a pont, ahol szerintem egy egyedi weboldal valódi értelmet nyer.
Nem attól egyedi, hogy nincs rajta Elementor.
Attól egyedi, hogy a tervezési és technikai döntések abból a termékből, márkából és üzleti helyzetből következnek, amelyhez készültek.
Van egy alkalmazásod vagy digitális terméked?
Ha nem egy újabb sablonos landing oldalt szeretnél, hanem olyan weboldalt, amely valóban a terméked vizuális és üzleti logikájából épül fel, beszéljük át a projektet.
Gyakori kérdések az egyedi WordPress-fejlesztésről
Miért érdemes egy mobilalkalmazáshoz egyedi weboldalt készíteni?
Ha az alkalmazás már rendelkezik saját vizuális identitással, egy általános sablon könnyen eltávolíthatja a weboldalt a termék valódi karakterétől. Egyedi tervezéssel az alkalmazás vizuális nyelvéből olyan webes designrendszer vezethető le, amely önálló weboldalként működik, mégis egyértelműen ugyanahhoz a márkához tartozik.
Mit jelent a page builder nélküli WordPress-fejlesztés?
A weboldal megjelenítési rendszerét nem Elementorhoz, Divihez vagy más általános vizuális szerkesztőhöz kötjük, hanem a projekthez készített saját téma és komponensek adják. Ez nagyobb kontrollt biztosíthat a design, a működés és a technikai felépítés felett.
Egyedi WordPress-fejlesztés mellett szerkeszthető marad a weboldal?
Igen. Az egyedi fejlesztés nem jelenti azt, hogy minden tartalmi módosításhoz programozóra van szükség. A Szumma esetében az üzleti tartalmak és funkciók külön WordPress-struktúrában kezelhetők, miközben a megjelenítést saját téma biztosítja.
Készíthető kétnyelvű egyedi WordPress-weboldal?
Igen. A Szumma magyar és angol oldalváltozata összekapcsolt nyelvi struktúrában működik. Többnyelvű oldalnál azonban a fordítás mellett a megfelelő URL-ekre, canonicalokra, metaadatokra és a tartalmak közötti kapcsolatokra is figyelni kell.
Miért érdemes különválasztani a WordPress-témát és az üzleti funkciókat?
A vizuális megjelenítés és az üzleti logika különválasztása karbantarthatóbb rendszert eredményezhet. Ha egy funkció nem közvetlenül a designhoz tartozik, célszerűbb külön pluginban kezelni, hogy ne váljon egy adott témától szükségtelenül függővé.
