UX - Case Moodle del 2


Opgaven

Flere studerende på Cphbusiness giver udtryk for, at de ikke er tilfredse ned at bruge Moodle. Det er dog uklart, hvad der reelt er problemet. Det skal I som UX’ere finde ud af!

I skal undersøge, hvordan brugerne anvender Moodle og hvad deres problemer i forhold til systemet er.

Nedenfor vil de anvendte metoder blive beskrevet

Som studerende på CPH business og selv bruger af platformen Moodle, er det essentielt at vi, i vores arbejde, laver objektiv og neutralt research.


Opgaven er delt op i 3 dele. Dette er 2. del

Problemstilling

De studerende på CPHBusiness bruger Moodle dagligt og har til skolen og lærerne givet udtryk for at Moodle ikke virker tilfredsstillende.

For at kunne løse dette problem har vi brug for at de studerende sætter ord på og viser hvilke funktioner der er utilfredsstillende men også hvad der rent faktisk virker optimalt.

Til 2. del af Moodle opgaven skal vi undersøge:
User Cases
Prioritering
HMW Spørgsmål
Moodle Features
Dokumentation / Leverancer

Opgavens opbygning

Her i del 2 af Moodle opgaven skal vi arbejde videre med vores brugers problemer, med udgangspunkt i vores personaer.

Dette gøres ved at finde indsigter og Identify muligheder:

Brugers problemstillinger POV (use stories)
Prioritering
Identify/brainstorme de rigtige design spørgsmål - How Might We (HMW)


Til sidst i denne opgave skal ovenstående resulter vises i en wireframe hvor løsningerne vises, dette gøres med:

Story points
Leverancer
Figma prototype

User cases

User cases er vigtige fordi:

Bringer brugerne tættere på: Teamet forbinde direkte med brugerne, forstår deres perspektiv, problemer, muligheder og andre ting, der skal tages fat på.

Bruges som byggeklodser for projektet: Letter tilføjelse eller fjernelse af funktioner (features) fra produktet.

Øger gennemsigtigheden: Lettere forståelse, samarbejde og hurtig beslutningstagning i teamet.

Muliggøre samarbejde: Med en klar forståelse af problemstilling, så kan teams arbejde sammen om at levere kreative og innovative løsninger til kundens behov

User cases - Prioriteringsteknikker

Ranking - Ranger alle funktioner i rækkefølge efter vigtighed

Gruppering - Gruppering af funktioner i rangerede kategorier.

Top ti - Hver stakeholder vælger deres top ti funktioner ud af alle mulige funktioner.

100-dollar test - Hver stakeholder har 100 dollars for at købe funktioner. De kan betale så meget de vil for enhver funktion.

Prioriteringsmatrix - Prioriteringsmatricen er et værktøj, der giver dig mulighed for at sammenligne og vælge prioriteterne for at tage en beslutning mellem bestemte problemer eller løsninger.

HMW - spørgsmål

Vi som UX´ER skal kunne definer og frame designudfordring ud fra et synspunkt og komme med med forskellige løsninger ved at spørge:

How Might We (HMW) - Identify/brainstorme de rigtige design spørgsmål

HVORDAN SKRIVER MAN GODE “HMW” spørgsmål?

#1 Start med de problemer (eller indsigter), du har afdækket

#2 Undgå at foreslå en løsning i dit HMW-spørgsmål

#3 Hold dine HMW'er brede

#4 Fokuser dine HMW'er på det ønskede resultat

#5 Formuler dine HMW-spørgsmål positivt

HMW - spørgsmål - Gruppering


Step 1: Vi så på de enkelte dele af vores indsigter/User Cases, og kom op med spørgsmål ved at bruge HMW. Disse HMW-spørgsmål grupperede vi i emner:

”tjekke kalender”

”Vejen til undervisningsmateriale”

”Kontakte medstuderende”

”Kontakte læreren”

”Danne overblik over opgaver/lektier”

”Opgave aflevering”

HMW - spørgsmål - Nyttige klynger


Step 2: Så sorterede vi og grupperede vores HMW svar i nyttige klynger;

SYSTEM SETTINGS

Hvad kan løses i systemet bag Moodle.

OPSÆTNING OG DESIGN

Hvad kan vi ændre i selve brugerfladen.

COSTUMIZE

Hvad kan brugeren selv være med til at ændre.

Moodle Features

Ud fra Moodle egne features havde vi nu til opgave og se hvilke features der allerede eksisterede og som kunne anvendes i vores HMW spørgsmål.

Listen er rigtig lang og det kræver en vist indsigt at kunne vælge ud. Derfor vil det i fremtidige cases kræve at man har en tæt dialog med både frontend og backend for at kunne sikre sig de bedste løsninger inden for de givne rammer.

Vi bruger Moodles Features som referencesystemet for vores design

Story Points

For at kunne udvikle features til vores case har vi anvendt metoden ”Story point” . Dette går ud på at give vores case nogle økonomiske begrænsninger.
I vores tilfælde har vi fået tildelt 16 story point. Disse point skulle fordeles ud på vores ønskede features.

HVAD ER ET STORY POINT?

Story Point er en enhed til at måle størrelsen på en User Case eller en feature.
Et Story Point tildeltes til en feature der løser en User Case. Hvis man giver en feature 2 Story Point, så betyder det, at det tager den dobbelte indsats i forhold til en feature som koster 1 Story Point.
Et Story Point kan tildeles baseret: indsats som det tager at løse en opgave, kompleksiteten og den risiko der er ved at udvikle en ny feature.

I denne case har vi fået stillet 16 story point til rådighed som skal fordeles ud på de features vi udvælger

Leverancer

XXXXXX

Figma

XXXXXX

Gruppens løsningsforslag

XXXXXX