Jag har designat för att leva sedan 2009 och under de senaste tre åren har jag fokuserat på mina färdigheter på både webb och mobil användargränssnitt. Under denna tid har jag upplevt det bra och dåliga i branschen. Bra kunder, dåliga kunder. Bra idéer, dåliga idéer. Bra utvecklare, dåliga utvecklare. Det har varit appgodkännanden och appavvisningar.
Ibland kan det vara frustrerande, och även om dessa så kallade "dåliga erfarenheter"? kan suga, de har lärt mig några viktiga lektioner. Dessa lektioner snabbar inte bara mina dagliga arbetsflöden utan hjälper mig också att skapa en bättre användarupplevelse för målgruppen.
Lär känna kunden och deras behov
? Skapa en bra produkt och användarupplevelse är nummer ett för mig?Innan du startar ett projekt, skapa ett online-chatt / samtal eller ansikte mot ansikte möte med din klient. Det är bra att lära känna dem lite innan du tar på jobbet, eftersom personlighetsskador ibland orsakar problem. Om du delar gemensamma intressen så kommer chansen att bli bra!
Jag har varit i en situation med en klient där han var otroligt affärsmässig och hans främsta prioritet var att tjäna så mycket pengar som möjligt på kort tid. Även om det är viktigt att tjäna pengar är det viktigt att skapa en bra produkt och användarupplevelse som är nummer ett för mig (om produkten är bra och användarna älskar att använda den tror jag att pengarna kommer att rulla i så småningom!).
I det här fallet slutade vi bestämma oss för att inte fortsätta arbeta tillsammans eftersom jag ville ha mer tid att spendera på det arbete jag blev ombedd att göra, och hans prioritet var att starta produkten så snart som mänskligt möjligt.
En gång förbi scenen att lära känna varandra lite och upptäcka att du är en bra match är det viktigt att ta reda på så mycket som möjligt om appen. Jag brukar dela upp det i två delar; 'grundläggande info' och 'avancerad info'.
Jag får reda på den grundläggande informationen innan jag lär känna kunden. Det handlar om vad appen är för, vem den är för, och dess primära funktioner. Jag flyttar sedan på att få reda på den avancerade informationen. I det här steget möter jag med kunden och diskuterar arbetsflödet och skärmarna i detalj.
Mellan oss skapar vi en fullständig lista över skärmar som krävs för att appen ska fungera. Jag personligen gillar att använda ett Google Drive-kalkylblad som vi alla kan visa och redigera, och göra några kommentarer. Vi håller med och skriver ut att det här är den fullständiga uppsättningen funktioner och skärmar som krävs.
Varför gör allt detta?
Det finns ett par giltiga skäl bakom mig att göra detta. Den första är att det är en viktig tillgång vid upprättandet av wireframes och arbetsflöden. Den andra är att det kan spara din rygg från kunder som ökar ditt arbetsflöde genom att glida i extra skärmar och funktioner här och där.
Jag tog en gång ett relativt stort iOS- och Android-projekt med en nära vän av mig där vi bröt denna regel och - som vi ursprungligen citerade som cirka 320 timmar arbete - blev snart till nästan 500 timmars arbete. På grund av att klienten lägger till så många nya funktioner mitt iväg genom projektet, måste hela strukturen i appen ändras på både iOS och Android-plattformar.
Det började bli tråkigt, repetitivt, och vi förlorade vanligtvis mycket kärlek vi ursprungligen hade för projektet. Vi slutförde det, men inte utan att arbeta in på morgonen tidigt, få stressade, jongleringsprojekt och fördröja andra klientprojekt som vi hade lagt fram. Inte värt det när det kan lösas med en enkel lista över skärmar och funktioner.
Sätt dig i användarnas skor
Det sista jag gillar att göra innan jag börjar planera projektet är att sätta mig i användarnas skor. Ibland kan det vara en typ av användare, andra två eller ännu mer. Denna regel gäller alla mobila applikationer.
? Navigering runt appen måste vara enkelt och väldigt snabbt?Jag arbetade med en terrängkarta och GPS-igångsättning under andra halvåret 2011, och det var väldigt viktigt att sätta mig själv i en typisk användarens skor. Jag skulle ta en bit papper, skriva "användaren" i mitten och skriva ner allt som kommer att tänka på. Tre av de stora frågorna jag frågade mig var:
- Vad ska de använda appen för?
- Var ska de använda appen?
- Hur mycket tid måste de använda appen?
Självklart skulle användaren använda appen för navigering både vägar och terrängspår, de kommer att använda appen i bilen och till fots - ibland kommer det att vara i direkt solljus (därför är en mörk UI-probaby inte lämplig ).
Appen kommer att användas i god tid, men i vissa fall kommer användaren bara ha begränsade tider att interagera med appen (t.ex. vid röda lampor), så att navigera runt i appen måste vara enkelt och mycket snabbt.
Jag skulle tillbringa en bra timme "i användarnas skor", det hjälper mig verkligen att se hur appen ska fungera och hur det kan se ut.
Planera förut för att undvika misstag senare
Planera ditt projekt är där den lista över skärmar och funktioner som vi nämnde i lektion en blir en viktig tillgång. När listan över skärmar och funktioner har skrivits av är det dags att starta trådframställning.
När jag först började fokusera mina färdigheter på design av mobilgränssnitt brukade jag hoppa över wireframing när jag såg en möjlighet till. Jag hittade det en chore för de flesta projekt men så småningom min lathet återfödde. Jag tog på ett projekt för ett litet iOS-applikationsprogram, klienten och jag bestämde mig för att spendera en halv dag och skisserade några enkla trådramar eftersom vi hade en ganska tydlig bild i vårt huvud för hur vi ville att det skulle fungera.
Vi flyttade framåt och innan du visste det körde vi in i små arbetsflödesproblem, inget stort, små saker som hur en användare kommer hit därifrån, hur tar de bort det utan att gå igenom många steg för att komma dit osv. Etc.Innan du vet det, spenderade vi en timma här och en timme där de här problemen fastställdes, vilket lätt kunde undvikas genom att spendera den halva dagen på att sätta ihop ett enkelt arbetsflöde och en uppsättning trådramar.
Det här är inte att säga att du måste spendera dagar eller veckor på att planera dina projekt (speciellt för mindre verktyg) men det är definitivt värt att lägga penna på papper och skribra några idéer för de viktigaste skärmarna och sedan hänvisa till din fullständig lista över skärmar och funktioner för dem du inte känner att du behöver skissera.
Jag gör det hela tiden, före och under ett projekt, så mycket att jag faktiskt lanserade Dotgrid.co för att uppmuntra andra att köpa prickböcker och skissa mer! För större projekt (speciellt tjänster) ställer jag alltid bort en stor del av projekttiden till trådframställning och annan planering. Det lönar sig alltid.
Det kan vara värt att använda en tjänst för att göra din wireframes till en fungerande prototyp (jag gillar Invision App). För stora projekt tycker jag att det här hjälper dig att upptäcka misstag eller möjliga problem innan du dyker för djupt in i projektet.
Håll dig till operativsystemets riktlinjer
Att hålla sig till användarens riktlinjer är viktigt. Det är fantastiskt att experimentera med nya navigationssystem, interaktioner och beröringsbevakningar, och jag uppmanar dig att göra det, men du kommer att bli tvungen att lösa problem igen och igen, oavsett om det är din utvecklare som har svårt att genomföra designidén eller Apples granskare är picky och avvisar din app.
För att få en bra bild av vad som är möjligt gör lite forskning på appar på marknaden och se till att du läser igenom riktlinjerna.
Det kan vara skillnaden mellan att en app godkänns eller att en app avvisas och sedan måste spendera mycket mer tid om omformning av olika element.
En annan bra anledning till att följa riktlinjer är att det låter användarna snabbt vänja sig på din app tack vare alla appar som följer samma riktlinjer. Till exempel finns bakåtknapparna längst upp till vänster. Flikstängerna ligger längst ner på skärmen. Omkopplare gör samma sak i alla appar. Listan fortsätter!
Praktiska länkar
- IOS Human Interface Guidelines
- Användargränssnitt för Android
- Riktlinjer för Windows Mobile Design
- Blackberry User Interface Guidelines
Det lönar sig att hålla saker enkelt
När jag berättar för kunder vill jag göra det? de missförstår mig ofta och tror att jag menar att jag ska designa gränssnittet i en minimalistisk designstil. Detta är inte meningen med ordet!
Enkelt innebär att en första användare kan öppna appen och börja använda den utan att behöva läsa igenom riktningar eller följa en guide.
Det betyder att de kan slutföra enkla uppgifter i mycket få steg, eller i situationer där fler steg krävs, är det fortfarande enkelt. Det betyder att färger används effektivt (rött för att ta bort knappar är ett vanligt exempel). Att hålla saker så enkla som möjligt kan utan att komplicera dem utan anledning, uppmuntrar inte bara användare att ladda ner en app i första hand, men också att de kommer tillbaka.
Varför skulle de använda en applikation som är förvirrande och knepig att komma runt när det är förmodligen ett alternativ som är enkelt och till den punkten?
Jag arbetade med en klient på en enkel GPS-app som spårar hur långt användaren har rest, sin genomsnittliga hastighet, toppfart och höjd. Appen fortsatte att spela in data tills användaren återställde den. För att återställa det valde vi för ett roligt "skaka att återställa" -alternativet, vilket tydligt illustrerades med en ikon och motsvarande text som läste något i linje med "Shake to reset stats".
Inom några dagar efter att vi lanserade appen fick vi flera användare att kontakta oss och fråga hur du återställer statistiken som spelats in, och vi lade snabbt till en röd knapp som läste 'Återställ statistik' i appen så att de kunde göra det på ett enkelt sätt. Det lönar sig att hålla saker enkelt!