Byggeklossdesign: en modulær designstrategi for UXere

En artikkel som hjelper til med å fylle ut hullene i modulære designmodeller fra et UX-perspektiv.

Jeg begynner med en historie

Hvis du hater historier, bør du hoppe over denne delen. Det handler om en UX-designer som fikk i oppgave å forkjempe en modulær designstrategi for organisasjonen sin. Hun har kort brunt hår og blå øyne. Hvis du ikke har gjettet nå, er UX-designeren meg.

For rundt åtte måneder siden møtte teamet vårt en modulær designstrategi kalt objektorientert UX (OOUX). I motsetning til andre bredt feiende modulbaserte systemer, ber OOUX deg om å fokusere på å modulisere kjerneinnholdstyper - det OOUX kaller objekter - og ta en hard titt på hvordan disse objektene forholder seg til hverandre. Denne prosessen hjelper designteamet med å avsløre iboende forekomster av kontekstuell navigasjon og skyve mot konsistente brukergrensesnittmoduler.

Vel, det er flott for å designe informasjonsarkitekturer og mønsterbiblioteker, men hva med å designe opplevelser. Tross alt er det å mobilisere innholdet ditt bare halve slaget. Hvis du kommer til å være i frontlinjen til UX, må du spørre hvorfor og hvordan.

Hvorfor og hvordan

Du sier kanskje til deg selv: "ikke fortell meg om hvorfor og hvordan! Jeg er en UX-forsker, dabb nabbit! Jeg spiser hvorfor og hvordan til frokost. ”Så la meg forklare.

Jeg snakker ikke om strategi på funksjonsnivå. Jeg snakker ikke om prosessstrømmer, wireframes og prototyper. Jeg snakker om strategi på applikasjonsnivå. Du vet, det vi alltid skal gjøre, men på en eller annen måte aldri har tid til? Og jeg snakker om å gjøre det til en integrert del av vår tilnærming til våre andre strategier, som modulær design.

For å gi deg litt mer kontekst, la oss snakke gjennom et eksempel. La oss si at vi designer en dating-app der en av de viktigste innholdsdelene er en profil. Med modulær design vil vi spørre: "hvor kan dette innholdet dukke opp i brukergrensesnittet?" - og basert på svaret vårt, ville vi utforme moduler for hvert av disse scenariene. Kanskje vi designer en profil som kan vises i en liste eller en profil som tar opp hele skjermen. Informasjonsarkitektur. Mønstre. Sjekk, sjekk.

En

Men nå som vi har bestemt oss for hva, hva som skjer når vi uunngåelig innser at vi trenger å tenke på hvorfor noen vil se en bestemt profil i utgangspunktet? Og hvordan den profilen ville se ut for den personen? Implementerer vi disse strategiene etter det faktum og håper at ingenting går i stykker?

Jeg håper du rister på hodet der ute, fordi svaret er et rungende nei.

I stedet for å hoppe først med å utforme modulene våre, bør vi bygge et strategisk rammeverk som kan hjelpe oss med å drive designarbeidet fra alle vinkler. I stedet for å definere ansiktet til innholdet vårt - tingene som vises i brukergrensesnittet - bør vi begynne med å definere hvordan og hvorfor det støtter dette innholdet. Dette kalles byggesteinsdesign.

Gå inn i byggesteinsdesign

I stedet for å be deg om å tenke over innholdet i modulene dine først, som andre modeller, ber byggesteindesign deg om å fokusere i stedet på strategien bak innholdet.

I byggeklossdesign, la strategi gi rammene for design; ikke omvendt.

Først etter at du har definert de viktigste UX-strategiene dine - rammen som holder innholdet ditt oppe - kan du begynne å designe hvordan innholdet vil bli representert i grensesnittet. "Det store bildet" -strategien for hvert stykke kjerneinnhold er din byggestein. Sammen definerer byggesteinene UX for produktet ditt.

Byggeklossdesign er modulær design for UXere.

Byggestein anatomi

For å forstå denne tilnærmingen til å skape meningsfylt, strukturert innhold, la oss gå tilbake til dateringsappen-eksemplet. Nå som jeg har identifisert et stykke kjerneinnhold i applikasjonen min - en profil - er det på tide å gå gjennom og identifisere hvilke strategier som potensielt kan påvirke hvordan denne blokken er designet. Ved å utforske forholdet mellom andre strategiske initiativer og innholdet vårt, er vi i stand til å tenke mer kritisk på hvordan vi nærmer oss utformingen og leveringen av denne informasjonen.

Anatomien til profilblokken begynner å ta form.

Når du utforsker forholdet mellom strategier på applikasjonsnivå, er det best å starte på et høyt nivå og jobbe deg ned. Hvis jeg for eksempel identifiserte personas som en hovedkomponent i strategien min, kan jeg bryte denne strategien ytterligere ved å identifisere:

  • de spesifikke personasene som bruker profiler;
  • hvor i appen de samhandler med dette innholdet;
  • deres kontekst av bruk;
  • kjernehandlingene de tar på profiler;
  • og hvor ofte de får tilgang til dette innholdet.

Det kan se slik ut:

Person-profil-forholdet gir mer kontekst for hvordan ansiktet til profilblokken min ser ut og føles.

Når jeg har gitt litt mer sammenheng med hvorfor dette innholdet er verdifullt for en bestemt type brukere, kan jeg begynne å tenke mer kritisk på hvilke handlinger som må prioriteres, hvordan modulen skal struktureres for å fremme personspesifikke atferdsmønstre, og hvor i opplevelsen dette innholdet må leveres.

Denne teknikken lar designere fokusere på de tingene som betyr noe og ikke bli fanget opp i visuell appell, interaksjonsforførelse og andre grensesnittdesignmønstre som ser bra ut, men ikke støtter faktisk brukeratferd.

Hvis jeg gjentar denne øvelsen i form av et andre strategisk initiativ, vil du få ytterligere innsikt. Avhengig av antall og kompleksitet av strategiske initiativer du har på plass, kan dette raskt bli en tidskrevende prosess. Jeg anbefaler å starte med ikke mer enn to strategier.

Så der har du det. Et eksempel på hvordan du kan bli føttene våte med konstruksjon av byggesteiner. Hvis du tror at dette vil være en nyttig øvelse for designteamet ditt, kan du sjekke hurtigveiledningen nedenfor for flere tips. Og selvfølgelig vil jeg gjerne høre tankene dine om alle ting modulert. Legg til kommentarene dine nedenfor, eller nå ut på LinkedIn.

Hurtigstartveiledning

Jeg har funnet ut at mange modulære designmodeller der ute faller på å gi leserne handlingsdyktige doser, så la meg gjøre et poeng av å gi den verdifulle informasjonen:

Trinn 1: Strategi inventar.

Vi lager innhold og komponentbeholdninger, så hvorfor ikke et strategiinventar? Lag en liste over alle applikasjonsstrategiene du har på plass. Eksempler inkluderer: Personas, data, kontekst av bruk og menneskelig miljødesign, lydhørhet, etc. Dette er en god mulighet til å ta pause og spørre "har vi en solid strategi på plass for applikasjonen vår?" Hvis svaret er nei, er det på tide å komme på jobb.

Gjør slik: Rally teammedlemmer for å uavhengig lage egne strategiinventar.

Trinn 2: Definer ditt kjerneinnhold.

Dette er ting brukerne dine tar handlinger i applikasjonen din. For å finne ut av dette, kan du stoppe litt tid for en idédugnad med teamet ditt. Still deg spørsmål som: “hva søker brukerne mine etter? Utsikt? Last ned? ”Når du har identifisert et stykke kjerneinnhold, skriver du det på et papir og henger det på en vegg.

Gjør du det: Hold en første idédugnad sammen med teamet ditt.

Trinn 3: Definer hvordan og hvorfor.

Nå som du har identifisert applikasjonsstrategier og kjerneinnhold, er det på tide å samle de to! Gå tilbake til brainstormingsrommet ditt for et oppfølgingsmøte, og sørg for at teamet ditt tar med seg strategiinventar. For din del av prosessen, la teamet ditt plassere strategipapirer etter ethvert kjerneinnhold der strategien kan ha innvirkning.

Gjør du: Hold en oppfølging av idédugnad med teamet ditt.

Trinn 4: Anatomien til en byggestein.

Det er på tide å dele og erobre. Tildel teammedlemmer en håndfull kjerneinnholdstyper - eller byggesteiner - og få dem til å repetere anatomien til dette innholdet.

Gjør du: Tilordne hvert teammedlem med flere innholdstyper. Det teammedlemmet bør definere anatomien til innholdet.

Trinn 5: Juster, juster, juster

Som et siste skritt, få gjengen sammen igjen i form av en lavmælt presentasjon der hvert teammedlem presenterer anatomien til byggesteinene sine. Spar tid på slutten for spørsmål, justering og beslutninger om neste trinn for å drive de individuelle strategiske komponentene i hver byggestein.

Gjør slik: Planlegg et tidspunkt for teammedlemmer å presentere deres byggesteinanatomi.

Denne artikkelen er brakt til deg av RUXERS. RUXERS er et fellesskap av ekte brukeropplevelsesledere som deler og diskuterer det siste innen design, brukeropplevelse, brukervennlighet og forskning. Vi er på Twitter - bli med!