En knapp i en mockup viser vanligvis én tilstand: standard. I det virkelige produktet er den samme knappen svevet, fokusert med et tastatur, trykket ned, deaktivert mens et skjema er ufullstendig, og laster mens en forespørsel sendes. Hver av disse er en UI-tilstand, og hver av dem trenger et design.
Det hjelper å skille to grupper. Interaksjonstilstander kommer fra brukeren: sveve, fokus, trykket og deaktivert. Datatilstander kommer fra systemet: lasting, tom, delvis data, feil og suksess. En listeskjerm trenger for eksempel et design for når den lastes, når den ikke har noen elementer, når den har ett element, når den har hundrevis og når forespørselen mislykkes.
Fokustilstander fortjener spesiell oppmerksomhet. Folk som bruker et tastatur eller bytter enhet er avhengig av en synlig fokusindikator for å vite hvor de er. Å fjerne nettleserens fokusomriss uten en erstatning er en av de vanligste tilgjengelighetsfeilene.
Endringen mellom stater er også en del av designet. En kort, tydelig overgang fra standard til trykket bekrefter trykket. En lastetilstand som jevnt blir til suksess forteller folk at handlingen deres fungerte. Brå hopp, eller animasjon som er for sakte, gjør at grensesnittet føles upålitelig.
En praktisk måte å unngå manglende tilstander på er å liste dem for hver komponent før design, eller å modellere komponenten som en tilstandsmaskin: et sett med tilstander og hendelsene som beveger seg mellom dem. ExodeUI, som vi lager, fungerer på denne måten. Du designer hver tilstand og overgangene mellom dem i én fil, og koden din sender hendelsene som bytter tilstand i den virkelige appen.