Slutprojekt: design

Designa för en specifik människa

Nu ska du paketera om ett av dina tidigare program som en färdig applikation, i ett fönster eller i terminalen. Men formen är inte det svåraste steget i uppdraget. Det svåraste steget är ett som inte involverar en enda rad kod: att bestämma vem du bygger för, och vad de faktiskt behöver kunna göra.

Slutprojektet går i tre steg, och det här är det första. Här bestämmer du vad du ska bygga och för vem. I nästa del bygger du det. I den sista städar du koden och lämnar ifrån dig den. Du skriver alltså ingen kod i den här delen, och det är avsiktligt: en timme vid ritbordet sparar en dag vid tangentbordet.

Det verkar som en administrativ detalj. Det är det inte. Nästan allt som blir fel i ett gränssnitt, knappar på fel ställe, stegen i fel ordning, förvirrande felmeddelanden, utebliven återkoppling, går att spåra tillbaka till att den som byggde inte hade en konkret person i tankarna. De hade sig själva, eller en abstrakt “användare”, eller ingen alls. Och det syns i resultatet.

Professionell UX-design börjar alltid med en specifik människa: inte “vuxna” eller “unga” utan en namngiven person med konkreta egenskaper, konkreta mål och konkreta begränsningar. Personen behöver inte vara verklig, men tillräckligt konkret för att du ska kunna ställa frågor mot den: Skulle Maja hitta den här knappen? Förstår hon varför programmet frågar det här? Klarar hon av att läsa den texten?

Det steget gör du innan du öppnar VS Code.

Välja projekt

Du bygger vidare på något du redan gjort, inte något nytt. Varje kandidat har sina styrkor:

Brawl blir en kampskärm med tydlig statusinformation: hälsopoäng, en turräknare och valen att attackera eller försvara. Målgruppen kan vara ett spelintresserat barn eller en kamrat som aldrig öppnat en terminal.

Textäventyret blir en narrativ upplevelse steg för steg: berättelsen visas, spelaren väljer väg och kommer vidare. Målgruppen kan vara ett yngre syskon eller en åldersgrupp du skriver berättelsen för.

Inventoryt blir en samling du fyller på och rensar i: ett sätt att lägga till, en lista som visas, allt sparat till fil mellan gångerna. Här kan du ta ett steg åt sidan och göra det till något eget, en träningsdagbok, en läslogg, en samlarförteckning. Målgruppen är någon som vill hålla ordning på något som betyder något för dem.

Caesar-chiffret blir ett litet krypteringsverktyg: meddelandet, nyckeln och de två valen kryptera och dekryptera. Målgruppen kan vara en nyfiken person som vill leka med hemliga meddelanden.

Klickräknaren från Knappar & räknaren är det minsta programmet på listan, och därför det som kräver mest av dig: den måste växa till något någon faktiskt vill öppna. Den tydligaste vägen dit är en klickare i stil med Cookie Clicker, där varje klick ger poäng och poängen köper något som klickar åt dig, så att kurvan börjar dra iväg av sig själv. Andra riktningar är en tävling mot klockan, en poängräknare för ett sällskapsspel eller en räknare för hur många gånger något hänt idag.

I fönsterspåret blir varje val en knapp och varje utskrift en etikett. I terminalspåret blir samma val menyalternativ och samma utskrifter rader. Innehållet är detsamma, det är formen som skiljer.

Välj det projekt där du kan svara på frågan: varför skulle just min målgrupp vilja använda det här?

Hur långt du siktar

Bestäm ambitionsnivån nu, innan du skissar, för den avgör hur mycket som ska rymmas på skärmen.

Grunden är ett av dina program med ett gränssnitt runt sig, anpassat efter din målgrupp, som går att starta och avsluta utan att krascha. Det är hela uppdraget, och det är inte lite. Ett program som fungerar hela vägen är alltid värt mer än ett halvfärdigt som ville för mycket.

Utbyggnaden är grunden plus något som inte fanns i originalet. Brawl får ett minne som sparar segrar mellan gångerna. Textäventyret får en spelare som kan fortsätta där hen slutade. Inventoryt blir en träningsdagbok som räknar ihop veckan. Du bygger vidare på ditt eget arbete i stället för att bara klä på det.

Kombinationen är två av dina program som möts. Ett vägval i textäventyret leder in i en strid från Brawl. Inventoryt blir hjältens ryggsäck, och det du plockar upp i ett kapitel finns kvar i nästa. Caesar låser dagboksinläggen så att bara den med nyckeln kan läsa dem. Det är den svåraste vägen, för dina två program måste komma överens om vem som håller i tillståndet, men det är också den som ger dig något ingen annan i klassen har byggt.

Väljer du kombinationen: rita båda programmen i samma skiss och markera var övergången sker. Det är den punkt där projektet brukar knaka.

Definiera målgruppen

Skriv ned en person. Inte en kategori, en person.

Namn: Maja
Ålder: 12 år
Bakgrund: Gillar berättelser och djur. Har surfplatta och dator hemma
          men har aldrig öppnat en terminal.
Mål: Spela ett roligt spel på datorn utan att installera något.
Begränsningar: Läser inte engelska flytande. Van vid appar med
               tydliga knappar. Tappar intresset om något är krångligt.

Nu kan du pröva varje designbeslut mot Maja. Förstår Maja det här felmeddelandet? Hittar hon Avsluta-knappen? Är texten stor nog för henne att läsa bekvämt?

Det är UX UX (User Experience) Summan av en persons upplevelse när de använder ett program. Innefattar hur lätt det är att förstå, hur effektivt det är att använda och hur det känns att interagera med det. UX-design försöker optimera upplevelsen för den specifika målgruppen. Se: Slutprojekt: design -design. Inte filosofi, utan att ha en konkret person att rikta sina frågor mot.

Skissa gränssnittet

Ta ett papper och en penna. Rita en rektangel, det är skärmen. Rita in det användaren ska möta.

Vad ska visas vid start? Vad händer när användaren gör något? Hur ser nästa tillstånd Tillstånd (state) Data som beskriver programmets nuvarande läge. I tkinter lagras tillstånd i globala variabler som funktionerna läser och modifierar. Se: Knappar & räknaren ut? Hur tar de sig tillbaka?

Så här kan ett fönster se ut:

+-----------------------------+
|  Majas Äventyr              |
+-----------------------------+
|                             |
|  [Berättelsetext här]       |
|                             |
+-----------------------------+
|  [ Gå vänster ]  [ Stanna ] |
+-----------------------------+

Och så här samma tillstånd i terminalen:

=== Majas Äventyr ===

[Berättelsetext här]

1. Gå vänster
2. Stanna
3. Avsluta

Välj (1-3):

En skiss Prototyp / Skiss En tidig, icke-funktionell representation av ett gränssnitt. Pappersskisser är den snabbaste och billigaste formen. Syftet är att testa och validera idéer innan tid läggs på implementation. Se: Slutprojekt: design behöver inte vara vacker. Den ska svara på frågorna: vad finns var, och vad händer när användaren gör sitt val? Rita minst tre tillstånd: startskärmen, ett typiskt interaktionstillfälle och ett slutläge.

Planera arkitekturen

Med skissen klar planerar du hur koden ska struktureras. Vilka funktioner behöver du, och vad anropar vad? Tillstånd i variabler, logik i funktioner och visning för sig, nu för hela ditt program:

funktioner:
  bygg_granssnittet() -> sätter upp det användaren möter
  starta_spel()       -> återställer tillståndet, visar intro
  behandla_val(val)   -> tar emot användarens val, uppdaterar tillståndet
  visa()              -> visar det aktuella tillståndet
  avsluta()           -> sparar framsteg, avslutar programmet

data (tillstånd):
  nuvarande_kapitel   -> vilket kapitel spelaren är i
  spelare_namn        -> hämtat från inmatningen eller sparfilen

Det är inte ett löfte om exakt hur koden ska se ut, det är en hypotes att testa. Koden kommer att avvika från planen, och det är normalt. Planen är ändå värdefull för att komma igång åt rätt håll.

README.md

README.md är det första en person ser när de öppnar ditt GitHub-repository. Den ska svara på tre frågor: vad är det här för program (en kort, konkret beskrivning för din målgrupp, inte för en programmerare), vem är det för (din målgruppsanalys Målgruppsanalys En konkret beskrivning av vem ett program är designat för, inte en bred kategori utan en specifik fiktiv person med namn, egenskaper, mål och begränsningar. Används som referenspunkt för varje designbeslut. Se: Slutprojekt: design ), och hur ser det ut (infoga din skiss, fotografera eller skanna den och lägg filen i projektet).

# Majas Äventyr

Ett textäventyr för barn 8-14 år som vill utforska en magisk skog.
Programmet körs i ett eget fönster, ingen terminal behövs.

## Målgrupp

Designat för Maja, 12 år, som gillar berättelser och är van vid appar
med tydliga knappar. Därför blev det fönsterspåret: stora texter,
tydliga knappar och inga tekniska felmeddelanden.

## Gränssnittsskiss

[bild på pappersskiss]

## Vad jag skulle förbättra med mer tid

...