Skaidrs mērķis
Pirms ekrāniem vienojamies par vajadzību, prioritāti un sagaidāmo rezultātu.
No vajadzības līdz produkcijai
Dizains paliek iesaistīts līdz produkcijai.
Sākam ar biznesa vajadzību, izstrādājam UX/UI, strādājam kopā ar izstrādes komandu un pārbaudām ieviešanu pirms tās nonāk produkcijā.
Ko nodrošina vienots process
Mazāk neskaidrību no lēmuma līdz ieviešanai.
Katrā posmā samazinām citu risku - neskaidru mērķi, nepilnīgus scenārijus, pārpratumus izstrādē vai neatbilstības gatavajā produktā.
Pilni scenāriji
Definējam plūsmas, stāvokļus, izņēmumus un responsīvo uzvedību.
Atbalsts ieviešanā
Atbildam uz jautājumiem un precizējam risinājumu reālās izstrādes laikā.
Pārbaudīta realizācija
Pārbaudām ieviešanu pirms publicēšanas un pēc nonākšanas produkcijā.
Process soli pa solim
Astoņi posmi no vajadzības līdz produkcijai.
Ne katram uzdevumam vajadzīgi visi astoņi posmi vienādā dziļumā. Procesu pielāgojam reālajam kontekstam - vienkāršam uzlabojumam nav vajadzīgas astoņas sapulces.
01 Saprotam
Vajadzība
Ko risinām, kam un kāpēc.
UX un plūsma
Scenāriji, loģika, stāvokļi un izņēmumi.
02 Projektējam
Saskarnes dizains
Vizuālais risinājums un visi būtiskie ekrānu stāvokļi.
Dizaina sistēma
Esošie komponenti, jauni papildinājumi un sistēmas noteikumi.
03 Ieviešam
Nodošana izstrādei
Skaidrs risinājums, specifikācija un paredzētā uzvedība.
Ieviešanas atbalsts
Atbildes, precizējumi un korekcijas izstrādes laikā.
04 Pārbaudām
Kvalitātes pārbaude
Pārbaudām realizāciju, scenārijus un vizuālās neatbilstības.
Produkcija
Pārbaudīts risinājums kļūst par produkta daļu.
Ko izlemjam katrā fāzē
Katrai fāzei ir skaidrs uzdevums un rezultāts.
No vajadzības definēšanas līdz pārbaudītai ieviešanai - katras fāzes rezultāts kļūst par pamatu nākamajai.
Vajadzība, konteksts un UX
Definējam problēmu, lietotājus, biznesa mērķi, tehniskos ierobežojumus un galvenās plūsmas. Sarežģītiem uzdevumiem izstrādājam struktūru un alternatīvus scenārijus.
- Mērķis un rezultāta kritēriji
- Informācijas arhitektūra
- Plūsmas un izņēmumu scenāriji
Saskarnes dizains un sistēma
Veidojam saskarni pilniem scenārijiem, ne tikai ideālajam stāvoklim. Pārbaudām responsīvo uzvedību un to, kā risinājums iekļaujas esošajā sistēmā.
- Datora un mobilā versija
- Ielādes, tukšie un kļūdu stāvokļi
- Komponenti un varianti
Nodošana un ieviešanas atbalsts
Nododam izstrādei loģisku un sakārtotu risinājumu. Paliekam pieejami jautājumiem un tehniskos kompromisus pieņemam kopā ar izstrādes komandu.
- Sakārtots Figma fails
- Uzvedība un specifikācijas
- Ātras atbildes ieviešanas laikā
Kvalitātes pārbaude un sistēmas atjaunināšana
Salīdzinām realizāciju ar iecerēto un pārbaudām galvenos izmērus, scenārijus un stāvokļus. Pēc ieviešanas atjauninām sistēmu, lai nākamais darbs sāktos no labāka pamata.
- Vizuālā atbilstība
- Responsīvā uzvedība un stāvokļi
- Komponentu konsolidācija
Ko saņem izstrāde
Risinājumu, kas jau ir sagatavots ieviešanai.
Strādājam dizaina sistēmā, kas izveidota un saskaņota ar izstrādes komandu - ar savstarpēji atbilstošiem komponentiem, tokeniem un uzvedības principiem. Tāpēc katrs nākamais risinājums jau top ar ieviešanu un handoff prātā.
Par dizaina sistēmām ↗
Automatizācijas iespējas
Dizaina izmaiņas var automātiski nonākt izstrādes sistēmā.
Figma izmaiņas var nodot Jira, GitLab vai citai komandas darba videi - variables un komponentu atjauninājumus, diff, saites uz konkrētiem freimiem un “Ready for dev” statusus. Integrācija var papildināt esošu uzdevumu vai izveidot jaunu. Apjomu pielāgojam komandas rīkiem un pieejamajiem API, lai izmaiņas būtu izsekojamas un nepazustu komunikācijā.
Praktiski komandai
Ko tas maina ikdienas darbā.
Mazāk interpretācijas, pārstrādes un nevajadzīgas koordinēšanas - bez izmaiņām izstrādātāju ierastajā darba ritmā.
Vai tas maina izstrādātāju ikdienu?
Nē. Izstrādātājiem nav jāiesaistās dizaina procesā vai jāapgūst jauns darba process. Viņi turpina strādāt savos ierastajos rīkos un saņem dizainu, kas jau izmanto produkta esošo loģiku - mainīgos (variables), atstarpju sistēmu, krāsas, komponentus un izkārtojuma principus.
Kur rodas laika ietaupījums?
Mazāk laika aiziet dizaina interpretēšanai, precizējošiem jautājumiem un risinājumu pārtaisīšanai. Izstrādātājam ir skaidrs, kurš komponents jāizmanto, kā tam jāuzvedas un kas konkrēti ir mainījies.
Kā samazinām kļūdas un pārstrādi?
Pirms dizaina nodošanas izstrādei definējam būtiskos stāvokļus, pielāgošanos dažādiem ekrāniem, izņēmuma situācijas un komponentu variantus. Izstrādātājam nav jāizdomā trūkstošās detaļas brīdī, kad funkcija jau tiek būvēta.
Ko pārbaudām dizaina kvalitātes pārbaudes laikā?
Salīdzinām gatavo produktu ar dizaina bibliotēku, komponentiem un sistēmas loģiku. Nemeklējam viena pikseļa nobīdes - nosakām, vai neatbilstība jālabo realizācijā vai jāatspoguļo pašā dizaina sistēmā.
Kā nepieļaujam, ka dizains un produkts ar laiku sāk atšķirties?
Izmaiņas, kas rodas ieviešanas laikā, atgriežam dizaina sistēmā - atjauninām komponentus, mainīgos (variables) un noteikumus. Nākamais uzdevums sākas no aktuāla, nevis novecojuša pamata.
Vai jāmaina esošās tehnoloģijas vai darba rīki?
Nē. Dizaina sistēmu un nodošanas procesu pielāgojam esošajai lietotāja saskarnes izstrādei (frontend), komponentu bibliotēkai un komandas darba videi. Mērķis ir samazināt berzi esošajā procesā, nevis ieviest vēl vienu procesu.
Nākamais solis
Parunāsim par jūsu produktu.
Nav vajadzīga ne specifikācija, ne detalizēts apraksts. Parādiet produktu un pastāstiet, ko vēlaties tajā vai komandas darba ritmā mainīt, vai kur šobrīd rodas lieks darbs un sarežģījumi. Īsā sarunā sapratīsim, vai un kur varam būt noderīgi.
Parunāt par produktu ↗