Artefakter
Vi fik skabt de indledende artefakter i gruppen og indlægget her er efterfølgende blevet opdateret så det inkludere artefakter fra start til slut.
Opdateret 23.11.2024
User stories & Use cases
Efter de første møder med vores PO og en masse rigtig god materiale fra hende, som hun bruger i dag og som vi skal lave et system ud fra, var vi nu klar til at skabe vores indledende artefakter. Det var heldigvis arbejde som vi efterhånden har prøvet mange gange og det tog ikke lang tid før vi havde en fornuftig og fælles forståelse af hvad vores applikation skulle kunne og i grove træk se ud.
Vi startede med Use Cases og User Stories hvor et par eksempler derpå kan ses herunder:
Domænemodel og DCD
Herefter gik vi videre til at lave vores domænemodel, så vores DCD og til sidst vores Wireframes. Vi endte med flere udkast på en domænemodel og endte faktisk aldrig med at blive helt præcist enige om hvordan den skulle se ud. Eftersom jeg selv skulle stå for frontenden og “blot” skulle kalde nogle API endpoints har det ikke været noget jeg personligt er gået tilbage og kigget på. Det har endnu ikke vist sig at være et problem for mig – og jeg kan på nuværende tidspunkt heller ikke se hvordan det skal blive det. Når det så er sagt, kunne det være rart at vi havde en fælles enig forståelse af opsætningen af systemet.
Se et par forslag til vores artefakter herunder:
Wireframes
Wireframes har vi også lavet på tidligere semestre, men denne gang var det nødvendigt at dykke lidt dybere ned i emnet. Her har jeg brugt Springboard, bogen Designing User Experience og gruppen til at diskutere materiale og fund. Og som nævnt tidligere virker det til at være stor uenighed om, hvornår det hedder et wireframe og hvornår det ikke gør. For eksempel siger Springboard følgende:
Source: springboard.com
What Does a Wireframe Include?
The primary goal of a wireframe is to visually represent the layout of the screen. So, a wireframe would show the arrangement of content, interface elements, navigation, etc. A typical wireframe includes:
- Page layout. Arrangement of visual elements in relation to one another
- Functions of the site. Video, images, links, etc. (The functionality itself is not yet designed/developed. It’s simply assigned a place on the wireframe)
- Relative importance of features. For instance, how big is the banner as compared to the subscription form or the announcements section
- User journey. What happens when a user clicks on something or fills a form
What Does a Wireframe Not Include?
In the website or apps, user interface designers also use mockups, prototypes, high/low-fidelity designs, etc. A wireframe is none of that. So, it does not contain:
- Visual design. Fonts, colors, images, branding elements, etc.
- Interactions. Drop-downs, clickthroughs, hover animation, etc.
- Content. Designers may sometimes use placeholder text to show how much text can be accommodated, but it’s never the final copy
Hvorimod bogen giver flere eksempler som følgende:
Men fordi det materiale vi havde modtaget fra PO samt de samtaler vi allerede havde haft med hende gik vi direkte til at lave hi-fi wireframes. Set i bakspejlet var det nok ikke den helt rigtige løsning, og efter jeg selv er blevet klogere på SwiftUI og Apples designprincipper ville jeg have kommet med endnu flere forslag til layoutet. For eksempel ville jeg nu havde forslået en “tab bar” for, både at minimere antal tryk nødvendigt, mindre behov for at læse tekst, navigation tættere på tommelfingeren som er primær indtastningsfinger ved brug af en hånd samt hurtig visuel forståelse og overblik over app’ens funktioner.
Her er nogle af vores tidlige og senere wireframes inklusiv user flows:
