This is a presentation from UX Riga 2014 user experience design conference. A case study is about the process and results of E-Services UX Methodology development for Lithuanian public sector.
12. What happens then…
Far away
Abstract
requirements
(law),
general
discussions
Functional
requirements
Actions
Close
???
Completion of
specific
actions
to reach
a planned result
“This is not what
we meant”
Bad
UX
14. Need to
1. Make people communicate their ideas early
2. Realize the difference between yourself and the user
3. Get the users involved
4. Build a common vision
5. Translate common vision into specific actions when you are
far away from the deadline
18. Common Principles
1. User needs in the center
2. Regular user research and involvement
3. Design and development based on user resarch
findings
4. Regular measurement of user experience
20. Process in more detail
Define the
„good“
Implement the
„good“
Support the
„good“
Modernize
Idea
Design
Implement
Support
Liquidate
21. Tools
Stakeholder list
Customer journey
Target group description
Service blueprint
Persona description
Business process diagrams
Survey
Wireframes
User observation
Sitemap
User interview
Interactive UI prototype
Diary study
Card sorting
Focus group
A/B testing
Usability evaluation
User interface guidelines
Usability testing
22. Idea
Modernize
Idea
Design
Implement
Support
Identify user needs, generate and explore e-service
ideas, which match those needs.
Stakeholder list
Target group
description
Survey
User observation
User interview or
diary study
Persona description
Customer journey
Liquidate
29. Document pack
UX Methodology (Process+Tools)
Tool Use
Examples
Procurement
Guidelines
Training materials
Available at: http://epaslaugos.ideacode.lt/
Usability Problem
Solution Guide
Functional requirements are written form a very abstract understanding.
Functional requirements are written form a very abstract understanding.
Žmogiškieji ištekliai – naudotojų pasitenkinimas paslauga ir e. paslaugos naudojimo sklaida. Pavyzdžiai: e. paslaugos naudotojai gerai ir labai gerai vertinantys e. paslaugos tinkamumą (tyrimui naudojama apklausa);skundų dėl e. paslaugos kokybės kiekis (fiksuoja paslaugos teikėjas pagal galiojančias tvarkas).Infrastruktūra – vertinamas informacinės sistemos (ir kitų infrastruktūros elementų, jei tokie yra) tinkamumas, greitis ir patikimumas, naudotojams atliekant esminius naudojimo scenarijus. Pavyzdžiai: kaip greitai naudotojas atlieka dažniausius e. paslaugos gavimui reikalingus veiksmus (tyrimui naudojamas tinkamumo testavimas )kiek naudotojų sėkmingai atlieka dažniausius e. paslaugos gavimui reikalingus veiksmus iš pirmo bandymo (tyrimui naudojamas tinkamumo testavimas )Komunikacija – vertinamas informacijos, naudojamos e. paslaugos teikime bei sukuriamos e. paslaugos teikimo metu, aiškumas, suprantamumas jos naudotojams. Taip pat gali būti vertinamas informacijos apsikeitimo greitis ir patikimumas e. paslaugos teikimo metu. Pavyzdžiai: kiek naudotojų sėkmingai suranda esminę informaciją apie e. paslaugos veikimą iš pirmo bandymo (tyrimui naudojamas tinkamumo testavimas )skundų išnagrinėjimo vidutinis greitis (fiksuoja paslaugos teikėjas pagal galiojančias tvarkas)Procesai – vertinama kaip efektyviai organizuotos ir atliekamos su e. paslaugos teikimu susijusių veiksmų sekos. Pavyzdžiai: kiek naudotojų aiškiai suvokia visą e. paslaugos veikimo eigą ir eiliškumą (tyrimui naudojama apklausa ir interviu su naudotojais)kiek organizacijoje trunka e. paslaugos suteikimas vienam naudotojui (fiksuoja paslaugos teikėjas pagal galiojančias tvarkas)