Standardy ISO w projektowaniu UX/UI – Języki, Daty, Waluty i Godziny
Poznaj kluczowe standardy ISO wykorzystywane w projektowaniu UX/UI. Dowiedz się, jak prawidłowo implementować normy ISO 3166, ISO 639-1 i inne, aby tworzyć lepsze interfejsy dla użytkowników z całego świata. Praktyczny przewodnik z przykładami i wskazówkami implementacji.
Dlaczego standardy ISO są ważne w UX/UI?
Wyobraź sobie sklep internetowy obsługujący klientów z różnych krajów. Platforma e-commerce, która działa globalnie, musi sprostać wielu wyzwaniom związanym z lokalizacją i personalizacją. Bez odpowiednich standardów nawet najprostsze elementy interfejsu mogą stać się źródłem frustracji dla użytkowników.
Pierwszym wyzwaniem jest prezentacja dat. Ten sam zapis „03/04/2024” może oznaczać 3 kwietnia lub 4 marca, w zależności od kraju pochodzenia użytkownika. W kontekście terminów dostaw czy promocji, takie niejednoznaczności mogą prowadzić do poważnych nieporozumień.
Kolejną kwestią jest prawidłowa prezentacja walut. Nie chodzi tylko o symbol waluty, ale także o sposób formatowania kwot. W niektórych krajach używa się przecinka jako separatora dziesiętnego, w innych – kropki. Do tego dochodzą różnice w grupowaniu cyfr i pozycjonowaniu symbolu waluty.
W tym kontekście standardy takie jak ISO 3166 i ISO 639-1 odgrywają istotną rolę, choć na pierwszy rzut oka mogą wydawać się mało istotne. W tym artykule omówimy, jak różnice między ISO 3166 a ISO 639-1 wpływają na projektowanie UX/UI oraz w jakich sytuacjach warto zastosować dany standard.
ISO 3166 w Projektowaniu UX/UI
W świecie, gdzie każdy interfejs aspiruje do miana „intuicyjnego”, prawdziwa elegancja kryje się w niewidocznych standardach. ISO 3166 jest właśnie takim standardem – cichym architektem międzynarodowych doświadczeń cyfrowych.
Wyobraźmy sobie przez moment świat bez tego standardu. Chaos. Niezliczone warianty oznaczeń krajów, konfliktujące systemy identyfikacji, kakofonię sprzecznych formatów. Zamiast tego mamy elegancką prostotę: PL, DE, US – dwuliterowy kod, który niesie ze sobą całą bibliotekę kontekstu kulturowego.
Weźmy przykład pozornie prostej transakcji w sklepie internetowym. Użytkownik z Niemiec (DE) widzi ceny w euro, z niemieckim podatkiem VAT i lokalnymi metodami płatności. Ten sam produkt, wyświetlany użytkownikowi z Polski (PL), automatycznie prezentuje się w złotówkach, z polskim VATem i opcją płatności BLIK. To nie magia – to precyzyjnie zaprojektowany system kodyfikacji.
// Elegancja w prostocie
const context = {
'PL': { currency: 'PLN', vat: 23, payment: ['blik', 'card'] },
'DE': { currency: 'EUR', vat: 19, payment: ['sepa', 'card'] }
};
Ale prawdziwa głębia ISO 3166 objawia się w szczegółach. Gdy amerykański użytkownik widzi datę „03/04/2024”, system wie, że dla niego oznacza to 4 marca, nie 3 kwietnia. Gdy francuski klient wprowadza kwotę „1.234,56”, system rozumie, że przecinek jest separatorem dziesiętnym, nie tysięcznym.
To właśnie w tej warstwie abstrakcji – gdzie kod spotyka się z kulturą – ISO 3166 pokazuje swoją prawdziwą wartość. Nie jest to tylko standard techniczny.
Paradoksalnie, największym sukcesem ISO 3166 jest jego niewidoczność. Użytkownicy nie powinni wiedzieć, że istnieje – powinni po prostu doświadczać płynnej, spersonalizowanej interakcji. To jak grawitacja w świecie cyfrowym – niewidoczna siła organizująca chaos w harmonię.
W epoce, gdzie każdy mówi o sztucznej inteligencji i blockchain, może się wydawać, że prosty standard kodów krajów to relikt przeszłości. To właśnie te fundamentalne standardy umożliwiają budowanie coraz bardziej złożonych systemów.
ISO 639-1 w Projektowaniu UX/UI
Podczas gdy ISO 3166 organizuje geograficzną mapę cyfrowego świata, ISO 639-1 zajmuje się jego językową strukturą. Te dwa standardy, pozornie niezależne, tworzą fundamentalną matrycę każdego międzynarodowego interfejsu.
Dwuliterowe kody językowe to tylko wierzchołek góry lodowej. Pod powierzchnią ’en’, ’de’ czy ’ja’ kryje się złożona sieć zależności kulturowych i technicznych. Interfejs bankowości internetowej w Japonii to nie przetłumaczona wersja europejskiego odpowiednika – to całkowicie odmienne doświadczenie, dostosowane do lokalnych oczekiwań i wzorców interakcji.
Przykłady tej adaptacji widać w codziennych interakcjach:
Netflix (US): "Continue watching"
Netflix (JP): "視聴を続ける" [z kontekstem grzecznościowym]
Netflix (DE): "Weiterschauen" [precyzyjny, techniczny ton]Inny przykład
Error 404 (PL): "Strona nie została znaleziona"
Error 404 (AR): "لم يتم العثور على الصفحة" [czytane od prawej]
Error 404 (ZH): "找不到页面" [zwięzłe, kontekstowe]W praktyce, struktura URL staje się pierwszym punktem kontaktu między standardami a użytkownikiem:
amazon.de/bücher/kindle
amazon.co.jp/本/キンドル
amazon.fr/livres/kindleGdzie pierwszy kod określa język (ISO 639-1), a drugi kraj (ISO 3166). Ta pozornie prosta konwencja rozwiązuje złożone przypadki:
example.com/en-GB/ // angielski brytyjski
example.com/en-US/ // angielski amerykański
example.com/de-CH/ // niemiecki szwajcarski
example.com/fr-CA/ // francuski kanadyjski
W praktyce oznacza to, że ten sam system e-commerce może płynnie przełączać się między różnymi kontekstami kulturowymi, zachowując spójność funkcjonalną przy jednoczesnym dostosowaniu do lokalnych preferencji. To nie jest tylko tłumaczenie – to kulturowa adaptacja na poziomie kodu.\
Praktyka pokazuje, że rozróżnienie między kodem kraju a kodem języka często staje się źródłem nieporozumień. Podczas współpracy z klientem ze Szwecji, nasz zespół początkowo założył, że 'sv’ (szwedzki) i 'SE’ (Szwecja) są wymienne. To klasyczny błąd, który ignoruje złożoność językową regionu – w Szwecji mieszkają też użytkownicy posługujący się fińskim czy arabskim. Podobnie sytuacja ma miejsce w innych regionach.
Częste błędy
- uk-UK // ❌ błędne: 'uk’ to ukraiński, 'en-GB’ to angielski brytyjski
- en-UA // ✅ poprawne: anglojęzyczny interfejs dla Ukrainy
- ua-UA // ❌ błędne: 'ua’ nie jest kodem języka
Złożone przypadki
- fr-CH // francuski w Szwajcarii
- de-CH // niemiecki w Szwajcarii
- it-CH // włoski w Szwajcarii
- rm-CH // retoromański w Szwajcarii
- ar-AE // arabski w ZEA
- en-AE // angielski w ZEA (często w biznesie)
- zh-HK // chiński (tradycyjny) w Hong Kongu
- en-HK // angielski w Hong Kongu
- fr-BE // francuski w Belgii
- nl-BE // niderlandzki w Belgii
- de-BE // niemiecki w Belgii
- es-US // hiszpański w USA (rosnący rynek)
- en-PR // angielski w Puerto Rico
W praktyce oznacza to konieczność przemyślanego podejścia do struktury URL i całej architektury aplikacji. System powinien być zaprojektowany z myślą o obsłudze wielu języków w ramach jednego kraju i tego samego języka w różnych wariantach regionalnych. To nie jest tylko kwestia techniczna – to fundament prawdziwie inkluzywnego projektowania.
ISO 8601 w Projektowaniu UX/UI – Komunikacjia Czasu
Wyobraźmy sobie globalną aplikację do zarządzania projektami. W Tokio menedżer planuje spotkanie, które ma się odbyć za tydzień. W tym samym momencie jego zespół w Nowym Jorku i Londynie musi precyzyjnie zrozumieć, kiedy to spotkanie się odbędzie. Właśnie tutaj wkracza standard ISO 8601.
ISO 8601 wprowadza elegancką prostotę do świata chaosu dat i czasu. Zamiast zastanawiać się, czy 03/04/2024 oznacza 3 kwietnia czy 4 marca, standard jednoznacznie określa: 2024-04-03. To nie tylko data – to uniwersalny język czasowy zrozumiały dla wszystkich.
Praktyczne zastosowanie w codziennym projektowaniu
Weźmy przykład aplikacji do rezerwacji lotów. Gdy użytkownik z Warszawy rezerwuje lot do San Francisco, system musi bezbłędnie komunikować:
- Czas odlotu: 2024-01-15T14:30:00+01:00 (Warszawa)
- Czas przylotu: 2024-01-15T17:30:00-08:00 (San Francisco)
Format ten, choć techniczny, zostaje następnie przedstawiony użytkownikowi w przyjaznej formie: „Wylot: 15 stycznia, 14:30 (czasu lokalnego)”.
Strefy czasowe bez bólu głowy ISO 8601-2 rozwiązuje odwieczny problem stref czasowych. Gdy zespół programistów z Indii współpracuje z designerami z Berlina, zapis 2024-01-15T09:00:00+05:30 (Bangalore) automatycznie przelicza się na 2024-01-15T04:30:00+01:00 (Berlin). Żadnych pomyłek, żadnych spóźnień na spotkania.
Interfejs musi być elastyczny. W kalendarzu aplikacji możemy pokazać:
- Format podstawowy: 2024-01-15
- Format przyjazny: 15 stycznia 2024
- Format lokalny: dostosowany do preferencji użytkownika
Przykłady Formatowania Daty: 15 stycznia 2024, 14:30:45 (z czasem lokalnym)
| Kraj/Region | Format Lokalny | Format ISO 8601 | Kolejność Elementów | Uwagi |
|---|---|---|---|---|
| USA | 01/15/2024 2:30:45 PM | 2024-01-15T14:30:45-05:00 | MM/DD/YYYY | Miesiąc przed dniem, 12h format |
| UK | 15/01/2024 14:30:45 | 2024-01-15T14:30:45+00:00 | DD/MM/YYYY | Dzień przed miesiącem, 24h format |
| Japonia | 2024年1月15日 14:30:45 | 2024-01-15T14:30:45+09:00 | YYYY年MM月DD日 | Rok-Miesiąc-Dzień z japońskimi znakami |
| Niemcy | 15.01.2024 14:30:45 | 2024-01-15T14:30:45+01:00 | DD.MM.YYYY | Kropki jako separatory |
| Polska | 15.01.2024 14:30:45 | 2024-01-15T14:30:45+01:00 | DD.MM.YYYY | Kropki jako separatory |
| Chiny | 2024年1月15日 14:30:45 | 2024-01-15T14:30:45+08:00 | YYYY年MM月DD日 | Rok-Miesiąc-Dzień z chińskimi znakami |
| Indie | 15-01-2024 14:30:45 | 2024-01-15T14:30:45+05:30 | DD-MM-YYYY | Myślniki jako separatory |
| Australia | 15/01/2024 14:30:45 | 2024-01-15T14:30:45+11:00 | DD/MM/YYYY | Dzień przed miesiącem |
| Brazylia | 15/01/2024 14:30:45 | 2024-01-15T14:30:45-03:00 | DD/MM/YYYY | Dzień przed miesiącem |
| Arabia Saudyjska | ١٥-٠١-٢٠٢٤ 14:30:45 | 2024-01-15T14:30:45+03:00 | DD-MM-YYYY | Cyfry arabskie, zapis od prawej do lewej |
ISO 3166-2 w Projektowaniu UX/UI
ISO 3166-2 to międzynarodowy standard kodowania jednostek administracyjnych państw, który jest fundamentalny w projektowaniu nowoczesnych interfejsów cyfrowych. Jego znaczenie jest kluczowe w e-commerce, aplikacjach rządowych i każdym systemie wymagającym precyzyjnej lokalizacji.
| Kraj | Kod ISO | Region | Kod Regionalny | Przykład Zastosowania |
| Polska | PL | Małopolskie | PL-12 | Regionalne strefy dostaw |
| USA | US | Kalifornia | US-CA | Stanowe stawki podatkowe (różne VAT) lub systemy prawne |
| Niemcy | DE | Bawaria | DE-BY | Lokalne święta i dni wolne |
| Chiny | CN | Guangdong | CN-GD | Specjalne strefy ekonomiczne |
| Brazylia | BR | São Paulo | BR-SP | Lokalne metody płatności |
| RPA | ZA | Gauteng | ZA-GT | Wielojęzyczność (11 języków) |
| Japonia | JP | Tokio | JP-13 | Specyficzne formaty adresów |
| Indie | IN | Maharashtra | IN-MH | Regionalne skrypty językowe |
| Australia | AU | Queensland | AU-QLD | Strefy czasowe i dostawy |
W praktyce standard ten umożliwia:
- Precyzyjne określanie lokalizacji dostaw
- Automatyczne dostosowanie podatków i opłat
- Personalizację treści zgodnie z lokalnymi wymogami
- Poprawną obsługę adresów w formularzach
Znajomość i właściwe wykorzystanie ISO 3166-2 pozwala projektantom tworzyć interfejsy, które są jednocześnie globalne w zasięgu i lokalne w działaniu, zapewniając użytkownikom naturalne i zgodne z ich oczekiwaniami doświadczenie.
ISO 15924 w Projektowaniu UX/UI:
ISO 15924 to fundamentalny standard dla projektowania wielojęzycznych interfejsów, określający kody dla różnych systemów pisma na świecie. Jest kluczowy w tworzeniu prawdziwie globalnych aplikacji i stron internetowych.
| Pismo | Kod | Język | Kierunek | Przykład Zastosowania |
| Łacińskie | Latn | Polski, Angielski | Od lewej do prawej | „Hello World” |
| Arabskie | Arab | Arabski, Perski | Od prawej do lewej | „مرحبا بالعالم” |
| Chińskie | Hans | Chiński uproszczony | Od lewej do prawej | „你好世界” |
| Cyrylica | Cyrl | Rosyjski | Od lewej do prawej | „Привет мир” |
| Japoński | Jpan | Japoński | Od lewej do prawej* | „こんにちは世界” |
| Koreański | Kore | Koreański | Od lewej do prawej | „안녕하세요 세계” |
| Devanagari | Deva | Hindi | Od lewej do prawej | „नमस्ते दुनिया” |
| Tajski | Thai | Tajski | Od lewej do prawej | „สวัสดีชาวโลก” |
| Hebrajski | Hebr | Hebrajski | Od prawej do lewej | „שלום עולם” |
| Bengalski | Beng | Bengalski | Od lewej do prawej | „ওহে বিশ্ব” |
Praktyczne Znaczenie:
- Właściwe renderowanie tekstów
- Odpowiednie układy interfejsu
- Poprawna typografia
- Obsługa mieszanych systemów pisma
Standard ten jest niezbędny w projektowaniu interfejsów, które muszą obsługiwać różne systemy pisma, zapewniając przy tym najwyższą jakość użytkowania dla wszystkich użytkowników, niezależnie od ich języka ojczystego.
ISO 3166-3 i ISO 4217-2
Historyczne i współczesne zmiany geopolityczne bezpośrednio wpływają na sposób projektowania systemów cyfrowych. Przyjrzyjmy się dwóm znaczącym przykładom: historycznemu rozpadowi ZSRR i współczesnej transformacji Sudanu.
Przykład Historyczny: Rozpad ZSRR (1991)
Kiedy Związek Radziecki przestał istnieć, kod SUN musiał zostać zastąpiony przez 15 nowych kodów. Systemy informatyczne stanęły przed wyzwaniem zachowania ciągłości historycznej przy jednoczesnym dostosowaniu do nowej rzeczywistości.
Przykładowe zmiany kodów krajów po upadku ZSRR
| Dawny Kraj | Stary Kod | Nowe Kraje | Nowe Kody | Rok Zmiany |
| ZSRR | SUN | Rosja | RUS | 1991 |
| Ukraina | UKR | 1991 | ||
| Białoruś | BLR | 1991 | ||
| Kazachstan | KAZ | 1991 |
Przykład Współczesny: Podział Sudanu (2021)
W 2021 roku Sudan przeszedł istotne zmiany administracyjne, które wpłynęły na systemy finansowe i identyfikacyjne. To wymusiło aktualizacje w systemach bankowych, aplikacjach rządowych i platformach e-commerce.
| Kraj | Waluta | Stary Kod | Nowy Kod | Rok Zmiany | Wpływ na Systemy |
| Sudan | Funt Sudański | SDG | SDG | 2021 | Nowe regiony bankowe |
| Sudan Płd. | Funt Południowosudański | SSP | SSP | 2021 | Osobne systemy płatności |
Przykłady różnic poszczególnych norm ISO
| Kraj | ISO 3166 (Kraj) | ISO 3166-2 (Region) | ISO 3166-3 (Historyczne) | ISO 639-1 (Język) | ISO 4217 (Waluta) | ISO 4217-2 (Waluta) | ISO 8601 (Data/Czas) | ISO 8601-1 (Data/Czas) | ISO 8601-2 (Strefa Czasowa) | ISO 15924 (Pismo) |
|---|---|---|---|---|---|---|---|---|---|---|
| Polska | PL | PL-MA | POL | pl | PLN | 2021-01-01T15:30:00 (24h) | 2021-01-01T15:30:00 (24h) | +/-01:00 | Latn | |
| USA | US | US-CA | en | USD | 2021-01-01T03:30:00 PM (12h) | 2021-01-01T03:30:00 PM (12h) | +/-01:00 | Latn | ||
| Wielka Brytania | GB | GB-ENG | en | GBP | 2021-01-01T15:30:00 (24h) | 2021-01-01T15:30:00 (24h) | +/-01:00 | Latn | ||
| Szwecja | SE | SE-AB | sv | SEK | 2021-01-01T15:30:00 (24h) | 2021-01-01T15:30:00 (24h) | +/-01:00 | Latn | ||
| Niemcy | DE | DE-BY | DE-BE | de | EUR | 2021-01-01T01:30:00 AM (12h) | 2021-01-01T01:30:00 AM (12h) | +/-01:00 | Latn | |
| Japonia | JP | JP-13 | ja | JPY | JPY, JPY2 | 2021-01-01T09:30:00 (24h) | 2021-01-01T09:30:00 (24h) | +/-09:00 | Jpan | |
| Chorwacja | HR | HR-21 | HRV | hr | HRK | HRV, HRK | 2021-01-01T15:30:00 (24h) | 2021-01-01T15:30:00 (24h) | +/-01:00 | Latn |
| Afganistan | AF | AF-BAL | ps, uz | AFN | AFN, AFA | 2021-01-01T04:00:00 AM (12h) | 2021-01-01T04:00:00 AM (12h) | +/-04:30 | Arab | |
| Boliwia | BO | BO-L | es, qu | BOB | BOB | 2021-01-01T04:00:00 AM (12h) | 2021-01-01T04:00:00 AM (12h) | +/-04:00 | Latn | |
| Tajwan | TW | TW-CHA | zh | TWD | TWD | 2021-01-01T08:00:00 (24h) | 2021-01-01T08:00:00 (24h) | +/-08:00 | Hant | |
| Nepal | NP | NP-P3 | ne | NPR | NPR, NPU | 2021-01-01T05:45:00 (24h) | 2021-01-01T05:45:00 (24h) | +/-05:45 | Deva |
Kiedy i do czego używać danego standardu ISO:
| Standard | Kiedy Używać |
|---|---|
| ISO 3166 | – Dostosowywanie treści do preferencji krajowych |
| – Ustalanie lokalizacji w URL-ach | |
| – Weryfikacja prawa dostępu w zależności od kraju | |
| ISO 3166-2 | – Dostosowywanie treści do konkretnych regionów |
| ISO 3166-3 | – Aktualizacje interfejsów w przypadku zmian terytorialnych |
| ISO 639-1 | – Personalizacja treści i interfejsu w zależności od języka |
| – Dostosowanie komunikatów i instrukcji dla użytkownika | |
| – Selekcja opcji językowych w interfejsie | |
| ISO 4217 | – Wybór preferowanej waluty w procesach finansowych |
| ISO 4217-2 | – Uwzględnianie alternatywnych jednostek monetarnych |
| ISO 8601, 8601-1, 8601-2 | – Prezentacja dat i czasu w spójny sposób |
| ISO 15924 | – Wyświetlanie tekstów w różnych pismach i językach |
Wnioski
W projektowaniu UX/UI, wykorzystanie standardów takich jak ISO 3166 i ISO 639-1 może znacznie poprawić jakość interakcji użytkowników. Odpowiednie zastosowanie tych standardów umożliwia dostarczenie spersonalizowanych i spójnych doświadczeń, co przekłada się na wyższą użyteczność interfejsów oraz zadowolenie użytkowników. Projektanci powinni mieć na uwadze różnice między tymi standardami i wykorzystywać je w zależności od potrzeb projektu, aby osiągnąć najlepsze rezultaty.