Responsive dizajn – što treba testirati?

Responsive dizajn znači da se web prilagođava različitim veličinama ekrana.

To zvuči jednostavno.

Desktop verzija ima tri stupca.

Na tabletu dva.

Na mobitelu jedan.

Gotovo.

U praksi nije tako.

Responsive web nije kvalitetan samo zato što ništa ne izlazi izvan ekrana.

Treba provjeriti:

• redoslijed sadržaja
• navigaciju
• CTA-ove
• forme
• tipografiju
• slike
• tablice
• modale
• interaktivne elemente
• različite visine i širine ekrana

Dobar responsive dizajn znači da korisnik može normalno koristiti web bez obzira na uređaj.

Ne samo da ga može otvoriti.

Nije dovoljno smanjiti desktop

Jedna od najčešćih grešaka je prvo napraviti desktop stranicu, a zatim sve elemente samo smanjivati dok ne stanu na mobitel.

Rezultat može tehnički biti responsive.

Ali korisnički put često ostane prilagođen velikom ekranu.

Primjer:

Na desktopu hero sadrži:

• veliki naslov
• podnaslov
• dva CTA-a
• ilustraciju
• nekoliko trust elemenata

Sve stane u jedan ekran.

Na mobitelu isti sadržaj može zauzeti tri ili četiri ekrana.

Korisnik glavnu uslugu vidi odmah, ali sadržaj nakon hero sekcije tek nakon dugog scrolla.

Responsive dizajn zato zahtijeva ponovno razmišljanje o prioritetima.

O tome detaljnije govorimo u vodiču što je mobile-first dizajn.

Testirajte širinu, ne uređaj

Često ćete čuti:

Treba testirati iPhone, Samsung i tablet.

To ima smisla.

Ali još važnije je testirati ponašanje layouta kroz različite širine.

Problem se može pojaviti na 912 px širine, iako:

• 1024 px izgleda dobro
• 768 px izgleda dobro

Responsive dizajn ne sastoji se od nekoliko statičnih screenshotova.

Layout mora funkcionirati između breakpointa.

Breakpoint nije uređaj

Breakpoint predstavlja točku na kojoj se layout mijenja.

Primjer:

Desktop
↓
1200 px

Tablet
↓
768 px

Mobile

Ali 768 px nije “tablet” u fizičkom smislu.

To je samo širina pri kojoj smo odlučili promijeniti layout.

Dobar breakpoint treba proizlaziti iz sadržaja.

Ako navigacija više ne stane na 940 px, možda se upravo tamo treba promijeniti.

Nema razloga čekati proizvoljnih 768 px samo zato što ih framework koristi kao default.

Resize test

Jedan od najjednostavnijih testova je ručno mijenjati širinu browsera.

Polako smanjujte ekran.

Gledajte trenutak kada:

• tekst počne loše lomiti
• navigacija postane tijesna
• kartice postanu preuske
• CTA-i se sudare
• elementi počnu izlaziti iz viewporta

Tako možete pronaći probleme između standardnih breakpointa.

Testirajte hero

Hero je često najkompleksnija sekcija stranice.

Treba provjeriti:

• dužinu H1-a
• podnaslov
• CTA gumbe
• fotografiju
• vertikalni razmak
• redoslijed elemenata

Na desktopu može raditi:

tekst lijevo + slika desno

Na mobitelu treba odlučiti:

tekst pa slika

ili:

slika pa tekst

Najčešće glavna poruka treba imati prednost.

Dugi naslovi

Testiranje samo kratkog placeholder naslova može stvoriti lažni osjećaj sigurnosti.

Primjer:

SEO usluge

stane gotovo svugdje.

Ali pravi H1 može biti:

SEO optimizacija za male i srednje tvrtke

Na užem ekranu ponašanje je potpuno drugačije.

Zato layout treba testirati sa stvarnim sadržajem.

Ne samo s idealnim demo tekstom.

Hrvatski tekst

Ovo je posebno važno kod hrvatskog jezika.

Riječi često mogu biti duže nego u dizajnerskom placeholder tekstu na engleskom.

Primjer:

održavanje web stranica

ili:

optimizacija za tražilice

mogu napraviti potpuno drugačiji prijelom.

Ako je dizajn napravljen s:

Learn more

treba provjeriti što se događa kada stvarni CTA postane:

Dogovorite besplatne konzultacije

Navigacija

Desktop navigacija često je prvi element koji se mora mijenjati.

Treba provjeriti:

• koliko stavki stane
• što se događa s dugim nazivima
• kada se aktivira mobile menu
• je li CTA i dalje dostupan
• rade li podizbornici

Ako se logo, menu i CTA počnu gurati jedni u druge, breakpoint je vjerojatno postavljen prekasno.

Mobile menu

Hamburger menu treba zasebno testirati.

Provjerite:

• otvara li se
• zatvara li se
• radi li klik izvan menija
• postoji li jasan close button
• može li se scrollati
• rade li dropdowni
• zatvara li se nakon klika na link

Posebno provjerite što se događa ako menu ima više sadržaja od visine ekrana.

Korisnik mora moći doći do zadnje stavke.

Sticky header

Sticky header može biti koristan.

Ali na manjem ekranu lako zauzme previše prostora.

Ako header ima:

• logo
• CTA
• hamburger
• dodatnu top traku

može zauzeti značajan dio ekrana.

Provjerite i što se događa tijekom scrolla.

Header ne bi trebao:

• treperiti
• skakati
• prekrivati anchor sadržaj

CTA-i

CTA gumbe treba testirati na više širina.

Problem često nastane kada su dva gumba u istom redu.

Primjer:

Zatražite ponudu

Dogovorite besplatne konzultacije

Na širokom desktopu izgledaju dobro.

Na manjem laptopu možda više ne stanu.

Na mobitelu ih je često bolje postaviti vertikalno.

Više o hijerarhiji CTA-ova možete pronaći u članku gdje postaviti CTA na web stranici.

Klikabilna površina

Na desktopu korisnik koristi precizan miš.

Na mobitelu koristi prst.

Zato treba testirati:

• menu stavke
• gumbe
• ikone
• checkboxove
• slider kontrole
• accordion strelice

Mala ikona može izgledati dovoljno velika vizualno, ali touch target može biti premalen.

Hover

Element koji ovisi samo o hoveru neće raditi isto na touch uređaju.

Primjer:

Kartica prikazuje CTA samo kada korisnik prijeđe mišem preko nje.

Na mobitelu nema klasičnog hover ponašanja.

Važan sadržaj ne smije biti dostupan samo na hover.

Kartice

Grid s karticama često izgleda ovako:

Desktop

4 kartice u redu.

Tablet

2 kartice.

Mobile

1 kartica.

To je normalan početak.

Ali treba provjeriti i:

• jesu li kartice iste visine
• što se događa s dugim naslovima
• koliko sadržaja imaju
• postaje li stranica predugačka

Ako 12 kartica na mobitelu postane 12 vrlo visokih blokova, možda treba promijeniti način prikaza sadržaja.

Redoslijed kartica

CSS grid i flex mogu vizualno promijeniti redoslijed.

Treba paziti da redoslijed ostane logičan.

Korisnik koji koristi keyboard ili screen reader ne bi trebao dobiti potpuno drugačiji slijed od onoga što vidi na ekranu.

Responsive promjena treba očuvati smisao sadržaja.

Tablice

Tablice su jedan od najčešćih problema.

Posebno:

• cjenici
• usporedbe paketa
• tehničke specifikacije

Na mobitelu tablica može biti preširoka.

Moguća rješenja su:

• horizontalni scroll
• kartice
• accordion
• pojednostavljena tablica

Treba testirati stvarne podatke.

Tablica s kratkim demo riječima možda stane.

Prava tablica s dugim nazivima neće.

Cjenici

Kod paketa treba provjeriti može li korisnik jednostavno usporediti:

• cijene
• karakteristike
• CTA

Ako su tri paketa na desktopu jedan pored drugoga, na mobitelu postaju jedan ispod drugoga.

Tada korisnik može zaboraviti što je sadržavao prvi paket dok dođe do trećeg.

Možda treba dodatno istaknuti ključne razlike.

Našu komercijalnu strukturu možete vidjeti na stranici izrada web stranica – cijena i paketi.

Slike

Slika treba kvalitetno reagirati na promjenu širine.

Provjerite:

• mijenja li veličinu
• zadržava li proporcije
• cropa li važan sadržaj
• izlazi li iz containera
• učitava li odgovarajuću verziju

Posebno kod fotografija ljudi treba paziti da responsive crop ne odsiječe lice.

Tehničku optimizaciju detaljnije objašnjavamo u vodiču kako optimizirati slike za web.

Background slike

Background slika može izgledati odlično na širokom desktopu.

Na uskom ekranu cover može odrezati vrlo velik dio fotografije.

Ako je važan subjekt na rubu slike, možda potpuno nestane.

Treba testirati:

• object position
• background position
• alternativni mobilni vizual

Nekad ima smisla koristiti drugu sliku za mobitel.

Video

Responsive video mora zadržati pravilan omjer.

Čest problem je:

• overflow
• pogrešna visina
• crne trake
• video širi od containera

Embedded YouTube ili Vimeo sadržaj također treba provjeriti.

Iframe koji ima fiksnu širinu može lako slomiti mobilni layout.

Forme

Forma zahtijeva posebno testiranje.

Provjerite:

• jesu li inputi dovoljno široki
• stanu li labeli
• rade li error poruke
• postoji li horizontalni overflow
• može li korisnik normalno scrollati
• radi li submit

Polja koja su na desktopu u dva stupca na mobitelu najčešće trebaju postati jedan stupac.

Detaljnije smo to prošli u članku kako napraviti dobru kontakt formu.

Tipkovnica na mobitelu

Forma ne završava layoutom.

Treba otvoriti stvarni input i vidjeti što radi mobilna tipkovnica.

Provjerite:

• je li aktivno polje vidljivo
• scrolla li browser pravilno
• je li submit gumb dostupan
• zatvara li modal tipkovnica
• koristi li e-mail polje odgovarajuću tipkovnicu

To se često ne vidi u običnom responsive previewu.

Modal

Modal koji izgleda odlično na desktopu može na mobitelu postati neupotrebljiv.

Provjerite:

• stane li u viewport
• može li se scrollati
• je li close button vidljiv
• što radi tipkovnica
• postoji li sadržaj ispod donjeg ruba

Ako modal sadrži kompleksnu formu, zasebna stranica može biti bolje rješenje.

Cookie banner

Cookie banner obavezno testirajte na manjem ekranu.

Može se dogoditi da:

• zauzme gotovo cijeli ekran
• CTA-i nisu vidljivi
• korisnik ne može scrollati
• close ili settings gumb ne stanu

Element koji se pojavljuje svakom novom korisniku zaslužuje ozbiljno testiranje.

Chat widget

Chat widget vrlo često izgleda bezazleno na desktopu.

Na mobitelu može prekrivati:

• CTA
• cookie banner
• formu
• sticky navigaciju

Treba provjeriti kako se ponaša zajedno s drugim fixed elementima.

Horizontalni overflow

Jedan od najčešćih bugova je da cijela stranica može malo kliziti lijevo-desno.

Uzrok može biti:

• preširok element
• negativni margin
• transform
• slika
• tablica
• fiksna širina

Horizontalni scroll često je znak da neki responsive detalj nije dobro riješen.

Fiksne širine

Element poput:

width: 700px

može biti potpuno normalan na desktopu.

Na mobitelu širine 390 px neće.

Zato treba paziti gdje se koriste fiksne dimenzije.

Često je bolje koristiti:

• max-width
• width: 100%
• fleksibilne gridove

ovisno o elementu.

Min-width

I min-width može nenamjerno slomiti layout.

Primjer:

Kartica ima minimalnu širinu od 450 px.

Sve izgleda normalno dok viewport ne padne ispod toga.

Tada cijela stranica dobije horizontalni overflow.

Ovakve probleme je lako pronaći resize testom.

Dugi URL-ovi

Tekst također može napraviti overflow.

Posebno:

• dugi URL
• e-mail
• duga riječ
• kod
• ID
• tablični podatak

Treba testirati sadržaj koji se ne može prirodno prelomiti.

Kod blog članaka posebno pazite na code blockove.

Code blockovi

Kod ili terminal output može biti puno širi od mobilnog ekrana.

Najčešće je bolje omogućiti horizontalni scroll unutar code blocka.

Ne cijele stranice.

To zadržava layout stabilnim.

Fontovi

Responsive test treba uključiti stvarno učitavanje fontova.

Custom font može imati drugačije dimenzije od fallbacka.

To može promijeniti:

• broj redova naslova
• visinu gumba
• širinu navigacije

Više o tome pročitajte u članku kako fontovi utječu na brzinu weba.

Font size

Ne treba samo linearno smanjivati tipografiju.

H1 od 64 px na desktopu možda ne treba biti 24 px na mobitelu.

Treba pronaći veličinu koja:

• zadržava hijerarhiju
• stane na ekran
• ostane čitljiva

Fluid typography može pomoći, ali i nju treba testirati na rubnim širinama.

Line-height

Ako se font smanji, a line-height ostane isti, naslov može izgledati previše razmaknuto.

Ako je line-height prenizak, višeredni naslov može izgledati zbijeno.

Zato responsive tipografija nije samo font-size.

Prazan prostor

Desktop layout često koristi velike vertikalne razmake.

Na mobitelu isti spacing može proizvesti beskonačno dugu stranicu.

Primjer:

Desktop section padding:

120 px

Na mobitelu možda ima više smisla:

64 px

Ne treba sve proporcionalno smanjiti, ali ritam treba ponovno procijeniti.

Premalo prostora

Ni druga krajnost nije dobra.

Ako sve stisnemo kako bi stranica bila kraća:

• tekst postaje zbijen
• CTA-i se dodiruju
• sekcije se teško razlikuju

Responsive dizajn treba zadržati dovoljno prostora za jasnoću.

Footer

Footer se često testira posljednji.

A može sadržavati:

• nekoliko stupaca
• linkove
• kontakt
• društvene mreže
• newsletter
• pravne informacije

Na mobitelu treba provjeriti:

• redoslijed
• razmake
• linkove
• dužinu sadržaja

Footer s pet stupaca često treba potpuno drugačiju strukturu.

Accordioni

Accordion treba testirati u otvorenom i zatvorenom stanju.

Provjerite:

• pomiče li sadržaj normalno
• može li se otvoriti više elemenata
• radi li animacija
• ostaje li naslov vidljiv
• može li se koristiti touchom

FAQ može izgledati dobro zatvoren, a potpuno se raspasti kada se otvori dugačak odgovor.

Slider

Carousel treba testirati i bez miša.

Provjerite:

• swipe
• touch
• strelice
• dots
• veličinu sadržaja
• visinu slajdova

Ako slajdovi imaju različitu količinu teksta, cijeli layout može stalno mijenjati visinu.

To nije uvijek dobro iskustvo.

Landscape

Mobilni test često znači samo portrait.

Ali vrijedi okrenuti uređaj i u landscape.

Tada se mijenja:

• visina viewporta
• navigacija
• modal
• sticky elementi

Posebno problemi nastaju kod elemenata koji imaju:

height: 100vh

na mobilnim browserima.

Visina ekrana

Dva mobitela mogu imati jednaku širinu, ali različitu visinu.

Hero koji je dizajniran da točno stane u jedan viewport možda će na jednom uređaju izgledati dobro, a na drugom sakriti CTA.

Responsive testiranje zato ne bi trebalo gledati samo širinu.

Browser UI

Mobilni browser ima vlastite kontrole.

Address bar se može:

• pojaviti
• sakriti
• promijeniti visinu viewporta

To može utjecati na fullscreen sekcije.

Elementi temeljeni na viewport height vrijednostima zaslužuju dodatno testiranje.

Safari

Safari, Chrome i Firefox ne renderiraju baš sve identično.

Posebno problemi mogu nastati s:

• formama
• sticky elementima
• viewportom
• fontovima
• CSS funkcionalnostima

Ne morate testirati svaki browser koji postoji.

Ali glavne browsere koje stvarno koriste vaši korisnici treba pokriti.

iOS i Android

Browser emulator u DevToolsima je odličan alat.

Ali ne zamjenjuje potpuno pravi uređaj.

Stvarni iPhone ili Android može otkriti probleme poput:

• ponašanja tipkovnice
• touch interakcija
• sticky elemenata
• scrolla
• browser UI-a

Zato barem osnovni smoke test treba napraviti i na stvarnom uređaju.

Tablet

Tablet često ostane zaboravljen između desktopa i mobitela.

A upravo tu se mogu pojaviti čudni layouti.

Primjer:

desktop breakpoint još je aktivan, ali nema dovoljno mjesta za cijelu navigaciju.

Ili mobile layout već radi, ali elementi izgledaju previše rastegnuto na širokom tabletu.

Tablet zaslužuje vlastitu provjeru.

Mali laptop

Isto vrijedi za manje laptope.

Dizajn napravljen na monitoru od 1920 px može izgledati dobro.

Ali na laptopu širine oko 1366 px:

• hero možda postane tijesan
• menu se sudara
• četiri kartice više ne stanu dobro

Desktop nije jedna rezolucija.

Zoom

Vrijedi testirati i browser zoom.

Korisnik može povećati prikaz.

Kod 200% zooma layout se može ponašati slično užem viewportu.

To je relevantno i za accessibility.

Ako web potpuno pukne kada korisnik poveća sadržaj, responsive implementacija nije dovoljno fleksibilna.

Stvarni sadržaj

Jedno od najvažnijih pravila:

testirajte s pravim sadržajem.

Ne samo:

Lorem ipsum.

Pravi sadržaj ima:

• duge naslove
• kratke naslove
• različite slike
• različite cijene
• različite količine teksta

Layout treba podnijeti realne varijacije.

Najduži mogući sadržaj

Kod komponenti testirajte i ekstrem.

Ako kartica obično ima naslov od tri riječi, probajte deset.

Ako CTA obično glasi:

Kontakt

testirajte:

Dogovorite besplatne konzultacije

Ako layout tada potpuno pukne, komponenta nije dovoljno robusna.

Najkraći sadržaj

I vrlo kratak sadržaj može otkriti problem.

Ako jedna kartica ima tri odlomka, a druga samo jednu riječ, je li raspored i dalje dobar?

Responsive komponenta treba funkcionirati u različitim sadržajnim scenarijima.

Stanja greške

Nemojte testirati samo idealno stanje.

Provjerite:

• error poruke
• prazne rezultate
• loading
• form validation
• 404

Error poruka od dvije linije može na mobitelu promijeniti cijeli layout forme.

To treba biti očekivano.

Loading state

Skeleton, spinner ili loader također mora biti responsive.

Ne treba doći do situacije da loading placeholder ima desktop širinu veću od mobilnog ekrana.

I loading je dio UX-a.

Empty state

Ako nema:

• projekata
• proizvoda
• rezultata pretrage

što korisnik vidi?

Empty state treba također raditi na svim veličinama.

Ne samo glavna idealna verzija stranice.

Accessibility

Responsive i accessibility često se preklapaju.

Treba provjeriti:

• keyboard navigaciju
• focus stanje
• zoom
• kontrast
• redoslijed sadržaja

Posebno pazite da responsive promjene ne sakriju važan sadržaj korisnicima assistive tehnologija.

Nemojte samo sakriti problem

Čest responsive “fix” je:

display: none;

Element ne stane?

Sakrij ga na mobitelu.

To ponekad ima smisla za čistu dekoraciju.

Ali ako se radi o:

• cijeni
• CTA-u
• važnoj informaciji

to nije pravo rješenje.

Mobilni korisnik ne treba dobiti lošiju informaciju samo zato što ima manji ekran.

Testirajte performanse

Responsive dizajn i performanse također su povezani.

Ako na mobitelu vizualno sakrijete veliku desktop sliku CSS-om, browser ju možda svejedno preuzima.

Korisnik tada plaća performance cijenu elementa kojeg uopće ne vidi.

Responsive implementacija treba kontrolirati i resurse.

Širu performance sliku možete pronaći u članku kako brzina weba utječe na korisnike i SEO.

DevTools je početak

Browser DevTools omogućuje brzo testiranje velikog broja širina.

Koristan je za:

• breakpointove
• overflow
• layout
• osnovni touch preview

To treba biti dio svakodnevnog razvoja.

Ali nije jedini test.

Pravi uređaji

Prije objave web bih barem otvorio na:

• jednom iPhoneu
• jednom Androidu
• desktopu
• laptopu ili tabletu ako je moguće

Ne treba kupiti laboratorij s 50 uređaja.

Ali stvarni uređaji otkrivaju probleme koje emulacija može propustiti.

BrowserStack i slični alati

Kod ozbiljnijih projekata postoje servisi za udaljeno testiranje velikog broja:

• browsera
• operativnih sustava
• uređaja

To može biti korisno kada je potrebna šira kompatibilnost.

Za jednostavan mali poslovni web možda nije potrebno svaki put.

Opseg testiranja treba odgovarati važnosti projekta.

Responsive checklist

Prije objave provjerite barem:

Layout

• nema horizontalnog scrolla
• sekcije se pravilno slažu
• breakpointovi imaju smisla

Tipografija

• naslovi ne pucaju
• tekst je čitljiv
• razmaci su dobri

Navigacija

• desktop menu radi
• mobile menu radi
• dropdowni su dostupni

CTA

• gumbi stanu
• lako ih je kliknuti
• nisu prekriveni

Slike

• pravilno se skaliraju
• crop je dobar
• ne učitavaju se nepotrebno velike verzije

Forme

• sva polja rade
• error poruke stanu
• tipkovnica ne blokira formu

Komponente

• accordioni rade
• modali rade
• slideri rade
• tablice su upotrebljive

Uređaji

• desktop
• tablet
• mobile portrait
• mobile landscape

Automatizacija može pomoći

Dio responsive provjera može se automatizirati.

Primjerice, end-to-end test može otvoriti stranicu na nekoliko viewporta i provjeriti:

• postoji li glavni CTA
• otvara li se menu
• radi li forma

Visual regression test može pomoći otkriti neočekivanu promjenu layouta.

Ali automatizacija ne zamjenjuje potpuno ljudsku procjenu.

Test može potvrditi:

gumb postoji.

Ne mora znati:

gumb izgleda loše i preblizu je drugom elementu.

Responsive nije gotov na jednom screenshotu

Čest problem u projektu je:

Evo mobilnog dizajna.

Jedan Figma frame od 390 px nije kompletna responsive specifikacija.

Developer mora znati što se događa:

• na 320 px
• na 480 px
• na 768 px
• između desktopa i tableta

Zato dizajn treba definirati ponašanje, a ne samo nekoliko statičnih stanja.

Komponente trebaju biti fleksibilne

Dobra komponenta treba podnijeti različite situacije.

Primjer kartice usluge:

• različita dužina naslova
• različit opis
• opcionalna ikona
• CTA

Ako komponenta radi samo s jednim točno određenim tekstom, teško ju je dugoročno održavati.

Responsive dizajn i skalabilnost komponenti idu zajedno.

Responsive je dio QA-a

Responsive testiranje ne treba ostaviti developeru da ga “usput pogleda”.

Treba ga tretirati kao normalan dio QA-a.

Posebno treba testirati:

• glavne korisničke putove
• kritične breakpointove
• interakcije
• forme

Web koji izgleda dobro na desktop screenshotu nije završen projekt.

Prije objave

Responsive provjera treba biti dio završnog testiranja prije lansiranja.

Ne treba čekati da korisnik nakon objave pošalje:

Na mom mobitelu gumb izlazi iz ekrana.

Takve probleme je relativno lako pronaći unaprijed.

Zato responsive testiranje treba biti dio cijelog procesa izrade web stranice.

Nakon objave

Ni tada posao nužno nije gotov.

Analytics može pokazati:

• koje uređaje ljudi stvarno koriste
• koje rezolucije dominiraju
• postoje li razlike u konverzijama

Ako desktop konvertira dobro, a mobile izrazito loše, to je signal za daljnju analizu.

Podaci stvarnih korisnika mogu pokazati probleme koje niste očekivali tijekom razvoja.

Cilj responsive dizajna

Cilj nije da web izgleda identično na svakom ekranu.

To često nije ni poželjno.

Cilj je da na svakom uređaju:

• poruka ostane jasna
• sadržaj bude čitljiv
• navigacija radi
• CTA je dostupan
• interakcije su jednostavne

Desktop može imati kompleksniji layout.

Mobitel može biti jednostavniji.

Ali oba trebaju omogućiti korisniku da ostvari isti osnovni cilj.

Ako želite krenuti od same logike dizajna za male ekrane, pročitajte što je mobile-first dizajn.

Ako vas zanimaju širi problemi koji se često pojavljuju tijekom korištenja stranice, pogledajte i najčešće UX greške na web stranicama.

Ako planirate novu poslovnu stranicu, pogledajte naše pakete i cijene izrade web stranica.