MIRRI Pracovná skupina K9.5 Lepšie služby - Dizajn manuál

Pracovné skupiny
1

V skupine k9.5 na urade zacala tento tyzden tema - dizajn manual. Zodpovedny za tuto temu je Stefan Szilva a veduci skupiny je Tomas Revaj.

Prvotna uloha je ustrazit scope tohto materialu (vystupom ma byt plan toho co sa ide robit).

Tu je kratky zapis zo stvrtka 19.1.

  • vystupy maju byt do 31. maja.
  • previazane s vystupmi - strategicka priorita - interacia s verejnou spravou.
  • dizajn manual
    • Utvar hodnoty za peniaze odporuca pouzitie UK design/service manual (nepamatam si kde, zistim)

SUXA

  • nielen testovanie UX potom, ale hlavne vyskum (potreby) predtym. Dolezity je proces, nie farbicky

  • potrebne su tri piliere: dizajn manual, patterny, procesy

  • NASES planuje “prefarbickovat” schranky

  • navrhuje - sutaz navrhov na farbicky dizajn manual - a potom na to preklopit slovensko.sk

    • treba zvazit dopady redizajn na slovensko.sk a ine weby

  • navrhol som zvazit variant - ze len prefarbime gov.uk style guide & framework

  • je to hotove, overene, robia na tom stovky ludi denne

  • su k tomu podporne nastroje (hotove komponenty v html, atd)

  • licencia by nemala byt problem

  • suxa - rozne fazy redizajnu - vela sa da vyriesit aj opravenim textacie.

  • diskusia o textacii, ktora je vzdy boj medzi “chceme to poludscit” vs. legislativci

    • ked to nema jedneho pana, tak sa to rozsype
    • uradnik si kryje chrbat, napise to nepriestrelne

  • diskusia - co so specializovanymi portalmi

  • zatial panovala zhoda, ze cielom by malo byt rusit zbytocne sidla a centralizovat obsah

  • mv spominalo krajske urady, ktore kazde maju web a kazdy si to robi inak, treba ocakavat odpor pri ruseni

  • navrhol som zvazit gov.uk model - centralizovana publikacna platforma + decentralizovane aplikacie (na podania, etc) v gescii toho ktoreho OVM (za predpokladu jednotneho dizajn manualu)

  • diskusia o jednotlivych fazach agilneho projektu (v zmysle spatnej vazby od pouzivatelov)

  • brief (co sa ide robit a aky je aktualny stav) + research (co naozaj treba riesit)

  • dlha diskusia o tom, ci ideme riesit procesne zmeny alebo len orchestrovat existujuce podania, aby sa zlepsil komfort pouzivatela

    • primarny ciel je zvysenie komfortu pouzivatela, avsak optimalizacia procesov na strane uradnikov je tiez nutna

  • navrh za nas - ci neda sa na tuto uvodnu fazu (brief + research) pouzit OP EVS - mali by jasnu agendu co maju urobit a co ma byt vystupom.

  • rozvoj systemov - treba robit research aj pre rozvoj existujucich systemov. Priklad ITMS - bola predstava co treba robit, ale po user researchi sa zistilo, ze treba riesit nieco uplne ine.

  • musime riesit hlavne proces - nesklznut len do farbickovania (dizajn manualu), pointa je uplne inde.

  • navrh za nas - prebrat proces z gov.uk - maju zmaknutu metodiku / assessment reporty pre jednotlive fazy. Vybrat to dobre a aplikovat na nase realie (t.j. nie interny vyvoj).

  • v zavere bolo jasne, ze sa zhodneme, ze treba: dizajn manual, patterny a hlavne zmenit proces akym sa tvoria aplikacie (research, prototyp, testovanie s realnou cielovkou)

@michalblazej dufam doplni ak som nieco zabudol a prida nejake materiali za neho.

4 Likes
2

Do istej miery sa toto riesilo na fore u nas Vytvorenie dizajn manuálu

@ps-ux by mohlo dat nejake vstupy.

1 Like
3

Na diskusiu:

1 Like
4

podla mna jednoznacne treba prebrat tie UK veci.

tam je taky poklad, ze robit to nanovo po nasom je uplny waste of time a este to bude aj horsie.

8 Likes
5

Pomerne davno som riesil tento koncept pre slovensko.sk https://dribbble.com/shots/3077376-www-slovensko-sk-concept/attachments/648396 …chceli sme to postavit na drupal instalacii (podla australskeho vzoru)…zatial sme sa k tomu samozrejme poriadne nedostali…kazdopadne mam toho rozpracovaneho ovela viac co sa tyka designu a ux riesenia…avsak skor by som isiel do uz hotoveho riesenia co maju v UK…ak by ste potrebovali help rad pomozem…

4 Likes
6

Ja som uz niekolkokrat prechadzal tiez tie UK podklady a je to jednoducho dobre urobene. Na Slovensku neexistuje v sucastnosti ludska kapacita schopna vyprodukovat tak dobre (z hladiska accesibility, standardov alebo napr konzistencie) guide lines ako tie z UK v rozumnom casovom horizonte.

Navrhujem (1) fork, (2) zanalyzovanie a pridanie patternov specifickych pre statnu spravu (worflowy, widgety, sluzby, ktore najcastejsie su na slovensko.sk pouzivane — staci zistit statistiku toho, co bolo zatial urobene cez portal a vieme, ze realne mozno treba sa zamerat najprv na dve/tri subsekcie), (3) spisat rozumne okontrolovatelny bullet point list, ktory je flexibilny, ale donuti niekoho sa pod to podpisat a zaskrtnut ze to tam je (aspon z hladiska UX a asi vizualu).

4 Likes
7

Tiez som za prebratie, ale nielen dizajnu, ale aj inych veci, ako napr. spomenuteho service manualu. Maju to uz vyladene, urcite lepsie ako vymyslat vlastne.
Idealne by asi bolo tam menit co najmenej veci, aby sa potom dali prebrat aj vylepsenia co budu robit v UK.

1 Like
8

mam pocit ze som niekde videl tie US standardy uz v podobe live styleguide na patternlabe, co moze pomoct pri jednoduchsej implementacii, pripadne pri rychlom vytvoreni klikacieho prototypu pre konkretne pouzitie.

1 Like
9

Nedávno som si prechádzal tak Gov.uk, ako aj USA standards takže pridám svoje postrehy:

Gov.uk:

+ veľkosť všetkých elementov
+ dostatok whitespace-u
+ kontrastný pomer farieb
+ páči sa mi akú výraznú farbu nadobudnú elementy ktoré su focus-nuté
+ použitý font (New Transport - pozor, je platený)
+ prístupné aj pre čítačky vďaka WAI-ARIA atribútom
+ pripomienkovanie riešené verejne
+ frontend kit dostupný pre rôzne balíčkovacie systémy a platformy
+ je dosť mature, vyvíjajú už dlhšie

- paletu komponentov by som rozšíril o pokročilejšie formulárové prvky (napr. maskované inputy)
- chýbajú mi decentné mikro-interakcie, ktoré by dodali viac kontextu (napr. pre accordion)
- po dokumentácií pre frontend kit sa ťažšie pohybuje, preferoval by som vždy prístupné ľavé menu
- nikde som nenašiel PS / Sketch súbory pre dizajnérov ako to majú v USA standards

USA standards:

+ naozaj veľmi dobre členená a rozložená dokumentácia
+ využívajú voľne dostupné fonty
+ majú PS / Sketch súbory pre dizajnérov

+/- celé to pôsobí kompaktnejším dojmom, čo je ale aj nevýhoda pre rôzne hendikepované skupiny

- nevidím v zdrojákoch WAI-ARIA atribúty, ale údajne podliehajú WCAG
- nevyvíja sa až tak dlho, niektoré elementy sú stále unstable podľa maturity scale

Záver

Osobne by som asi fork-ol, ako už viacerí predo mnou písali, Gov.uk verziu, odstránil čo netreba, zmenil branding a možno dorobil jemné vylepšenia týkajúce sa prevažne formulárových prvkov, ako som už uvádzal. Čo sa však týka design manuálu, asi by som to urobil takým štýlom, ako ma USA standards.

EDIT:
Na akých platformách sú postavené naše štátne weby? Je to ako tak konzistentné? Niektoré komponentové frameworky môžu vyžadovať viac úsilia pri nahrádzaní prvkov. Ale to je samozrejme riešiteľný problém. Gov.uk, zdá sa preferuje Ruby.

PS: Ak som uviedol niečo nesprávne, prosím opravte ma, rád to upravím.

8 Likes
10

akožto jeden z autorov toho odporúčania, aby Slovensko prebralo britský dizajn manuál, s týmto tiež súhlasím :slight_smile:

konkrétne to bolo v záverečnej správe revízie výdavkov na IT, na strane 37: http://www.mfsr.sk/LoadDocument.aspx?categoryId=11154&documentId=14956

@jsuchal sem už dal všetky relevant linky, tak len, že teším sa z tejto iniciatívy a držím palce!

navrh za nas - ci neda sa na tuto uvodnu fazu (brief + research) pouzit OP EVS - mali by jasnu agendu co maju urobit a co ma byt vystupom.

asi by sa dalo, ale ak má byť výstup hotový do 31. mája, riešiť popri tom ešte aj OP EVS projekt… uf. aby ste do 31. mája nemali tak akurát schválený reformný zámer. alebo paralelne na tom robiť a potom to len prefinancovať?

11

Dovysvetlim, kedze moje minimalisticke poznamky ocividne nestacia.

Pri kazdom projekte (napriklad zivotne udalosti ale aj ine user-facing projekty) je potrebne spravit brief-popisat stav + research(user needs). Toto by sa mohlo riesit uz v ramci OP EVS. Cim by vseobecne analyzy dostali aj nejaky konkretny a hmatatelny obsah. Tu presne vieme co treba spravit a co ma byt vysledkom a ako sa bude pokracovat.

12

zaujimave…ked som sa na prvom zasadnuti pracovnej skupiny pytal, ci jednym z vystupov tejto pracovnej skupiny bude dizajn manual, tak bolo povedane, ze nie!!! :slight_smile:

toto sme dost debatili uz tak pred viac ako polrokom s @michalblazej…robili sme si taky guide ako vyvijat sw aplikacie, ako zapojit workshopy, wireframovanie, testovanie na koncovych pouzivateloch do celeho procesu projektu a postupne interovat k finalnemu stavu…myslim, ze vieme zalovit a vyshareovat k comu sme dospeli

osobne si myslim, ze OP EVS bude fail…je zaciatok roka 2017 a nemaju ani “tuk”…moj osobny tip je, ze sa stanu brzdou celeho procesu zlepsovania procesov VS…schvalovat nove projekty informatizacie bez navrhu a otestovani novych procesov/sluzieb nema vyznam, to som sa presvedcil sam…cize kym nebude toto zrealizovane, tak projekty informatizacie by mali byt zamerane len na infrastrukturne a technologicke zmeny…ale aj tieto zmeny nakoniec do velkej miery definuju/ovplyvnuju poziadavky koncovych pouzivatelov a zmeny procesov/sluzieb

na konci roku 2017 musi byt minutych za EU zdroj cca 93 mil. EUR v ramci informatizacie. Aktualne sa SR cerpanie pohybuje na urovni 52 mil. EUR. Ak sa do konca 2017 neminie tych zostavajucich 39 mil. EUR, tak SR o rozdiel medzi planom a realnym cerpanim pride a nema narok na jeho docerpanie

na MV SR verejne obstaravanie na tieto analyzy vyhrala spolocnost Deloitte…pochybujem, ze ta spolocnost bude mat tolko internych ludi, ktori to vedia spravit v takom rozsahu a v kratkom case…cize budu hladat vonku, co tiez bude stat cas a ti ludia teraz robia svoje veci a necakaju, kym ich niekto oslovi

→ cize na zaklade vyssie uvedeneho tipujem, ze to sklzne k rychlemu minaniu penazi na urok kvality

preto dizajn manual by mal niest aj prvky a postupy pre optimalizaciu procesov a zbieranie poziadaviek a testovanie na koncovych pouzivateloch tak, aby hociktory organ verejnej moci si vedel urcitu cast tychto veci poriesit sam, svojimi internymi kapacitami

az takto tvrdo by som to nedefinoval…neviem, kto to povedal…predstava co treba riesit bola a je podla mna vo velkej miere spravna, ale ovela skorsim testovanim, prototypovanim a pod. sa mohol usetrit cas, peniaze a hlavne dodat pouzivatelom skor sluzby/produkt s vyssou pridanou hodnotou

tu na platforme som zdielal priklady z vystupov z UX testovania na koncovych pouzivateloch…ak by niekoho zaujimalo, ze ako to vyzera a pod., tak potom tu

2 Likes
14

+1
Velmi dobry breakdown Marek
(od Amikov by som pozical aj fonty)

15

Ako na zavolanie https://gds.blog.gov.uk/2017/01/17/service-toolkit-everything-you-need-to-build-a-service-in-one-place/

4 Likes
16

Proces treba v case aktualizovat, ked sa zmenia niektore zavislosti. Aky system zvolit na identifikovanie, co treba refaktorovat? Ako to robia v UK?

To iste sa tyka textov.

17

Ahojte,

v SUXE sme to prebrali, presli si dokumenty a navrhujeme nasl. postup. Treba si byt vedomi, ze:

  • narozdiel od UK, nemame interny dizajnersky tim
  • navrhujeme postupne prekladat a optimalizovat UK dokumenty, ale chceme vychadzat z nich a nevymyslat nic nove, lebo nikto nema tak vela casu, aby sme spravili nieco lepsie ako existuje u nich.
  • skuste sa pozerat na situaciu tak, ze to dostane ATOS/HP/Anext na stol a musia sa pohnut. Preto navrhujeme zmensit objem pravidiel, ktore UK ma.

Tu je navrh:

Dizajn manuál

  • Kompontenty: preberieme a zlokalizujeme http://govuk-elements.herokuapp.com / https://designpatterns.hackpad.com/Design-patterns-0eUk1OdHvql
  • Patterny: preberieme a lokalizujeme https://www.gov.uk/service-manual/design, musime este doplnit nasl.:
  • indikáciu progresu v procese – Jednotná navigačná schéma – ako majú vyzerať procesné flows
  • navigácia – menu, multikontext, crumbs menu
  • úvodné stránky – Každý web by mal obsahovať USP – vetu, ktorá projekt uvádza
  • vyhľadávanie
  • dashbordy
  • FAQ
  • Slovnik: priprava spolocneho slovniku pre egov a manual pre copy. – musi byt vytvoreny nanovo.
  • Otazka na diskusiu: ako velmi tlacit proces alebo vyuzit len akceptacne kriteria
    1. moznost: tlacit vyrazne User-centered design proces, t.j.:
    • Research
      Toto bude robit asi UPVII v ramci studie uskutocnitelnosti. Vystupom researchu je strategia, ktora koriguje existujuce user procesy.
    • Informacna architektura
      Priprava navigacie, user flows a slovnik.
    • Iterativny prototyping
      Priprava a vypublikovanie prototypu na zaklade patternov a slovniku. Niekolko iteracii
    • Viacnasobny testing v kazdej iteracii
      Testovanie pouzitelnosti prototypu, optimalizacia prototypu, uprava.
    • HTML
      Na zaklade komponentov (herokuapp).
      1. moznost: spravia si ako chcu, ale budeme mat akceptacne kriteria, napr.:
    • usability testing (vacsi) s definiciami cielov na priechod kriteriom: chybovost, time on task, efektivita, SUS …
  • Dodržiavať odporúčania WCAG 2.0 a výnos MF SR 55/2014 o štandardoch pre informačné systémy verejnej správy.
  • Urovne implementacie pri starsich projektoch:
    • uroven 1: len branding (komponenty)
    • uroven 2: len patterny
    • uroven 3: aj proces
  • Uroven implementacie pri novych projektoch: vsetko
3 Likes
18

Ja by som este navrhol, aby sa niekto pozrel na sulad UK designu s vynosom MFSR 55/2014. Predpokladam, ze tam bud nesulad, lebo ten vynos je dost stary.
Z toho vyplyva ze treba mysliet aj na aktualizaciu tohto vynosu (podla mna je long overdue).

1 Like
19

Cauko, toto sme riesili, mas nieco konkretne? Lebo vynos bol priebezne aktualizovany a specialne kolegovia z UPVII ho su ochotni aktualizovat ak v nom je nieco nevyhovujuce, len ja som nevedel na nic poukazat.

20

Konkretne priklady:

  • Mali sme napriklad problem, ze bootstrap nie je kompatibilny s textom Pri uvádzaní hodnôt atribútov v značkovacom jazyku alebo vo vlastnostiach štýlov sa namiesto absolútnych jednotiek používajú relatívne jednotky. Veľkosť textu možno zväčšovať a zmenšovať prostredníctvom štandardných funkcií prehliadača.
    Bootstrap (aspon v tedy pouzitej verzii) pouziva absolutne hodnoty, ale samozrejme prehliadace si s tym vedia poradit.

  • Je dnes relevantne mat taketo usmernenie? V praxi to asi znamena mat alternativnu stranku bez Javascriptu. "Aktívne prvky, ktorými sú skripty, aplety a iné programové objekty sa poskytujú prístupne alebo sa zabezpečuje, aby boli webové stránky použiteľné, aj keď sú aktívne prvky, vypnuté alebo nie sú podporované. Ak to nie je možné, poskytujú sa ekvivalentné informácie na alternatívnej prístupnej webovej stránke."

Toto asi uz nie je moc relevantne:

  • Zverejnenie verejného kľúča pre šifrovanú poštu
  • Zverejnenie kontaktu na overenie verejného kľúča

Samozrejme tam treba vyriesit este dalsie detaily, ako napriklad ze na kazdej stranke musia byt kontakty mimo menu, otvaracie hodiny (aj ked pre web to je mozno 24x7:)

21

https://designnotes.blog.gov.uk/2017/02/02/building-an-international-group-of-government-designers/ @michalblazej @stefan.szilva tuto sa treba prihlasit.