Sådan designes UI-stater og kommunikerer med udviklere ved hjælp af FSM-tabel

Kinesisk version (中文 版 連結)

Læs indlægget på vinceshao.com

Livet kan undertiden være hårdt for UI-designere. Mens de får at skabe fantastiske designs, får de også at gøre med presset fra klienter eller premierminister. De skal overveje brugeroplevelse og brugerflow. Og de kæmper ofte for at finde en effektiv måde at kommunikere med udviklere på.

For at lindre noget af presset fra mine kolleger, vil jeg hjælpe ved at introducere en bedre måde at håndtere UI-komponenter med tilstandsvariationer. Jeg tror, ​​dette er en af ​​de største udfordringer, som designere står overfor.

Håndtering af tilstandsvariationer af UI-komponenter er smertefuldt. Først troede jeg, at det var så svært, fordi du er nødt til at skabe forskellige synspunkter, hvilket kan være kedeligt. Men så indså jeg, at design ikke er den skræmmende del. Snarere mangler stater og fortæller udviklerne nøjagtigt, hvad du vil have. Så denne artikel vil behandle disse to problemer.

Stat og flowchart

For at forhindre designteamet i at undlade at forberede de nødvendige tilstande, er disse fem stater blevet foreslået som normen for designere at følge. Men for nøjagtighedens skyld vil jeg først påpege forskellen mellem en tilstand og en matchende visning.

Tilstand er faktisk output fra en UI-komponent efter modtagelse af en input. En tilstand har muligvis eller ikke brug for en matchende visning for at interagere med brugerne.

Derfor kan en UI-komponent kun have fem tilstande, men hver stat kan faktisk have forskellige versioner af visningerne. Forvirret? Lad os se på et dagligdags eksempel på en indsende-knap, og jeg tror, ​​du får fat i det med det samme.

En indsenderknap inkluderer normalt tilstand, standard, indlæsning, succes og fejl, og hver stat kan have forskellige visninger

Men hvordan ved vi, at der er tre andre stater udover den oprindelige? Og hvordan skifter disse tilstande mellem hinanden? Det er lettere at forstå dette spørgsmål ved at se på et flowdiagram.

Flowchart er ikke nok til at fortælle designdetaljer

Den metode, der hjælper os med at styre UI-tilstande, er afgørende. Det skal formidle beskeden om, hvilken tilstand komponenten skal skifte til efter modtagelse af visse input. Men selvom dette flowchart i de fleste tilfælde er et kraftfuldt værktøj, er det ikke ideelt til detaljerede tilstandsvariationer på grund af disse ulemper:

  1. Ulejlighed. Det kræver hjælp fra software eller plugins (bortset fra klassisk kontor- eller designsoftware) for at tegne, ændre eller vedligeholde diagrammet. Og det er enormt.
  2. Var upræcis. Det er svært at se, hvilke stater der kræver en visning, og hvilke indgange der skifter tilstande.
  3. Kompleksitet. Det kræver ekstra opmærksomhed, når du vælger korrekte symboler og farver.

For at opsummere er det ineffektivt og unøjagtigt at administrere tilstande for UI-komponenter ved hjælp af et flowdiagram. Jeg tror de fleste designere ville være enige. Så jeg vil nu foreslå en bedre måde her.

Finite State Machine (FSM) tabel

FSM-bord inspireret af Krasimirs FSM-introduktion

Designere, bliver ikke narret af det teknisk-klingende navn! Lad mig nedbryde det.

Hvad er Finite State Machine?

Finite state machine (FSM) er en abstrakt maskine, der organiserer alle mulige tilstande og input. Denne metode anvendes ofte til programmering og alle slags enheder. Se på det finite state-maskineeksempel på en turnstile illustreret på Wikipedia, så har du en bedre idé med det samme.

Igen, FSM er kun en samling af stater og input. Det er så enkelt. Lad os tage et dybere kig på brugen af ​​denne tabel og opleve kraften i den.

Sådan bruges FSM-tabellen

Der er tre kolonner i tabellen: Fra tilstand, input og til tilstand.

I kolonnen Fra tilstand repræsenterer hver celle en mulig tilstand, som komponenten kan have.

Input-kolonnen indeholder de vigtigste oplysninger i tabellen: hvilke begrænsede handlinger der kan udføres eller input, der skal modtages i hver tilstand.

Endelig er kolonnen Til tilstand faktisk outputtilstanden i henhold til den tilsvarende input.

Hvorfor er det bedre?

Tabellen viser klart tre ting:

  • alle de mulige stater
  • når hver handling kan afsluttes
  • resultatet af gennemførelse af en bestemt handling

Når jeg sammenligner dette med flowchart, tekstnotater eller interaktiv prototype, tror jeg, de fleste udviklere ville være glade for at modtage denne tabel. Det dækker næsten al den information, en udvikler har brug for!

Udover at sænke kommunikationsomkostningerne, opfordrer FSM-tabellen også til et tankesæt. Det hjælper med at opbygge en klar forbindelse mellem årsag og virkning og forhindrer dig i at tage beslutninger uden understøttelse af lydlogik.

Bedre teamkommunikation

Lad os nu overveje et mere praktisk og kompliceret eksempel efter denne korte introduktion til FSM-tabellen, så vi virkelig kan se kraften i det. Lad os se på en login-side.

Flowchart og wireframe for godkendelsesside

Siden indeholder en overskrift, en hovedoverskrift, en formulargruppe med to inputfelter og en indsendelsesknap. For at få et overblik over godkendelsesfunktioner har vi stadig brug for et klart flowchart. Men det kan ikke udtrykke de detaljerede variationer af komponenterne på grund af ulemperne nævnt ovenfor.

Hvis en bruger f.eks. Klikker på knappen Send og valideringen mislykkes, får vi en fejlmeddelelse - og vi får disse oplysninger fra flowdiagrammet. Men hvad med specifikke inputvalideringsmeddelelser, når brugeren prøver at fokusere, sløre eller klikke mod hvert inputfelt? Hvornår skal inputvalideringsfunktionen begynde? Bør indsendelsesknappen være låst, indtil brugerens input i formularen er valideret?

Der er mange betingelser at overveje

Dette er alle detaljerede beslutninger, der kan have indflydelse på brugeroplevelsen, og de bør ikke ignoreres. Men hvordan kan du som designer fortælle udvikleren nøjagtigt, hvad du tænker? Interaktive prototyper, lister med noter og møde ansigt til ansigt kan alle være ineffektive.

Men ved at forberede et FSM-bord bliver tingene øjeblikkeligt krystalklare. Du kan endda forberede adskillige versioner hurtigt efter forskellige brugeroplevelsesproblemer.

Hvis du ønsker, at sendeknappen skal deaktiveres, før alle inputfelter er korrekt udfyldt, ser tabellen sådan ud:

Autentificer form FSM - version deaktiveret

Eller hvis du følger Googles guide til materialedesign, ser tabellen sådan ud:

Godkend form FSM - version Materialedesign

Er det ikke så let, hurtigt og klart? Jeg tror, ​​det er meget bedre end andre metoder!

Desuden kan en FSM-tabel tage sig af komponenter, der heller ikke er relateret til databehandling. Sig, at designeren ønsker, at header skal opføre sig som dette smukke sted. FSM-tabellen kan hjælpe med at give tærskler og synspunkter for hver stat.

Header FSM-tabel

Det er det! Tillykke med at udfylde et enkelt, men alligevel forståeligt dokument til din godkendelsesside ved at kombinere en wireframe, flowchart og FSM-tabel!

En sidste note

I en stor virksomhed med specialiserede teams, der samarbejder tæt om ét produkt, er designere måske ikke påkrævet at tænke over statslige styringsproblemer. Jeg har bare aldrig været en del af denne slags hold før. Generelt tror jeg, at de fleste UI-designere stadig har brug for at kommunikere med udviklere, ledere eller andre designere om statens overgang i deres karriere.

Jeg håber inderligt, at FSM-tabellen hjælper designere med at reducere dyrebare tidsressourcer til at håndtere kommunikationshindringer og endda hjælper dem med at opdage en ny måde at tænke på.

Endelig, så lad mig det vide, hvis du har nogen tanker om dette!