A makettben lévő gombok általában egy állapotot mutatnak: az alapértelmezettet. A valódi termékben ugyanaz a gomb lebeg, a billentyűzettel fókuszálva, lenyomva, letiltva, amíg egy űrlap hiányos, és betöltődik, miközben egy kérés elküldésre kerül. Ezek mindegyike UI állapot, és mindegyikhez tervezésre van szükség.
Segít a két csoport elkülönítésében. Az interakciós állapotok a felhasználótól származnak: lebeg, fókusz, lenyomva és letiltva. Az adatállapotok a rendszerből származnak: betöltés, üres, részleges adat, hiba és siker. Például egy listaképernyőnek szüksége van egy tervezésre, amikor betöltődik, amikor nincsenek elemek, amikor egy elem van, amikor több száz van, és amikor a kérés sikertelen.
A fókuszállapotok külön figyelmet érdemelnek. A billentyűzetet vagy kapcsolóeszközt használó emberek egy látható fókuszjelzőtől függenek, hogy tudják, hol vannak. A böngésző fókuszvonalának csere nélküli eltávolítása az egyik leggyakoribb akadálymentesítési hiba.
Az állapotok közötti változás is a tervezés része. Egy rövid, egyértelmű átmenet az alapértelmezettről a nyomottra erősíti meg a csapot. A zökkenőmentesen sikerré váló terhelési állapot azt mondja az embereknek, hogy cselekedeteik működtek. A hirtelen ugrások vagy a túl lassú animáció megbízhatatlanná teszi a felületet.
A hiányzó állapotok elkerülésének gyakorlati módja, ha tervezés előtt minden komponenshez listázzuk, vagy állapotgépként modellezzük: állapotok és a közöttük mozgó események halmazát. Az általunk készített ExodeUI így működik. Az egyes állapotokat és a köztük lévő átmeneteket egy fájlban tervezi meg, és a kódja elküldi az eseményeket, amelyek a valódi alkalmazásban állapotot váltanak.