Category archives for "ux"

UX of the Honda CR-V 2nd gen

We have an old family Honda SUV (which is now clean as new by the way). At some point the remote control of the car stopped opening the rear door, but I didn’t care, we can still open it up with the keys. The process for opening the door was so weird, I thought it warranted for a UX blog post. 😀 Here is the lock:

The question: how do you open and close the rear door with the key? I wanted to post this question on Twitter, but then I realized it’s not how real life works. In real life you don’t UX-analyze things. You go to the rear door with a screaming girl in one hand, a melting chocolate bar in the other, and there is even a TV remote sticking out of your back pocket. How did the remote end up in your back pocket? Who knows! The only thing you want is to put SOMETHING into SOMEWHERE then expect the result to happen. You don’t have the time or leisure to look at things.

I didn’t even see the dots! This is exactly how I, as a user of this interface, went about it: I inserted the key into the lock and turned it left, then I was expecting the door to either open OR close depending on the previous state it was in.

And I did that exactly. The door opened, and when I was out in the city (in an even more complicated child situation) wanting to close the door, I put the keys in, I turned the same direction and the rear door was still open. I tried turning the other way around, then the back window opened. I retried the whole thing a couple of times, then I labeled the issue as something that a car electrician needs to fix. I even took the car to the expert who almost started to tear the whole lock down when it dawned on me.

[cue in cloud explanatory music from Captain Disillusion]

If you’re sitting in a comfy chair sipping precious liquids of your choice while looking at this photo, you can immediately see three dots as markers. Maybe they indicate something. At first I thought there is two information hidden in here and this is the grouping:

You can do one thing by turning the key to the left and you can do another by turning the key to the right. I figured if I turned my keys to the left, I opened the rear door. If I turned my keys to the right, I opened the window, right? In reality this is the grouping:

The solution: red – open, blue – open window, yellow – close. You need to feel how far you can turn that key until it closes. Turn it a bit more and you pop the window open. You need to learn all of this.

Did the designers of Honda make a horrendous mistake? I honestly don’t know. How would you have solved this design challenge? You have a lock and a key, but you need to operate three things with it.

First of all, it was my sole assumption that by turning the key to the left it reversed the previous state it was in. I don’t know why. Maybe it’s not even a good thing because then you need to manually check, by pulling the lever, if the door is really closed. I don’t mind that, but maybe you do.

I have a quick fix for the whole mechanism though: let’s leave everything as is for now, but switch the the yellow and blue dots. You rarely open the back window, but you do want to close the door frequently. This way if you need to open the window, you need to turn it halfway. All you need to learn is: left – open, right – close, in between – window.

But here is the thing: I don’t want to learn. I want to use. I see a keyhole, I want to put my key inside and I’m expecting the mechanism to either lock or unlock and maybe give me a feedback about it. A short chime perhaps?

Maintaining colors in your Google documents

Let’s pick a color:

Not very useful, because later on I will never know what particular shade of gray did I use in my document from this very picker. There had been a number of occasions where I’d try to guesswork the color I’d used, since I want my document to be consistent.

I like the rich palette in general, but what if it had a section that read: “Colors in your document” and it’d populate automatically. You can get to a similar behaviour by using the “Custom” colors for this, but it’s just exactly one step more than what most people want and you can’t set default colors as custom colors (more on this later). Most people want to 1) select some colors for their document 2) next time they’re there, see their used colors in the document.

How do I know this? Because of all the years I’d been using Google Docs, there was never a single occasion where I’d define a custom color or saw someone else do it. Never. Even though I’d spent countless of minutes wasted on trying to find the color I’d used for highlights, it has never occured to me to define colors for a document. For two reasons: first, I’m not exclusively using GDocs. I’m using different software and different software tend to have different solutions for this. Second, when you’re doing actual work, you just can’t be bothered with defining custom colors.

One more thing: if you define a custom color in GDocs, make sure you actually are using a different color from the base palette, because if you tried to set a custom color of the base palette it will not get defined. Good luck with finding your used gray.

53’s Paper app for the iPhone

John Paul Titlow, Fast Company:

Ian Curry, a visual designer at FiftyThree, blurted out: “Why don’t we visually format the text?” After some back and forth, the team settled on what they now call swipe-to-style, a way of formatting text using gestures instead of interface buttons. Over the next 48 hours, a developer coded up a prototype called Text Trial, an internal app that would allow them to test out different methods of formatting text with touch gestures.

I love this interaction model. The article is worth a proper read, too. They could’ve released the iPhone version three years ago, but didn’t because they want to get it right. The read is just a glimpse how much thought and craft went into making the port.

/via Benoît

Slack fixes

In the Slack iOS client the swipe left and right always brought up a contextual menu. If you swiped from the left edge you’d get the channel/user list, if you swiped from the right, you’d see the Slack menu.

For some time these were not real drags, but programmed swipes that didn’t follow your finger, you just triggered the event and it slid automatically. And those times sucked, it always felt like a robot massaging me. Then they changed it and now it’s a real drag with real feedback. I had this issue and it was fixed.

Then, for teams you’re admin in, they introduced an “Invite” feature. This menu option, however, appeared on the very bottom of the menu, where usually the highly important “Switch Teams” was. So in teams you’re not admin in, you’d get the switch at the bottom, in teams you’re admin in, the invite. When checking up on teams, it was very confusing since you always had to pay attention where to tap, the previous “just tap the bottom menu item” didn’t work.

And now it’s also been fixed. I love Slack.

Lookup forrásválasztó

Egyik kedvenc fícsöröm Macen a három ujjas “lookup“. Általában ezzel szótárazok, ha valamilyen angol szót nem ismerem olvasás közben, egyszerűen csak ráklikkelek három ujjal.

Keveset reklámozott dolog, hogy ezt picit átalakították 10.10.3-ban, ahol a Wikipedia stb. szócikkeket már nem ömlesztve, hanem egy kontrollal választhatjuk ki. Így néz ki:

Egyetlen gondom van csak: melyik a gomb? Yosemite alatt a szürke alapon fehérrel jelölt részek a gombok. Itt viszont ez a grafikai elem a kijelölt állapotot mutatja, azaz a fenti screenshoton a Dictionary a kiválasztott (nem nyomható) elem, míg a Wikipedia a kiválasztható (megnyomható). Még egy apró animáció is átvezet egyik állapotból a másikba.


Avoid using a push button to mimic the behavior of other controls. (…) Don’t use a push button to indicate a state, such as on or off.

(Az angol-magyar szótár bekötéséről bővebben.)

Best Interface Is No Interface: The simple path to brilliant technology

Golden Krishna:

There was me, walking up to my car. And there was my goal: to open my car door.

(This isn’t complicated.)

Walk up to my car
Pull out my smartphone
Wake up my phone
Unlock my phone
Exit my last opened app
Exit my last opened group
Swipe through a sea of icons, searching for the app
Tap the app icon
Wait for the app to load and try to find the unlock action
Make a guess with the menu and tap “Control”
Tap the Unlock button
Slide the slider to unlock
Physically open the car door (my goal)


If we eliminate the graphical user interface, we’re left with only two steps:

A driver approaches her car
She opens her car door

Egy újabb dialer őrület

Itt van ez a screen a Wazéból (de mindegy melyik, bármelyiken mutathatnám):

A törlés gomb elhelyezése és pozíciója az érdekes: a 0 számbillentyű mellett, jobb oldalon. Ha írom a számot, és törölni akarok, mindig oda nyúlok. Én úgy tudom, hogy ez a billentyűzet Apple szabványos beviteli form. Dacára ennek a konvenciónak, a dialer screenen valamiért a jobb fölső sarokba került:

Nem tudom, a user testen mik a meglátások, de én minden alkalommal elrontom. Nem volt alkalom, hogy ne jobb alul akarjak törölni. Ugyanitt epekedve várok a napra, amikor képes leszek a számot hívás előtt szerkeszteni. Apple plz.

Designing Twitter video

Paul Stamatiou:

750+ Sketch mockups 54 Framer prototypes
While there were multitudinous sketches, visual design changes and prototypes along the way, I’ll show a few of the main directions. After understanding what the problem was and having a hunch of how it could be solved, I began to sketch as many different directions as I could, pick the best ones and then test them out in a prototype. The design team at Google Ventures talks about something like this called the “Understand, Diverge, Decide, Prototype and Validate” sprint.

Tegnap eltelt pár perc, mire rájöttem, hogy nem különálló alkalmazást csinálták, hanem a mainline app része a videó. Aki megnézi az appot, egyből látja, hogy egyszerű, mint a faék, “bárki utána tudná csinálni”. Viszont érdekes módon kurva egyszerű használni. Miért? A válasz: 750 Sketch mockup és 54 Framer prototype.

Az egyszerű, magától értetődő dolgok mindig nagyon nehezek, és ez az út vezet a megoldáshoz: 750 Sketch mockup és 54 Framer prototype. Aki csinált már hasonló dolgot életében, most remélem bólogat. 🙂

3 Rules of App Design (according to Marissa Mayer)

John Brownlee, FastCo Design:

A new book about embattled Yahoo CEO Marissa Mayer reveals her three rules of great app design:

1. The Two Tap Rule – “Once you’re in the app, is it two taps to do anything you want to do?” If no, time to redesign the app.”

2. The 5-Point Rule – count a point for every different font, font size, and color on a page. If a page goes above five points, it’s time to redesign.

3. The 98% Rule – every product should be designed for the way it will be used 98% of the time

Az első kettőt, noha értem és jó vezérlő elvnek gondolom, szerintem nem kell készpénznek venni (ő maga is áthágja a szabályokat), viszont a hármassal nagyon egyet tudok érteni, amikor mindenféle obskúrus edge case-ek miatt vezéreljük a felületterveket. Mayert nem tartom egyébként egy különösebben nagy gurunak, sőt, viszont a Hatalom mögötte áll, így legitimálni tud dolgokat, például ezt is.

Hipotézis hajtotta UX design

Egy eBay tulajdonolta nagy német cégnél dolgozó UX szakember, Maximillian Wambach, nem sokkal kezdése után azt a feladatot kapta, hogy dolgozzon a mobil app redesignon. A pitch teljesen hétköznapi: “[new design should] not only to match current visual design guidelines and trends but also to get rid of usability issues that were caused by the current design approach”

El is készítették ezt a változatot:

Kártyás, nagyon szép, csak leestek tőle a számok. És most jön a lényeg, ki a jó UX szakember. 🙂 Végigolvastam a posztot és nekem a végeredmény, meg a nagy tanulság, a következő: nem azon múlik a szakma, hogy mit rajzolsz, hanem azon, hogy milyen blogposztot tudsz írni a gondolatmenetből. Először is arról, hogy a jelenlegi megközelítésnek mi a hibája. Aztán kitalálni, hogy milyen megközelítést alkalmazzunk, milyen hipotézisekkel, aztán azt hogyan alkalmazzuk. Ábrák kellenek, meg nyilak.

A végeredmény drótvázak egyébként meglepően semmitmondók: visszavettek a kártyákból és kompaktosították három képen a dolgokat. Viszont kijött belőle egy tökéletes szakmai blogposzt, validálva van a business előtt a dolog, talán még a számok is jönnek (erről nem kaptunk sajnos infót).

/via Webisztán Weekly

Hogyan kell tervezni iPhone 6 Plusra?

Azt kezdtem el megnézni, hogy egy iPhone 6 Plus layout tervezésének hogyan kell nekiállni? Az alapvető probléma onnan indult, hogy Sketchben felraktam az iPhone 4s-5s-6-6p artboardokat egymás mellé és ezt látom:

A 6 Plus az egyetlen nyilvánvaló kivétel, hiszen bitang nagy a többihez képest. De miért is ne lenne az, ha egyszer a szoftver 1242×2208 tényleges pixellel számol (3x), amiből az eszköz megjelenít végül 1080×1920 képpontot? A valóságban egyébként a következőképpen néz ki a méretbeli különbség:

Jól látszik, hogy a fizikai méretek között nincs ekkora különbség. Persze, mivel nem lehet összemérni őket, hiszen a 6-os 2x-ben, a 6 Plus 3x-ben gondolkodik. Jó ötlet lehet ezek után 2x-ben felrakni az artboardokat, hogy akkor hasonló arányokat lássunk.

Ez már alkalmas arra, hogy tervezzünk rá egy képernyőt, viszont ha erre rátesszük a valós méretet, látszik, hogy a valós méret (amit a kezünkben tartunk), nem az, ami a Sketchben 2x 6 Plusnál látható:

Ennek az okát nem fogom tudni levezetni, de szívesen látnék ezzel kapcsolatos pontosítást. Eleve onnan kezdődik, hogy a poszt fenti ábráján levő fizikai milliméter adatok nem pontosak (és nem is tudom, mik a pontos számok, ennél jobbat nem találtam). iPhone 6 esetén (58 mm)2 + (104 mm)2 = 14180, ellenben a derékszögű háromszög átfogója (120 mm)2 = 14400. Egyébként a fizikai pixelek aránya szépen kijön 16:9-re (0,5625), ugyanakkor a fenti milliméter adatok nem (0,5577). Photoshopban 58x104mm 326 PPI-vel 744×1335 pixelre jön ki a 750×1334-gyel szemben – pixel aspect ratio?

Feketével jelöltem be, hogy mekkora lesz a valóságos mérete – egy icipicit nagyobb. (Számításaim szerint 6,6%-kal.) Mit jelent ez a gyakorlati dizájnernek? Azt, hogy nyugodtan tervezzünk 2x-ben 6 Plusra, de legyünk tisztában azzal, hogy a fizikai, ténylegesen megjelenített méret a kézben picit nagyobb lesz. Ez azt jelenti, hogy egy ugyanakkora méretű felirat készüléken lemérve 6,6%-kal hosszabb és magasabb.

Próbaképpen Xcode Simulatorben is megnéztem azt, hogy az Apple mit alkalmaz design stratégiához, vagyis ők a tervezéskor milyen szabályokat követnek. Szerettem volna megtudni, az Apple hogy dizájnol 6 Plusra, milyen méreteket, arányokat tart, hogyan áll neki a kérdésnek.

Szeretném jelezni, hogy átnéztem az Apple iOS Human Interface Guidelines dokumentációját és ezzel kapcsolatosan konkrétan semmi információt nem találtam. Pedig ez szerintem egy teljesen tipikus hétköznapi kérdés bármelyik designer részéről. (Vagy mit néztem be, nem tudja valaki?)

A szimulátorban sajnos a 3x felbontás értelmezhetetlenül nagy, viszont nincs lehetőség 2x-re csökkenteni, a beépített kontrollok csak 75, vagy 50%-ra képesek. 3x-ről 2x-re menni pontosan 2/3-ra, vagyis 66,67%-ra kellene csökkenteni a méretet, ezért mit volt mit tenni, Photoshophoz nyúltam. A következő ábrán 1 másodperces késleltetéssel mutatom be, hogy az iPhone 4s / 5s / 6 és 6 Plus, manapság targetált iOS telefonméretek hogyan néznek ki pontosan egymásra téve:

Nagyon jól megfigyelhető, hogy az ikonok és szövegek maradnak ugyanolyan méretűek iPhone 6 Pluson is, csak az elhelyezkedésük változik a képernyőn, illetve ebben a példában a kis bélyegképek nőnek. Megnéztem egyébként rendesen és tökéletesen kiadják a méretek egymást.

Mindebből az következik, hogy nyugodtan tervezhetünk 2x-en (828×1472) ugyanakkora méretben, mint iPhone 4-5-6-ra, csak arra az artboardra kell szétdobálni az elemeket, végül pedig 3x-ben exportálni az asseteket.

IBM Design Language

Első scrollozás alapján csak egy ízlésesen összerakott dolog, aztán kiderül, hogy minden link mögött mélyebb tartalmi egységek vannak, végül el lehet jutni az “Inspiration” oldalra, ahol az addigra már felépített dizájn nyelv alapján bemutatják néhány mintán keresztül, hogy az új IBM vizuális nyelvtana milyen a gyakorlatban. Sokkoló, mennyire jól összerakták, mindent lementettem magamnak és próbálok belőle tanulni.

(Egyébként az utóbbi hetekben több ilyet is átnéztem, külső-belső dolgokat, azért lehet látni, hogy a világ hol tart ebben a tekintetben. Nagyon innovatív gondolatok és vizuális nyelvtan nem kerül elő sehol, a vizuális végeredményben eléggé hasonlít mindenki egymásra, vagy másképp, ahogy mondani szokták, most ez megy.)

Scrolling UX

Rebecca Gordon és csapata azt nézte, hogy scrolloznak-e az emberek különböző vizuális kulcsok hatására, illetve azok mennyire befolyásolják a scrollozási hajlandóságot.

we conducted user testing with 48 participants over 3 days. We did so using unmoderated remote testing to see how this less conventional methodology would compare to mediated testing, our usual approach.

Ami visszajött: mindenki, függetlenül bármitől, scrollozik. A fenti kutatás során a felhasználók több, mint 90%-a azonnal tekerni kezdte a képernyőt, teljesen mindegy, hogy tettek oda nagy méretű lefelé mutató nyilat, vagy sem, vagy megmutatták-e a lenti érdemi részt, vagy sem.

Emlékszem még régebbről, hogy nagyon gyakran jött vissza a business oldaláról az a feltételezés, hogy a “first view”-ba kell tenni a tartalmat, hogy megtalálják, azonnal lássák. Igen, van ebben is logika, mint ahogy abban is, hogy a nagyobb logó jobb. Ettől függetlenül jó lehet tudni, hogy az emberek szeretnek scrollozni és azonnal meg is teszik.

Főleg egyébként akkor, ha nem görgős egerük van, hanem pöckölhető touchpadjük, érintőkijelzőjük, vagy ilyen egerük, egyszóval kényelmes eszközük.

Fira for OS X

Jens Kutilek újracsomagolta a Mozilla OS betűtípusát a Firát, hogy egy vonzó alternatívát kínáljon a Yosemite rendszerbetűjét, a Helveticát nem kedvelőknek.

Az általam ismert Maces, de mobil eszközök tekintetében egyébként vígan Androidozó ismerőseim, kapva kaptak az alkalmon és ugrottak rá a kérdésre. Szabó Gergő ráadásul linkel a munkáltatójának egy blog bejegyzésére, ahol Alissa Walker próbálja összeszedni a nagy designerek finnyogását az új rendszerbetű miatt.

Nem pontosan értem a kérdést, illetve a problémát.

Eleve úgy tűnik, mintha ezek az emberek még nem láttak volna iOS-t, ahol már egy ideje bevezetésre került a Helvetica Neue egy képernyőre optimalizált rendszerbetűje. Az Apple mindig is hírhedt volt arról, hogy mennyire odafigyel a tipográfiára, most miért lenne ez másképp?

Eleve egy olyan változattal szállítják az OS X-et, ami kis méretben is gyönyörűen néz ki. Aki nem hiszi, az gondolom nem nézi napi szinten a Findert, vagy nem nézi a Safarit. Én nézem mindkettőt. Teljesen értem, hogy miért jobb, mint ami volt. Mindez 1x képernyőn, ami még nagyobb kihívás. Talán retinán még szebb.

A másik dolog, amit nem értek: miért azzal kezdi mindenki az okoskodást, hogy nekiállnak kitalálni mi a rossz, amikor meg sem értették még azt, ami van?

1. Apple OS X Human Interface Guidelines
2. Apple UIKit User Interface Catalog
3. The iOS Design Guidelines

(A posztot nem erre akarom kanyarítani, de ismerem azt a gondolkodást, amikor a designerek azzal kezdik a munkát, hogy na, akkor válasszunk ki egy fontot. Ez nálam a zsírkrétával színezés prodzsekt. Csak egy kérdés: mi lenne, ha az Apple HIG-ben terveznénk meg a prototípusunkat, wireframe-ünket, kontrolljainkat, aztán később, ha ez már mondjuk szépen és konzisztensen működik, akkor kezdenénk el dolgozni a márkázáson?)

Az Apple a legelső iOS 7 bétájában vékony Helvetica Neuét használ bizonyos információk megjelenítéséhez. Akkora volt a felhasználói bepicsogás, hogy visszavettek és áttették boldba a sorokat (sőt, még tovább boldozhatunk a settingsből). Rémes döntésnek gondolom, azóta is, hogy hívok valakit, mindig a félkövéret látom:

Ha jól megnézzük, bizonyos screeneken nem állították át:

Sokkal elegánsabb.

De visszatérve a poszt eredeti felvetéséhez: mi a hozadéka annak, ha elkezdjük áthekizni a rendszerbetűt? Lerakunk egy statementet, hogy elégedetlenek vagyunk? Elkezdünk hozzá jobban érteni? Kifejezzük azt, hogy mi örök megjavítók vagyunk és most megvan a font? Androidon értem, hogy ez egyfajta mentalitás és hozzáállásbeli dolog, hack forever.

Rengeteget foglalkoztam 10 éve én is hasonló dolgokkal. És tudjátok mi van? Minden esetben, amikor bárki másnak a számítógépét nézem, újra ugyanaz az idegenkedés. Az összes privát beállításom durván a képembe röhög az első alkalommal, hogy bárki gépe elé leülök, vagy a Mac boltban odamegyek megnézni egy új Macet.

Logikailag azt meg végképp nem értem, hogy valaki Macet használ, Androiddal és a Macre felrak egy Firefox rendszerbetűt. Ez olyan, mint a paradicsomleves krémessel összekeverve: gyomorforgató.