Hur man slår "Paradox of Choice" i UI-design
"Mindre är mer" är en av de viktigaste minimalistiska designprinciperna som varje designer lär sig: du läser mycket om det, du vet att det är väldigt viktigt, men du kan fortfarande få fel. Det viktiga är att komma omkring, lära av det och utvecklas. Och så gjorde vi det.
Med utgåvan av Todoist Next i januari i år introducerade vi en ny design tillsammans med nya funktioner. Från början var vårt fokus att modernisera appen och förbättra användarupplevelsen över hela linjen. Att skjuta upp uppgifter var en av de saker vi framförallt ville förbättra. Men det var inte så lätt som vi förväntade oss ...
Ut med den gamla
Den tidigare versionen av vår app hade bara två alternativ när det gällde att omplanera uppgifter. Antingen valde du "Gör det idag" eller "Utsätt" (det kan vara antingen imorgon eller nästa händelse för återkommande uppgifter). När du behövde lite mer kontroll behövde du använda hela kalendern eller skriva in ett nytt datum. På webben och skrivbordsklienter är det väldigt enkelt att skriva in ett nytt datum och tid, eftersom du har det fysiska tangentbordet och musen. Men på mobilen var erfarenheten lite bruten. Du kan skriva in ett nytt datum men det var inte särskilt bekvämt, särskilt när du är i "ett ögonlopp och ett tumme" -läge.
In med den nya
Eftersom det gamla systemet var så begränsat ville vi verkligen ge våra användare fler alternativ och göra det mycket mer visuellt så att det skulle vara mer flexibelt och lättare att använda på mobila enheter, men också bra på andra plattformar. Vid det exakta ögonblicket var valet mer.
Eftersom vi ville göra en bra mobilupplevelse, använde vi mobilens första tillvägagångssätt i utvecklingen: om det fungerar på mobil, är det lättare att få det att fungera på skrivbordet där du har mer skärmutrymme och mer exakta inmatningsmetoder.
Med detta i åtanke började vi utforska hur det skulle fungera och vilken riktning skulle mest hjälpa våra användare. Vi undersökte andra lösningar som försökte ta upp liknande problem själva, men vi kände att de flesta var begränsade och att vi kunde förbättra dem, även om några av dem är riktigt bra lösningar.
En "smart" schemaläggare var vår stora idé. Ett smart system som skulle titta på dina uppgifter och skulle föreslå de bästa datumen magiskt. När du till exempel omfördelar en uppgift för nästa vecka, ser systemet ut på dina nuvarande uppgifter och väljer en dag i nästa vecka utan förfallna uppgifter. Och det skulle vara fantastiskt! För användaren skulle det vara en brainer, med ett riktigt fint gränssnitt som drivs av en stark algoritm för att hämta de bästa datumen. För laget skulle det vara en stor prestation som blandade ett fantastiskt gränssnitt med en solid kodning till en solid produkt.
Tidiga utvecklingsstadier: från cirkulära menyer till riktigt komplexa uppsättningar alternativ med datumförslag markerade på kalendern och ytterligare feedback på kranen.
Allting föll på plats med den första utvecklingen, och de första mockupsna såg lovande ut. Vi började till och med komma med nya idéer om hur man gör det ännu mer kraftfullt. Vi lade till en första grupp av val (idag, imorgon, nästa vecka, en dag), ett klassiskt kalendervyn alternativ och "datumförslag" som skulle ge all magi till skärmen. Vi försökte olika layouter, till och med en cirkulär meny, och iterated snabbt på alternativområdet (mellan 6 till 9 alternativ på skärmen åt gången).
Snart började vi tänka på hur man skär interaktionssteg, hur man ökar valmöjligheterna och reducerar kranarna. Ett av alternativen skulle visa den klassiska kalendern, men det verkade som en onödig extra kran, eftersom vi kunde passa allt i samma skärm. Och så testade vi. Och testad.
Uh-oh-ögonblicket
Ett av de första problemen vi upptäckte med "magiken" var bristen på feedback på datumen. Om användaren valde nästa vecka lade systemet till datumet men användaren hade inget uttalande om det. Även om det var en ledig dag, kanske du ville ha uppgiften planerad för en annan dag. Vi behövde ett extra steg för att visa det datum som användaren kunde bekräfta.
Ett annat problem blev uppenbart: vi hade inte tillräckligt med information om användarna att verkligen göra de bästa möjliga förslagen. Att göra det skulle troligen ha krävt mycket input från användaren eller, verkligen, spionera på allt de gör. Ovanpå allt blev kodningen av ett sådant system väldigt komplicerat.
Dessutom blev gränssnittet riktigt rörigt med många val, och för många kranar krävdes vissa enkla val. Vid denna tidpunkt hade vi kommit fram till en "paradox av val" - en term som myntade av Barry Schwartz -Vi hade så många alternativ som faktiskt att välja en var en skrämmande uppgift i sig.
Den första lösningen vi började med var en algoritmisk lösning som skulle göra beräkningar för dig. Idén är smart på papper, men en mardröm att genomföra eftersom vi inte har tillräckligt med information för att göra det verkligen smart. - Todoist grundare, Amir Salihefendic.
Med den dyrbara hjälpen från Khoi Vinh (fantastisk designer och UX-guru) började vi inse att vi inte lyckades nå vårt mål om förenkling, vi gjorde appen mer komplicerad.
Slutligen övervinna Paradox of Choice
När du utvecklar en app, är det oftast din fantasi gränsen. Det betyder att det är lätt att gå helt överbord. Vi överdriver föll i denna fälla. Därifrån behövde vi ta ett steg tillbaka och ompröva hela systemet.
Vi förespråkar starkt enkelhet i användargränssnitt, så vår nya visuella schemaläggare kunde inte vara komplicerad. Här började vi med att använda en av Sheena Iyengars Principer från "Konsten att välja": klippa. Alternativet var begränsat och datumförslaget togs bort helt och hållet.
Även om Android och iOS-versioner fungerar på samma sätt, anpassades användargränssnittet för att bättre passa varje plattform. Även om det är den slutliga layouten, ändras inställningarna fortfarande före utgåvan.
Layouten var också förenklad. Den slutliga lösningen är ett alternativ på 3 × 2, med tillgång till en fullständig kalender som en av alternativen, så det är lätt att veta vad som ska förväntas när som helst. Några av de andra lösningarna kan ha varit bra val, men efter testning var det svårare att använda och krävde en brantare inlärningskurva. Ibland är det bara bättre att hålla det enkelt.
Det fanns mycket arbete med att utveckla systemet och i slutändan bestämde vi oss för en lättförståelig grupp av val. Allt detta för att erbjuda en bra användarupplevelse som faktiskt hjälper användaren att fatta beslut om förfallodatum och slutligen få saker att göra.