Beyer H: User Centered Agile Method Synthesis lectures on human-centered informatics: Chapter 3 and 4 Flashcards
Nævn de principper bag agile method
- There is only one team
- The user is on the team
- Plans and architectural work are a waste of time
- Face to face communication is better than documentation
- Short sprints are good. Shorter sprints are better
- Continual feedback guides the projekt.
- How these values go wrong in practice.
Nævn hvad: “There is Only one team” handler om samtidig med dens UX leverage point
At man er et hold hvor man har developers og UX. Developers og UX skal kende og finde ud af hinandnes arbejde for at hjælpe hinanden.
UX leverage point er: Lærer resten af holdet om simple UI koncepter, hvor hvis det er nødvendigt, gruppen kan arbejde med de simple UI og UX med de komplekse.
Nævn hvad: “The User is on the team” handler om samtidig med dens UX leverage point:
At man skal prøve at have den rigtig user med i ens projekt for evt. feedback, hvilket er ikke helt muligt. Derfor ofte baserer sig på de andre user, som stakeholders, hvilket er ikke helt den optimale løsning.
UX leverage point: UX er i stand til at kommunikerer med de rigtige users ved brug af deres tekniske viden, hvor de kan bl.a. kom med vigtige informationer med til developers, uden at useren er implicit med i holdet.
Nævn hvad “Plans and architectural work are a waste of time” handler om samtidig med dens UX leverage point:
Den tager udgangspunkt i at man bruger lang tid på design af arbejdet og derefter lave implementeringer der skal sendes til gruppen, idet man mener at users skifter drastisk deres ønsker (ikke rigtigt, kun miscommunication). Meningen er bare at komme med små koncepter som skal sendes direkte til useren som kan analyser.
UX leverage point handler om at det overstående er umuligt, idet man laver nogle implementeringer ud fra ingenting, derfor UX skal tages sig af i phase 0 i at får de nødvendig informationer for at implementeringer
Nævn hvad “Face to face communication is better than documentation” handler om og dens UX leverage point
At developers og users skal snakke sammen i forhold til ønskerne for slutproduktet, men dette er svært da useren kan ikke være på teamet og se hvordan developers arbejder
UX leverage point er at du har en UX som tager de implementeringer og designs fra developers og tester sammen med userne.
Nævn hvad “Short sprint are good. Shorter sprints are better” handler om, samtidig med UX leverage point.
At developers skal være i stand til at inddeler deres arbejde i korte sprints, hvor et bestemt par funktioner skal implementeres pr. sprint. I starten har man mere struktur og skeletet og mindre funktionalitet, men udvilker sig pr. sprint. Hvis ingen tid til implementering af et funktionalitet, laves på et andet tidspunkt (technical dept).
Technical dept og arhitectual dept skal løses på et tidspunkt.
The UX leverage point: At man har UX som designer UI pr. sprint, UI som bruges i development. Hvis UI designet er ikke færdigt, design debt er til stedet. For at have mindre design debt er UX nød til at have styr på den overfladiske koncept bag forholdet og interaktionen mellem UI.
Nævn hvad “Continual feedback guides the project” sammen med UX leverage point
Korte feedback for at have et bedre sammenhæng mellem implementeringer og feedback, sammen med at have god forbindelse med useren. Problemet er bare at man kan ikke have en user som er altid med developers, men det er umuligt. Et andet løsning er at kort forklare intentionerne ved implementationen til evt. stakeholders, men man vil få ikke meget tilbage.
UX leverage point: I stedet for at have konstant kontakt, UX designer diverse prototyper der kan nemt fremvises, testes og forstås af useren, såsom at feedbacket er mest konkret og detaljeret.
Nævn hvad “How these values go wrong in practice” handler om samtidig med UX leverage point
Selve ideen er at man kommer til ikke at have en overordnet forståelse af selve problemets løsning fra starten af, hvilket kan give problemer i at komme frem til radikale løsninger fra sprint til sprint, hvor kodeimplementeringen vil ændre sig drastisk, hvilken vil fører til mange bugs, fejl, meget tid til et upræcist produkt. Et andet problem som man tit gør er at man improviserer i forhold til user feedback, idet man antager hvad useren ønsker og designer ud fra dette.
Vis de 5 udfordringer i at få user feedback og integrer dem i systemet
- Users kan ikke finde ud af at forklare hvad de vil
- Users want to be helpful
- Users are not available as team members
- Marketing methods do not collect design data
- Online data collection is incomplete
Hvad handler user udfordringen: “Users kan ikke finde ud af at forklare hvad de vil”?
Det gælder fordi de har lavet dette arbejd e for lang tid og har internaliseret de forskellige koncepter (tacit viden). Det gør det bare instinktivt, derfor har de det svært at formulerer deres arbejde.
Hvad handler user udfordringen: “Users want to be helpful” ?
Problemet med det er at de raporterer de fejl de observerer ved deres system, men ikke helt konteksten fejlet sker hen og hvad de vil gerne have helt konkret der skal løses i forhold til fejlet
Hvad handler user udfordringen: “Users are not available as team members”?
Det betyder at brugerne har deres egen arbejde, derfor kan det ikke muligt at inddrage dem i vores projekt hele tiden.
Et andet problem er at selvom at man finder et surrogate, så vil han få de kriterier der skal løses fra stakeholders og organization owneren, hvilket er ikke nok konkret til at finde valid løsninger
At tage et medarbejder, betale dens arbejdstimer for at være med i projektet, er ikke nok, idet medarbejderen vil blive påvirket af environmentet og ikke komme frem til helt kritiske feedback.
Hvad handler user udfordringen “Marketing methods do not collect design data”
og “Online data collection is incomplete”?
Du kan ikke bare spørg mennesker om hvad de ønsker via questionairs, da de kan ikke forklare alt de mangler. Man har ikke muligheden for at observerer deres arbejdsprocess
Hvad er BPUF?
Big picture up front tager udgangspunkt i at have et overordnet forståelse af projektets problemstilling og et eventuelt løsning på dette.
Hvordan hjælper phase 0 i ens kodeproduktion?
Man kommer til at have et overordnet struktur af processen, derfor vil man reelt ændre kun cirka 20% af projektet fra de næste sprints af.
