En knapp i en mockup visar vanligtvis ett tillstånd: standard. I den verkliga produkten svävar samma knapp, fokuseras med ett tangentbord, trycks ned, inaktiveras medan ett formulär är ofullständigt och laddas medan en förfrågan skickas. Var och en av dessa är ett UI-tillstånd, och var och en behöver en design.
Det hjälper att separera två grupper. Interaktionstillstånd kommer från användaren: hovra, fokusera, nedtryckt och inaktiverad. Datatillstånd kommer från systemet: lastning, tom, partiell data, fel och framgång. En listskärm behöver till exempel en design för när den laddas, när den inte har några objekt, när den har ett objekt, när den har hundratals och när begäran misslyckas.
Fokustillstånd förtjänar särskild uppmärksamhet. Människor som använder ett tangentbord eller byter enhet är beroende av en synlig fokusindikator för att veta var de är. Att ta bort webbläsarens fokuskontur utan en ersättning är ett av de vanligaste tillgänglighetsfelen.
Bytet mellan stater är också en del av designen. En kort, tydlig övergång från standard till nedtryckt bekräftar tryckningen. Ett laddningstillstånd som smidigt förvandlas till framgång berättar för människor att deras åtgärd fungerade. Plötsliga hopp, eller animering som är för långsam, gör att gränssnittet känns opålitligt.
Ett praktiskt sätt att undvika saknade tillstånd är att lista dem för varje komponent innan designen, eller att modellera komponenten som en tillståndsmaskin: en uppsättning tillstånd och händelserna som rör sig mellan dem. ExodeUI, som vi gör, fungerar på detta sätt. Du designar varje tillstånd och övergångarna mellan dem i en fil, och din kod skickar händelserna som byter tillstånd i den verkliga appen.