Relationsproblem

Jag har läst Umair Haques olika bloginlägg och essäer senaste halvåret. Han är ganska kompakt i sitt sätt att skriva så det har tagit ett tag att komma till det stadium då jag kan reflektera över kunskapen han delar med sig.

Nyligen har jag iaf reflekterat över en av hans idéer, nämligen att IT-sfären inte löser riktiga problem längre. De problem han diskuterar är svält, vattenbrist, miljöförstöring etc. Problem på den skalan löser inte jag (än), men problem-perspektivet är intressant att applicera även på mina projekt.

För vissa av projekten kan jag inte komma på vilka problem som egentligen löses. Det kan vara en orsak till att de projekten ej lyuckas så bra.

OrkidéPrat löser dock tre problem. Problemen är, som sagt var, inte grandiosa, men att lösa dem förbättrar livet en aning för en del av Sveriges befolkning.

3 problem i OrkidéSverige
1. Sveriges orkidéodlare är ganska få och utspridda över en geografiskt stor yta. Det är därför svårt att hitta, träffa och skapa en relation med andra intresserade.
Lösning: OrkidéPrat är ett geeografiskt och tidsmässigt oberoende forum där orkidéintresserade kan träffas och prata publikt likväl som privat.

2. Svårt att hitta råd om specifika arter och ovanligare släkten.
Lösning: Pratoteket samlar OrkidéPrats kunskap. Om infon man söker inte finns i Pratoteket kan man såklart be medlemmarna om råd. Ett framtida wiki-liknande projekt kommer göra Pratoteket än bättre då wikin kommer innehålla artiklar, snarare än enstaka frågor med svar, om en mängd aspekter av orkidéodlandet.

3. Svårt att hitta ovanliga sorter att köpa i Sverige.
Lösning: Auktioner och KöpOchSälj-möljligheter där medlemmarna kan köpa sorter av varandra. Sambeställningar för att minska kostnaderna som det innebär att importera.

Utifrån de identifierade problem ovan kommer jag fortsätta utveckla OrkidéPrat. Lösningar ska bli kraftfullare, enklare och tydligare.

Värdet av problem
Att se på de specifika problem en tjänst skall lösa känns nu, tack vare Haque, som en självklarhet. Det är dock ett problem att vissa projekt jag just nu arbetar på inte löser tydliga problem...

Ibland behöver världen anpassas till individen

Vi lever inte alla i samma värld. Med det som utgångspunkt kan fantastiska möjligheter skapas för specifika personer och grupper. Ett exempel är ZacBrowser vilken fundamentalt ökar interaktionsmöjligheterna för unga personer med autism.

Artikel på boston.com.

Interaktion

Vad är det som utgör de där relationerna?




Vad jag är intresserad av, och vill arbeta med, syns ovan. Jag kallar det TPI, PPI och MPI. Och PPI är kung.

PPI = person-person-interaktion.
Det är PPI som är hela anledningen. Kanske kan jag till och med säga att PPI är meningen med livet. Dalai Lama säger att Lycka är meningen med livet. PPI kan medverka till lycka.

Jag vill möjliggöra person-person-interaktion genom att:
- bygga person- och interaktion-centrerade tjänster
- aktivt initiera interaktion genom att exempelvis delta i gemenskapen
- aktivt underhålla gemenskapen genom att exempelvis moderera och ge support samt lägga till nya utvecklande tjänster
- aktivt hjälpa gemenskapen definiera sig själv och sina interaktionspreferenser genom att exempelvis föreslå regler och interaktionsformer samt diskutera hur konflikter kan undvikas och hanteras
- avsluta gemenskapen på gott sätt när så behövs genom att exempelvis möjliggöra export av eget prat samt hänvisa till alternativa forum för fortsatt gemenskap

PTI = person-tjänst-interaktion
Var person behöver interagera med tjänsten för att kunna kommunicera och skapa gemenskap. Interaktionen behöver vara ... god.

Jag vill möjliggöra god person-tjänst-interaktion genom:
- tjänstedesign (definition av delar i tjänsten)
- interaktionsdesign (prototyper, tester, implementationsdefinitioner)
- informationsarkitektur (innehållskategorisering, navigation, sök och findability)

MPI = möjliggörare-person-interaktion
De som bygger tjänsten behöver bygga sitt arbete runt kommunikation med de kommande användarna.

Jag vill möjliggöra produktiv kommunikation genom:
- användartester (som del av Interaktionsdeign ovan)
- support (struktur kring support-arbetet)
- moderering

Sammanfattningsvis vill jag hjälpa personer hitta varandra under goda förhållanden. Jag vill möjliggöra goda virtuella samhällen.

Jag är inte statistik!

Relationer går inte att beskriva med statistik.

Det slog mig alldeles nyss att statistik är meningslöst som designgrund. Jag utvecklade en del besöksstatistik utifrån en mycket detaljerad databas med besöksstatistik. Man kan skapa hur många tabeller och grafer som helst utifrån datan. Jag började dock ställa frågan:

"Men, vad kan vi förändra utifrån den här grafen?"

Svaret var oftast:

"Ingenting"

Problemet är att den typ av data vi har, vanlig besöksstatistik, inte säger något om vad som kan förändras för att förbättra saker. Exempelvis kan vi veta att X% av de som ser sida A går vidare till sida B. Jaha. Det säger vanligen inget. Vi har ett flöde där det kan tänkas vara vettig statistik: Hur många av de som tittat på villkoren väljer att bli medlemmar. Utifrån den procenten kan vi experimentera med villkorstexten och dess layout. Vilka specifika problem villkoren har vet vi dock inget om...

En "lösning på problemet" är multivariat testning. Det har vi dock inte gjort, men kanske kommer göra, vem vet.

Det uppenbara är dock att avstå från att formge för statistiken och istället designa för individer.

Genom att göra användartester och använda personas kan vi ha en mer solid grund att designa utifrån.

Inga status-uppdateringar tack, men gärna Inspiration!

Kommunikation i relationer kan vara av ett flertal typer. Kommunikation som inte löser ett primärt mål filtrerar nog de flesta bort, snabbt.

Ett par exempel på typer av innehåll i kommunikation:

1. status-uppdateringar ("Hur e läget?" "Fint.")
2. pladder och info ("Vad gjorde ni på gympan idag då?" "Samma gamla vanliga, hinderbana.")
3. försäkranden ("Du klarar det!")
   
4. fel-meddelanden ("Nej, ha inte i timjan i pajen.")
   
5. diskussion och inspiration ("Jag ser pappersprototyper som vårt främsta utvecklingsverktyg." "Jaha. Vilka fördelar och nackdelar har den typen av prototyper jämfört med html-prototyper?")
6. slagsmål ("Sluta skriva på din blog att jag är fet!" "Men du är ju det ju!")
   

De sex typerna ovan tycker jag är listade i ökande viktighets-ordning. Diskussioner är alltså viktigare än pladder.

Innehållet i status-uppdateringar oss människor emellan är nog riktigt oviktigt. Vi fortsätter endå med dem, för de är en mycket viktig del i att underhålla relationer oss människor emellan. Interaktion handlar ju primärt om att underhålla relationer.

I webbapplikationer finns det många tillfällen då inte personer pratar. Istället pratar 'systemet'/'webbplatsen'/'applikationen'. 'Applikationen' har inget ansikte, ingen röst.

Användarna har ingen personlig relation till 'applikationen'. Därmed har användaren väldigt liten anledning att delta i interaktion med 'applikationen'.

Vilka motsvarigheter till de 'riktiga' interaktionstyperna ovan finns det då i webbapplikationer?

1. status-uppdateringar "Du är på steg 2 av 5"
2. info och instruktioner: "Fyll i fälten och klicka på 'skicka'"
3. försäkranden: "Det går snabbt och är gratis att bli medlem"
   
4. fel-meddelanden: "du glömde fylla i din e-postadress"
5. diskussioner och inspiration: utförliga artiklar om intressanta ämnen och trevliga diskussioner mellan personer
6. slagsmål: flame wars

Jag vill säga att webbanvändare generellt inte läser någonting före punkt 5 och 6 ovan. Diskussioner och slagsmål däremot kanske man ögnar igenom, eller till och med läser.

Generellt kan man alltså säga att den text som webbproducenterna skriver inte läses, medan användargenererad text kanske läses.

För webbskapare betyder detta att extremt fokus behöver lägas på att inte behöva felmeddelande, instruktioner och sånt blaj. Användartester är självklart en av lösningarna på problemet.

Ett intressant undantag tror jag är Inspiration. I applikationer där användaren ska skapa något (skriva en text, bygga en frågesport, publicera ett fotogalleri) kan rent inspirations-skapande innehåll hjälpa användaren. Jag tänker mig att 'inspirationen' visas i eller nära flödet som användaren går genom för skapa artefakten. Inspirationen är därmed en del av 'systemet'.

Anledningen att inspiration kan vara värdefullt är att inspirationsmaterialet löser ett av användarens primära problem: "Jaha, jag ska skapa ett fotogalleri. Hur vill jag att det ska se ut då?" Felmeddelanden och statusinfo löser inga primära problem för användaren.

/ Björn

ps. Självklart ska vi tillse att status-meddelanden och hjälp-texter finns tillgängliga på de ställen där se behövs. Så gäller även text och andra element vars syfte är att försäkra användaren om att han kommer klara av skapandeprocessen. Grejjen är dock att de ska vara lagom osynliga och att man aldrig får se dem som något primärt i applikationen man skapar. ds.

Hubs

Grupprelationer. Inte bara för människor -- för prylar på webbplatser också!

I "Structure and Flows" diskuterar Hagan Rivers konceptet hubbar. En hubb är en samling funktioner och/eller (länkar till) material. En hubb är Royal Quiz turneringslista. I hubben har vi samlat ett antal nuvarande och ett antal gamla turneringar. Dessutom finns en länk till alla gamla turneringar. (Navigationen etc är inte del av hubben.) När man genomfört en turnering är det naturligt att man återkommer till hubben för att prova en annan. Det är den cirkeln (hubb -> funktion -> hubb) som visar på att det är en hubb.

Hagan diskuterar ett flöde enligt ungefär följande:
1. Få en kravspec på funktioner (eller innehåll).
2. Identifiera hubbar, alltså funktioner som verkar vettiga ihop.
3. Användartesta.
4. Skapa design som stödjer hubbarnas funktion. Designfasen kan innebära att innehållet i hubbarna ändras.
...iterera 3 & 4 till dess att det är klart...

Jag tänker att hubbens ursprungliga innehåll kan ges större fokus än vad Hagans ger det.

En hubb är ju en samlign funktioner som ska lösa ett problem för användaren. Som ett exempel kan vi ta frågan "Vad är nytt på OrkidéPrat?" vilket är naturligt att fråga sig när man loggar in.

Svaret hittar man genom olika metoder -- fältstudier, användningsanalys etc -- och jag tycker just nu att 4 underfrågor är viktiga att besvara:
- Har jag fått några nya brev?
- Är några av mina favvo-medlemmar inloggade?
- Finns det några nya svar på mina favoritdiskussioner?
- Vilket nytt prat finns det?

Utifrån de 4 frågorna byggde jag om sidan OrkidéPrat-medlemmarna hamnar på när de loggar in.

Min process var alltså:
1. Hitta problemet.
2. Hitta funktioner som löser problemet.
3. Identifiera hubbar, alltså funktioner som verkar vettiga ihop. (Kan hända att man ska skapa flera hubbar utifrån problemet.)
4. Användartesta.
5. Skapa design som stödjer hubbarnas funktion. Designfasen kan innebära att innehållet i hubbarna ändras. (Ändringar känns dock mindre aktuella då problemet gyuidat processen från början).
...iterera 4 & 5 till dess att det är klart...

För mig är alltså en hubb:
Hubb: Problemet / Huvudfrågan
Funktion: Lösningen / Underfrågan / Svaret

Hubb-konceptet kan alltså användas inte bara för att skapa en arkitektur som funkar för innehållet utan även för att definiera innehållet självt.

Ingen hjälp här...

Jag vet inte om nätet kan hjälpa unga Vincent...