I P5 arbejdede vi ud fra Design Thinking som overordnet procesmodel. Modellen passede godt til projektet, fordi vi både skulle forstå en målgruppe, udvikle en digital løsning og løbende teste vores valg. Processen var ikke helt lineær, da vi flere gange gik tilbage og justerede løsningen ud fra feedback og nye indsigter.

1. Discovery – opstart og research

I starten af projektet skabte vi overblik over casen, gruppens arbejdsform og de første opgaver. Vi opbyggede et SCRUM-board, fordelte roller og lavede en produkt backlog, så vi havde en fælles struktur for arbejdet. Jeg havde rollen som SCRUM Master og kvalitetsansvarlig, hvor jeg blandt andet holdt overblik over boardet, fordelte opgaver og fulgte op på fremdriften.

Vi arbejdede med desk research, risikoanalyse, interessentanalyse, KWHL, spørgeskema og interview med Benedikte Brechmann. Formålet var at forstå både virksomheden, målgruppen og den kontekst, løsningen skulle indgå i.

Min egen rolle i denne fase var især at indsamle og bearbejde data. Jeg lavede tre interviews og arbejdede med affinity diagramming, hvor interviewdata blev opdelt i temaer som overblik, tryghed, rådgivning, tillid og forholdet mellem digital og personlig kontakt. Jeg lavede ikke selve spørgeskemaet, men sendte det ud i både danske og islandske Facebook-grupper for at få en bredere målgruppe af personer bosat i Danmark.

2. Interpretation – fra data til problemforståelse

Efter researchfasen samlede vi vores indsigter og begyndte at se tydelige mønstre. Det blev især klart, at boligkøb ofte opleves som en kompleks proces, hvor information er spredt på tværs af mails, banker, ejendomsmæglere og dokumenter.

Researchen viste også, at målgruppen ikke nødvendigvis ønskede en fuldt digital løsning. De havde stadig behov for personlig rådgivning, tillid og menneskelig kontakt. Derfor blev vores retning ikke at erstatte rådgiveren, men at skabe en digital platform, der kunne støtte brugeren med struktur, overblik og tryghed gennem boligkøbsprocessen.

I denne fase arbejdede jeg videre med at omsætte indsigterne til problemformulering og user stories. User stories hjalp os med at gøre brugernes behov mere konkrete og koble dem til funktioner i løsningen.

3. Ideation – idéudvikling og konceptretning

Efter research og problemforståelse arbejdede vi med idéudvikling. Vi brugte Crazy 8’s til hurtigt at få mange idéer frem og prioriterede derefter idéerne efter relevans for appen og SoMe-delen.

De stærkeste idéer handlede blandt andet om dokumentoverblik, kalender/bookning, Q&A, favorithuse, anmeldelser og mulighed for at flere brugere kunne have adgang til samme boligkøbsproces.

Jeg og Jamie lavede også et moodboard og arbejdede med style tile for at undersøge, hvordan det visuelle udtryk kunne hænge sammen med Benedikte Brechmanns eksisterende hjemmeside. Her havde jeg især fokus på whitespace, ro og et professionelt udtryk, så løsningen ikke virkede for tung eller uoverskuelig.

4. Experimentation – wireframes, test og iteration

Vi startede med low-fi wireframes, før vi gik videre til high-fi. Det gjorde det muligt at teste struktur, funktioner og brugerflow tidligt uden at låse os fast på det visuelle udtryk.

Der blev brugertestet i flere faser, blandt andet med think aloud, og der blev også arbejdet med A/B test og open card sorting i forbindelse med prototype-feedback. Feedbacken blev brugt til at justere wireframes, mockup og navigation, så løsningen blev udviklet ud fra brugernes reaktioner og ikke kun vores egne antagelser.

Samtidig arbejdede gruppen videre med personaer, konkurrentanalyse, SoMe-content, mockup og andre dele af konceptudviklingen. Vi var gode til at fordele opgaverne mellem os, så app-delen, researchdelen og kommunikationsdelen kunne udvikles parallelt.

Jeg havde tidligere arbejdet med dataindsamling, interviews og affinity diagramming, men i denne fase fik jeg afsluttet det sidste interview og kunne derfor færdiggøre analysearbejdet. Det betød, at jeg kunne samle indsigterne og bruge dem som grundlag for den endelige problemformulering og de user stories, jeg udviklede. På den måde blev brugernes behov omsat til mere konkrete funktioner og brugerrejser i løsningen.

5. Evolution – kode, pitch og aflevering

I den sidste del af processen blev projektet mere produktionsorienteret. Vi arbejdede med midvejspitch, high-fi prototype, klientrapport, procesvideo og kodning af den digitale løsning.

Kodningen gjorde projektet mere krævende, fordi vi skulle omsætte design og prototype til HTML, CSS og JavaScript. Jeg arbejdede især med min egen del af koden og nåede omkring 95% i Sprint 3. Det viste mig, hvor vigtigt det er at have en klar struktur, når design, dokumentation og kode udvikles samtidig.

I denne fase arbejdede vi meget individuelt med hver vores kode. Det var vigtigt, at de forskellige dele af løsningen kunne hænge sammen, selvom vi arbejdede på forskellige områder.

I Sprint 4 opstod der en situation, hvor en i gruppen havde haft en svær uge og derfor var kommet bagud med sin del af koden. Det skabte mere stress, men fordi vi havde haft godt styr på opgaverne, væltede det ikke projektet. Som gruppe mødte vi situationen med både forståelse og tydelig forventningsafstemning. Personen tog ansvar og kom stærkt tilbage i processen.

Den sidste uge handlede primært om finpudsning og klargøring til aflevering. Vi gik projektets dele igennem, rettede små detaljer og samlede den kodede løsning, design systemet, klientrapporten, procesvideoen og procesportfolioet. Vi gennemgik blandt andet responsivitet, footer, media queries og HTML-struktur, så de kodede dele fungerede bedre sammen.

For mig handlede afslutningen især om at bevare overblikket og sikre, at min egen del var færdig og kunne indgå i det samlede projekt.

Refleksion

Overordnet er jeg meget tilfreds med min egen indsats i projektet og med gruppedynamikken generelt. Projektet var stort, intensivt og vigtigt, og derfor er det også naturligt, at der opstår små udfordringer, når fire forskellige personer skal arbejde tæt sammen over længere tid. Jeg oplevede dog ikke, at de udfordringer skabte alvorlige kommunikationsproblemer eller påvirkede stemningen i gruppen negativt.

Tværtimod oplevede jeg, at vi var gode til at tage tingene op, når der opstod noget. Når der kom et problem eller en misforståelse, var fokus ikke på at placere skyld, men på at finde en fælles løsning. Det gjorde, at gruppen fungerede rigtig godt, selvom vi var forskellige som personer og havde forskellige måder at arbejde på. Jeg ser det faktisk som en styrke, fordi vi kunne se projektet fra flere perspektiver og bidrage med forskellige kompetencer.

For mig har projektet især styrket min evne til at arbejde i en gruppe. Jeg har lært endnu mere om at sætte mig i andres sted, være tålmodig og finde løsninger på situationer, der ellers hurtigt kunne skabe frustration. I stedet for at bruge energi på irritation, blev jeg bedre til at tænke: hvad er problemet, hvad har personen brug for, og hvordan kan vi komme videre sammen?

Jeg har gennem flere projekter forsøgt at bruge gruppearbejde aktivt til at blive en bedre teamplayer, men dette projekt viste mig endnu tydeligere, hvor meget gruppens dynamik betyder. En god gruppe handler ikke om, at alle arbejder ens eller tænker ens, men om at man kan kommunikere ærligt, tage ansvar og støtte hinanden, når projektet bliver presset.

Jeg er også tilfreds med min egen rolle i gruppen. Jeg bidrog både med design systemet, dataindsamling, interviews, affinity diagramming, user stories, SCRUM-overblik og min egen del af kodningen. Samtidig oplevede jeg, at jeg blev bedre til at tage ansvar uden at skulle kontrollere alt. Det var vigtigt for mig at bidrage aktivt, men også at stole på, at de andre havde styr på deres dele.

Hvis jeg skulle gøre noget anderledes, ville jeg tidligere i processen arbejde endnu mere med at skabe tydelige deadlines for de enkelte dele af projektet. Vi havde generelt godt overblik, men i de sidste uger blev presset større, og der kunne en endnu skarpere tidsplan måske have gjort afslutningen lidt mere rolig. Samtidig lærte jeg også, at selv når noget ikke går helt efter planen, kan en gruppe stadig lykkes, hvis kommunikationen er god, og alle er villige til at tage ansvar.

Samlet set har P5 været et projekt, hvor jeg både har udviklet mig fagligt og personligt. Jeg har fået mere erfaring med at arbejde struktureret gennem Design Thinking og SCRUM, men også med at håndtere samarbejde, ansvar og uforudsete situationer i en gruppe. Det er noget, jeg tager med mig videre, både i kommende projekter og i mit videre arbejde med digitale løsninger.

The post P5 Eksamensprojekt first appeared on Procesportfolio.

Vi fik en beskrivelse i starten af dagen, samt et program over dagen, hvilket jeg synes er virkelig nice, da jeg godt kan lide at have overblik over hele projektet.

Vi startede med at dele os op i grupper, som blev opdelt efter hvor mange SoMe-platforme vi bruger, og talte lidt om det. Derefter gik vi i gang med at svare lidt på Padlet. Efter det var der en samtale om TikTok og brugen af det. Vi fik en fin undervisning i forbrugeradfærden på TikTok.

Opgaven var at designe SoMe content for en virksomhed, men vi måtte både vælge en virksomhed selv eller bruge den, som de allerede havde lavet. I gruppen tog vi beslutningen om at bruge den virksomhed, som dem, der havde workshoppen, havde lavet.

Vi startede med hver især at lave Crazy8 for at finde alle mulige idéer til SoMe content. Det var meget åbent, hvilken platform vi ville lave content til, men jeg valgte at bruge 4 felter til Instagram og resten til TikTok. Jeg anbefaler ikke at prøve at læse teksten, det er en blanding af islandsk og dansk.

Efter dette gik vi sammen igennem vores idéer og valgte 2 idéer hver, som vi syntes bedst om. Næste skridt var så bare at designe, men vi valgte bare ud fra, hvad vi havde lyst til, af de idéer som var blevet valgt som de bedste.

Jeg havde virkelig meget lyst til at designe en poster til Instagram. Målgruppen er unge piger i alderen 23-29 år, og man kan læse mere om både brand identity, hvordan de bruger SoMe og målgruppen i del 2 i beskrivelsen.

Mit spørgsmål var så sådan her: Hvordan kan jeg skabe opmærksomhed omkring deres produkter, som taler til målgruppen, men også afspejler virksomhedens værdier.

Jeg havde lyst til at fokusere mere på piger. Fonten er meget piget, sådan en bubbly vibe, med en rød farve, som ikke er mega aggressiv, men cute og perky. Selve designet er meget minimalistisk, men jeg ville gerne have, at fokusset kun var på selve produktet, og at fonten skulle fange opmærksomheden. Mange piger er til minimalist aesthetics, men termen beverage princess trender også meget på SoMe lige nu. Derudover er piger ikke kun til varme drikke, men det kommer an på humør. Derfor valgte jeg at have designet som et lokkende spørgsmål, som også understøtter forbrugeradfærd: Vil du have iskaffe eller bare en almindelig varm kop kaffe, fordi vi tilbyder begge dele, er budskabet.

Efter vi var færdige med at designe, gik 2 og 2 grupper sammen og snakkede med hinanden. Vi var både heldige og uheldige, fordi gruppen vi snakkede med ikke var designere, ligesom os, men bare folk som enten arbejder eller er i anden uddannelse på UCL og ikke havde noget at vise. Til gengæld fik jeg utrolig gode reaktioner på mit design, eller som en pige sagde: “Hvis jeg havde set denne reklame, ville jeg have fortalt mine veninder om det, og jeg ville allerede have købt det!”
En anden, en ældre mand eller omkring 50 år, professor på UCL, sagde: “Jeg synes, den røde farve er fantastisk! Den er så fangende, fordi der ikke sker så meget på billedet, men den er slet ikke skrigende, bare mild og behagelig.”

Disse reaktioner gav mig så meget. Jeg er bare virkelig stolt af dette design, og at budskabet kom så godt igennem!

The post Content Workshop first appeared on Procesportfolio.

Der var i alt 10 opgaver, hvor vi fik nogle bestemte commands, som vi skulle skrive på post-it sedler, og derefter fik vi en opgave, som vi skulle løse ved at bruge disse commands. Derfor handlede alle opgaverne om at træne logisk tænkning, som er meget vigtig, når det kommer til at kode i virkeligheden.

Vi var meget hurtige til at løse opgaverne, og de første 5 opgaver var meget nemme, men vi fik ikke opgaverne på forhånd, så vi skulle vente virkelig længe, eller mellem 20–40 minutter. Efter opgave 5 begyndte jeg at forstå lidt mindre af dansk og brugte lidt længere tid på at tænke, men jeg var sammen med 2 meget stærke personer, som løste opgaverne virkelig hurtigt. Samtidig var de også virkelig gode til at sørge for at forklare alt, inden de gik videre, så selvom jeg ikke løste opgaverne så godt, som jeg gerne ville, forstod jeg alt, hvad de gjorde 100%.

Denne dag var meget sjov, og det var en god variation at prøve at arbejde med nogen, man ikke kender så godt, i forhold til dem man normalt arbejder med i sin egen klasse.

The post Code Workshop first appeared on Procesportfolio.

Hvordan kan et digitalt produkt engagere unge mellem 20–25 år i et eksisterende velgørenhedsprojekt eller organisation?

Formålet er at udvikle en digital løsning baseret på brugerens behov, hvor vi kombinerer research, design og udvikling. Projektet inkluderer en interaktiv prototype (HTML, CSS og JavaScript), SoMe-indhold samt et design system, og arbejdes med gennem Scrum og Design Thinking.

Sprint 1 – 03/03 → 06/03

Sprint 1 var starten på projektet og lagde fundamentet for hele vores videre arbejde. Vi valgte bevidst at bruge tid på forberedelse og struktur, før vi gik dybt ind i research og idéudvikling. Det var vigtigt for os at skabe en fælles forståelse i gruppen samt en klar struktur for samarbejdet.

Vi startede med at udarbejde en gruppekontrakt, opsætte Scrum og definere roller i gruppen. Dette gav os et tydeligt overblik over ansvar og arbejdsfordeling fra begyndelsen. Samtidig arbejdede vi med interessentanalyse og risikoanalyse, hvor vi fik feedback, som hjalp os med at afgrænse projektet bedre. Vi gik mere i dybden med valg af organisation og endte med at vælge Ungdommens Røde Kors, da det passede bedre til vores målgruppe og problemstilling.

Derudover begyndte vi at arbejde med KWHL-modellen, som hjalp os med at strukturere vores viden og identificere, hvad vi havde brug for at undersøge nærmere. Denne forberedelsesfase var afgørende, da den kom til at styre vores tilgang til research og sikre, at vi arbejdede mere målrettet.

Herefter gik vi ind i Empathize-fasen i Design Thinking, hvor vi arbejdede med både desk research og dataindsamling. Vi udarbejdede et spørgeskema, som blev delt på Facebook, hvor vi fik i alt 37 besvarelser. Af disse var 20 inden for vores målgruppe og 17 udenfor, hvilket gav os brugbar indsigt, men krævede, at vi var kritiske i vores analyse af dataene. For at opnå en dybere forståelse gennemførte vi også interviews med studerende på skolen, hvilket gav os et mere nuanceret og kvalitativt indblik i motivation og barrierer i forhold til frivilligt arbejde.

Samtidig arbejdede vi med Define-fasen, hvor vi udviklede vores problemforståelse og begyndte at formulere en mere præcis problemstilling. Dette var en iterativ proces, hvor vi løbende justerede vores retning på baggrund af både feedback fra vejledere og de indsigter, vi fik gennem vores research.

Vi arbejdede gennem hele sprintet efter Scrum-metoden, hvor vi organiserede vores opgaver i et Scrumboard og arbejdede med en klar struktur fra backlog til to do, in progress og done. Vi fordelte opgaver mellem os og arbejdede både individuelt og i fællesskab, hvilket skabte et godt flow i processen. Jeg havde rollen som developer og kvalitetsansvarlig, hvilket betød, at jeg både arbejdede med udviklingsrelaterede opgaver og samtidig havde fokus på at sikre kvalitet og sammenhæng i det, vi producerede.

Denne uge gik rigtig godt, og vi fik hurtigt opbygget et stærkt samarbejde i gruppen. Det, der især fungerede godt, var hvor struktureret vores arbejdsproces var fra starten. Som en person, der selv er meget organiseret, oplevede jeg, at denne tilgang passede mig rigtig godt og gjorde mig tryg i projektet. Det var også vigtigt, da dette er det største projekt, vi har arbejdet med indtil nu.

Vores fokus på forberedelsesarbejde var en klar styrke. Gruppekontrakt, Scrum setup, interessentanalyse og risikoanalyse var ikke bare formelle krav, men noget vi aktivt brugte til at styre vores arbejde. Det gav os et solidt fundament og gjorde det lettere at arbejde målrettet i de næste faser.

Det fungerede også godt, at vi kombinerede kvantitativ og kvalitativ research. Spørgeskemaet gav os et bredere overblik, mens interviews bidrog med en dybere forståelse af målgruppen.

Hvis noget kunne forbedres, kunne vi have været endnu skarpere i afgrænsningen af målgruppen fra starten, samt arbejdet mere struktureret med overblik over vores indsamlede data tidligere i processen.

Sprint 2 – 09/03 → 13/03

I Sprint 2 skiftede fokus fra research til ideudvikling og de første konkrete udformninger af løsningen. Der blev arbejdet videre med de data, som blev indsamlet i Sprint 1, hvor resultater fra spørgeskema og interviews blev analyseret og brugt som grundlag for at træffe beslutninger om projektets retning.

På baggrund af dette blev der udviklet et koncept, som tager udgangspunkt i et digitalt værktøj for frivillige hos Ungdommens Røde Kors. Løsningen er tænkt som en app, der adresserer alle tre problemstillinger ved at skabe bedre overblik, tydeligere rammer omkring opgaver og øge motivationen hos brugerne. Formålet er at gøre det lettere og mere attraktivt for unge at engagere sig i frivilligt arbejde.

I starten af sprintet blev data analyseret yderligere, og der blev udarbejdet en persona på baggrund af indsigterne. Denne persona blev brugt som et centralt værktøj til at fastholde fokus på målgruppen i den videre designproces. Derudover blev der arbejdet med UI inventory og user stories, som blev tilføjet til Scrumboardet for at skabe en mere struktureret tilgang til udviklingen af løsningen.

I idefasen blev der udviklet forskellige løsningsforslag, og gennem dialog med undervisere blev retningen gradvist præciseret. Dette bidrog til at gøre konceptet mere målrettet og bedre forankret i både målgruppen og problemstillingen.

I prototypefasen blev arbejdet opdelt mellem gruppemedlemmerne. Liana arbejdede med wireframes og opbygningen af løsningen. Jeg arbejdede med styletile og den visuelle retning. Rikke arbejdede med moodboard og visuel inspiration, og Sarah arbejdede med indholdsstrategi, som understøtter løsningen og målretter kommunikationen mod målgruppen.

Samtidig blev der arbejdet videre med design thinking-processen, hvor idéer løbende blev udviklet og justeret på baggrund af feedback. Undervejs modtog vi vejledning fra undervisere, som hjalp med at afklare både designvalg og tekniske muligheder.

Mod slutningen af sprintet blev der arbejdet med forberedelse og gennemførelse af midtvejspitch, hvor vi præsenterede vores proces og løsning. Vi modtog god og konstruktiv feedback, som blev brugt til at videreudvikle konceptet og afklare de næste skridt. Derudover blev arbejdet med kodning påbegyndt, hvor JavaScript-opgaver blev fordelt, og de første skridt mod en responsiv løsning blev taget.

Gennem hele sprintet arbejdede vi med Scrum, hvor opgaver blev organiseret og løbende opdateret på Scrumboardet. Dette var særligt vigtigt i dette sprint, da projektet blev mere komplekst, og flere elementer skulle koordineres.

I dette sprint begyndte projektet for alvor at tage form, og det var motiverende at se, hvordan vores research fra første sprint blev omsat til konkrete idéer og løsninger. Konceptet blev tydeligere og bedre forankret i både målgruppen og de problemstillinger, vi arbejdede med.

Samarbejdet i gruppen fungerede fortsat rigtig godt, og vi arbejdede struktureret og målrettet. Det fungerede særligt godt, at opgaverne blev fordelt mellem os, så alle kunne fokusere på deres del, samtidig med at vi arbejdede mod en fælles løsning.

Det fungerede også godt, at vi brugte feedback aktivt, især i forbindelse med midtvejspitchen, hvor vi fik bekræftet, at vi var på rette vej, men også blev gjort opmærksomme på, hvad der kunne forbedres.

Hvis noget kunne forbedres, kunne vi blive endnu skarpere i vores interne kommunikation, især når ikke alle arbejder samme sted eller på samme tid. Derudover oplevede vi perioder med træthed, som påvirkede vores fokus, og her er der mulighed for at arbejde mere stabilt med vores arbejdsrytme.

Sprint 3 – 16/03 → 20/03

I Sprint 3 blev fokus flyttet fra idé og design til implementering og færdiggørelse af projektet. Arbejdet tog udgangspunkt i den løsning, der var udviklet i Sprint 2, og målet var at omsætte den til funktionel kode og færdiggøre de vigtigste deliverables.

Der blev fortsat arbejdet med design thinking-processen, som blev opdateret løbende i takt med udviklingen. Derudover blev interessentanalyse og user flow justeret for at sikre, at løsningen fortsat matchede både brugerens behov og projektets overordnede mål. Responsivitet var en central del af sprintet, hvor der blev arbejdet med at sikre en god brugeroplevelse på mobil, tablet og desktop.

I dette sprint blev der arbejdet mere individuelt end tidligere. Jeg havde ansvar for at kode løsningen og implementere den teknisk, mens de andre arbejdede på deres respektive dele af klientrapporten. Målet var, at alle færdiggjorde deres afsnit i løbet af ugen, så der kunne arbejdes videre med opsætning i InDesign i næste sprint.

I dette projekt arbejdede jeg meget selvstændigt med at kode løsningen ud fra det design og den struktur, vi havde udviklet. Jeg lagde stor vægt på at opbygge en klar HTML-struktur med BEM naming og anvende CSS Grid for at sikre et stabilt layout i overensstemmelse med mockup.

Jeg fik kodet en stor del af løsningen og havde en fungerende UI, hvor jeg blandt andet:

• opbyggede card components (card-vagt)
• arbejdede med reusable classes og modifiers (fx card-vagt–anmodet)
• sikrede godt alignment og visuel hierarki
• gjorde siden responsiv med mobile-first tilgang

Efter at have færdiggjort en stor del af koden, begyndte jeg at sammenholde min JavaScript-del med pensum. Her blev det tydeligt, at min løsning ikke opfyldte alle krav, især i forhold til:

• brug af arrays og objects
• loops (for / forEach)
• state management
• dynamisk DOM manipulation

Derfor tog jeg en bevidst beslutning om at starte JavaScript-delen forfra.

Selvom det var udfordrende, var det meget lærerigt. Fordi jeg allerede havde en solid HTML- og CSS-struktur, kunne jeg genbruge store dele af arbejdet og fokusere mere målrettet på JavaScript.

I anden omgang lagde jeg større vægt på at:

• opbygge en klar datastruktur (arrays/objects)
• koble data til UI
• anvende event listeners og conditions
• håndtere state (fx når en bruger anmoder om en vagt)

Dette var en ret tung uge, især fordi jeg kodede stort set hele tiden. Det kunne være krævende at arbejde så intensivt alene, men samtidig syntes jeg også, det var virkelig sjovt og motiverende. Jeg kunne tydeligt mærke, hvor meget jeg har udviklet mig som koder, da jeg var i stand til at genopbygge løsningen på en bedre og mere struktureret måde.

Det, der fungerede godt i dette sprint, var, at vi arbejdede effektivt og fortsat nåede vores deadlines. Vi havde alle ansvar for hver vores del af klientrapporten, som vi fik færdiggjort i løbet af ugen. Det gjorde det muligt at fokusere på opsætningen i InDesign i det næste sprint.

Processen med JavaScript gav mig en vigtig læring. Jeg fandt ud af, at det ikke er nok, at koden bare virker, den skal også afspejle det, vi har lært. Jeg var nødt til at stoppe, evaluere mit arbejde og tage beslutningen om at starte forfra, hvilket var udfordrende, men meget værdifuldt.

Jeg lærte også, hvor vigtigt det er at:

• stoppe og evaluere sit arbejde i forhold til kravene
• være villig til at starte forfra, hvis det er nødvendigt
• opbygge kode, så den kan genbruges

Alt i alt var dette et krævende, men meget lærerigt sprint, hvor jeg udviklede mig både teknisk og i min evne til at arbejde selvstændigt.

Sprint 4 – 23/03 → 27/03

I Sprint 4 var fokus på at færdiggøre og aflevere projektet. Størstedelen af løsningen var allerede på plads fra det forrige sprint, så arbejdet i denne uge handlede primært om at afslutte de sidste deliverables og sikre, at alt var klar til aflevering.

Jeg arbejdede med opsætningen af klientrapporten i InDesign, hvor målet var at præsentere indholdet klart og professionelt. Samtidig færdiggjorde jeg min individuelle video, hvor jeg gennemgik min kode og min arbejdsproces. Jeg færdiggjorde også min procesportfolio, som tidligere havde haft lavere prioritet, mens fokus var på kodning og andre dele af projektet.

De øvrige gruppemedlemmer arbejdede med deres respektive opgaver, herunder SoMe-content, som blev færdiggjort sideløbende med de andre deliverables. Da vi havde arbejdet meget struktureret og effektivt i de tidligere sprint, var vi allerede langt i starten af ugen og havde derfor relativt lidt tilbage sammenlignet med projektets omfang.

Dette sprint var i høj grad præget af træthed. Vi havde arbejdet meget intensivt gennem hele projektet, og det kunne mærkes både mentalt, følelsesmæssigt og fysisk. Jeg oplevede, at energiniveauet var lavere, selvom vi var tæt på målet.

Samtidig var det meget tilfredsstillende at se, hvor langt vi var nået i starten af ugen. Det, at vi havde så lidt tilbage, gav en følelse af ro og bekræftede, at den indsats vi havde lagt i de tidligere sprint, havde været effektiv. Vi kunne derfor fortsætte arbejdet målrettet og arbejde hen imod aflevering om torsdagen.

Det, der fungerede godt, var, at vi formåede at færdiggøre alle vores opgaver og bevare overblikket, selv i en periode med lav energi. Jeg oplevede også, at jeg har udviklet mig meget gennem projektet – både i forhold til kodning, struktur og evnen til at arbejde selvstændigt.

The post Brugergrænseflade og digitalt indhold first appeared on Procesportfolio.

Jeg valgte hjemmesiden KreStoffer, som er en strikke- og håndarbejdsbutik. For at forstå branchen bedre undersøgte jeg lignende hjemmesider for at identificere designmønstre og tendenser. Dette gav mig både inspiration og en bedre forståelse af, hvad brugere forventer. Her er Jakob’s Law relevant, da brugere forventer, at en hjemmeside fungerer på samme måde som andre lignende sider inden for samme branche.

Sammen med Sarah og Rikke fandt vi et lokale, hvor vi arbejdede koncentreret hele dagen. Det var en god og anderledes oplevelse sammenlignet med resten af semesteret, som i høj grad har været præget af kodning.

Jeg startede processen med at lave et Style Tile, som hjalp mig med at definere farver, typografi og visuelle elementer. Jeg valgte ikke at lave et moodboard, da jeg vurderede, at det ikke var nødvendigt for denne type hjemmeside, men jeg havde stadig en klar idé om den stemning, designet skulle formidle.

I min research lagde jeg især mærke til, hvordan mange hjemmesider arbejder med visuelle “blocks” til at samle relaterede elementer. Dette hænger sammen med både Law of Common Region, hvor elementer opfattes som en gruppe, når de deler et afgrænset område, og Law of Proximity, hvor elementer tæt på hinanden naturligt grupperes. Disse principper brugte jeg aktivt i mit layout.

Derudover havde jeg også Hicks Law i baghovedet, som beskriver, hvordan for mange valgmuligheder kan gøre det sværere for brugeren at træffe beslutninger. Derfor forsøgte jeg at holde designet overskueligt og reducere unødvendig kompleksitet.

Herefter arbejdede jeg videre med mit mockup, som blev mit primære fokus resten af workshoppen. Jeg prioriterede tiden på at udvikle og finpudse designet frem for at lave en præsentation, hvilket passede godt til workshopens formål.

I forhold til farvevalg har jeg en tendens til at holde mig til få, harmoniske farver. I dette projekt valgte jeg dog at udfordre mig selv ved at arbejde med flere primære farver samt en lysere variation. Det var en udfordring at få dem til at fungere sammen og give dem plads i designet. Set i bakspejlet ville jeg nok holde det mere simpelt i en lignende opgave fremover.

Refleksion

Det er ret vildt at tænke på, hvor meget jeg har udviklet mig som designer på bare et halvt år. I starten af første semester havde vi en lignende opgave, hvor vi skulle redesigne en hjemmeside over cirka en måned i en gruppe på fire. I dette challenge formåede jeg at gennemføre en tilsvarende proces på én dag, hvilket tydeligt viser min udvikling både fagligt og metodisk.

Jeg var særligt opmærksom på alignment i mit design, da jeg tidligere har fået feedback om, at det er noget, jeg skal have ekstra fokus på. Efter workshoppen fik jeg også feedback fra Jesper, som både fremhævede min udvikling og gav konkrete råd til, hvordan jeg kan forbedre mit alignment yderligere. Det gav mig en god forståelse af, hvor jeg står nu, og hvad jeg skal arbejde videre med fremadrettet.

The post Design Challenge first appeared on Procesportfolio.

Vi sendte e-mails til Albani Bryggeriet, Bootleggers Bar, Anarkist og Odense Bys Museer. Vi fik dog kun svar fra Odense Bys Museer. Efter vi havde fået svar fra dem, mødtes vi i gruppen for at forberede det interview, vi skulle gennemføre.

Vi fik et møde med en medarbejder ved navn Mads, som er en vigtig del af teamet hos Odense Bys Museer. Da vi mødte Mads, var han meget åben og besvarede vores spørgsmål på en grundig og hjælpsom måde. Efter interviewet fik vi mulighed for at se en udstilling i TID, hvor Mads fortalte lidt om, hvilke faggrupper der er involveret i arbejdet med udstillinger på museet.

Efter interviewet arbejdede vi videre med at udvikle en persona baseret på vores interview – en Multimediedesigner, som arbejder hos Odense Bys Museer. Derefter lavede vi en præsentation ud fra det, vi havde lært. Til sidst i projektet præsenterede alle grupper det firma, de havde besøgt, med fokus på, hvad en Multimediedesigner arbejder med i den pågældende virksomhed.

Jeg synes, at dette projekt var meget relevant for os, der læser denne uddannelse. Multimediedesigner er en meget alsidig uddannelse, som giver mange forskellige muligheder i forhold til fremtidigt arbejde. Jeg ville dog have fundet projektet endnu mere interessant, hvis vi også havde haft mulighed for at se præsentationerne fra begge hold, altså både hold 1 og hold 2. Det ville have givet mig en endnu bedre indsigt i arbejdsmarkedet, som jo netop er formålet med projektet.

The post Netværksdage first appeared on Procesportfolio.

Vores projekt var ret simpelt, vi skulle finde en hjemmeside, som vi ville redesigne, men hver af os skulle lave én JS-kode, som indeholdt alt vores pensum. Når det var færdigt, skulle vi lave en fælles video, hvor vi tog én af vores koder og forklarede den grundigt sammen.

Der var ikke særligt store krav til vores HTML- og CSS-kode. Gruppen tog en fælles beslutning om at bruge Claude, som er en programmerings-AI, til at lave HTML og CSS, og på den måde var vi sikre på, at vi havde nok tid til at færdiggøre projektet. Vi arbejdede på projektet fra den 9.–13. februar.

Vi fandt en virkelig dårlig hjemmeside, som tilhører en blomsterbutik. Ud fra det besluttede vi hver især, hvad vi ville programmere i JS. Jeg valgte at programmere en “tilbuds”-knap, som viser, hvilke blomster der er på tilbud på en bestemt dag.

Min idé var først, at det skulle være en knap, man trykker på, og så kommer der et popup alert-vindue, som viser fem tilfældige forskellige typer blomster på tilbud. Jeg vidste nogenlunde, hvordan jeg skulle kode det og sætte det op, men det var første gang, jeg ikke skulle stille 100 spørgsmål til ChatGPT. Det tog mig én dag at kode det, men undervejs fandt jeg ud af, at man ikke kan indsætte billeder i et popup alert, hvilket er ret ærgerligt. Derfor måtte jeg ændre min idé fra at vise tilfældige billeder i et popup-vindue til i stedet at lave en knap, som, når man trykker på den, viser en kolonne, der folder sig ud med fem billeder af fem forskellige blomster, markeret efter ugedagene, altså hvilken dag de er på tilbud. Når man trykker på knappen igen, lukker kolonnen eller forsvinder.

Derefter mødtes vi alle for at samle vores koder i HTML og CSS og forbinde alt JavaScript til HTML. Til sidst valgte vi den kode, vi ville tale om, som var Sheilas kode, og fordelte, hvem der ville forklare hvad. Til sidst optog vi en video, hvor vi forklarede hele hendes kode.

Projektet var slet ikke så svært, som jeg havde forventet, men det hjælpede rigtig meget, at jeg deltog i alle JS-timerne, i modsætning til hvad jeg oplevede med HTML- og CSS-timerne. Jeg synes generelt, at det er sjovt at kode, selvom jeg er virkelig langsom, og det ofte er ret svært. Jeg var også stolt af mig selv over, hvor meget jeg forståede koden, og hvor lidt jeg havde brug for at rådføre mig med AI. Jeg har aldrig arbejdet sammen med de her piger før, og jeg syntes generelt, at det fungerede rigtig fint, en ret afslappet gruppe, som ikke stresser over småting.

The post Real Life JS first appeared on Procesportfolio.