Четыре истины о дизайне
Вообще-то это не сложно, даже в половину не так трудно, как вы думаете.
1. Цвет не имеет смысла
Пользователи не понимают вашего цветокодирования. Зеленый значит «хороший» для вас, но для кого-нибудь другого на другом экране это может значит «нечитаемое» или «гусиное дерьмо» или «Сайгон? Что? Я до сих пор в Сайгоне?». Каждый человек видит цвет исключительно по-своему, если вообще видит. Он любит одни цвета, и ненавидит другие. И это в значительной степени непредсказуемо. Вы не сможете угадать.
Цвет не является вербальным или рациональным. Он контекстен и эмоционален. Цвет — сильный инструмент, но сам по себе он не имеет смысла.
Единственное что вы можете сделать с цветами это:
Любой цвет: элемент имеет цвет
Другой цвет: элемент отличается от другого элемента
Серый: что-то сломано
Красный: дизайнер ненавидит вас и хочет разозлить
2. Наибольшее значение имеет позиция
Пользователей не заботит, что значат ваши иконки на кнопках, или что на них написано. Вы можете изменять их каждый день, и никто не будет жаловаться.
Измените позицию элементов, и пользователи насадят вашу голову на пику.
Люди используют их моторную память при использовании приложений. Перемещение элементов интерфейса ощущается как изощрённый метод пыток. Если вы хотите знать, что такое чистая нефильтрованная горящая ненависть, идите и поменяйте несколько элементов местами.
3. Никто не читает
Вы, скорее всего, не читаете это предложение. Если читаете, то вероятно, не читали эту статью целиком с первого раза. Вы пробежались от заголовков к цитатам и может быть пропустили пару пунктов перед тем как прочитать этот абзац. Так что это правда. И тем не менее, почему же мы пишем пояснительный текст? Почему мы позволяем себе длинные параграфы в наших интерфейсах? Почему мы делаем вид, что руководство пользователя и часто задаваемые вопросы являются правильным решением для проблем юзабилити?
Потому что мы ленивые, вот почему! Слишком ленивы, чтобы читать, и слишком ленивы, чтобы не писать.
4. Навигация — это провал
Не гордитесь вашим интерфейсом навигации, или информационной архитектурой. Если важной частью вашего интерфейса является навигация, вы уже на пути к провалу.
Ваша задача – помочь пользователю достичь своей цели. Навигация по приложению НЕ цель пользователя. Если вы сделали свою работу правильно, ваше приложение будет делать только одну вещь и будет делать это хорошо, находясь все это время на одном экране. Но вы не в состоянии решить что-либо за пользователя или вовсе устранить выбор, и вы оставляете выбор на откуп пользователю пользователю.
Дизайн – это принятие тяжёлых решений, для того, чтобы избавить от принятия решения пользователя.
Да, хорошо, навигация необходима для большинства приложений, большинства сайтов, и пользователь, в конце концов, привык пользоваться навигацией. Мы должны пойти на некоторые компромиссы. Я безусловно согласен. И почти всегда иду на этот компромисс и внедряю навигацию. Тем не менее, мне стыдно и вам должно быть.
Три истины о процессе
Не все части приложения одинаково важны. Есть некоторые вещи, которые вы должны сделать в первую очередь, некоторые вещи про которые не стоит забывать, и некоторые, которые можно полностью проигнорировать.
5. Контент – хорошо, UI – плохо
Моей первой UX-работой еще до того, как концепция UX была сформулирована, была Информационный Архитектор. Это до сих пор наиболее важная работа, которая есть на любом проекте. Вещи имеют имена и должны быть названы. Определение имен и глаголов является наиболее важной частью UX.
Контент является решением. Если вы не проектируете контент, вы проектируете проблемы.
Каждый раз, когда вы создаете каркасы с Lorem Ipsum, вы оскорбляете своих пользователей и злоупотребляете доверием вашего клиента. А также саботируете сами себя.
Loremipsitis – это плохо, поверьте, я видел фото.
Когда вы не в состоянии бороться с фактическим содержанием, но сосредоточены на проектировании каркасов, которые будут независимы от содержания, вы на самом деле создаете барьер между пользователем и их целью. Прекратите немедленно. Спроектируйте контент и вы, скорее всего, справитесь с задачей автоматически.
6. Прокрастинация – это хорошо
Делайте карту сайта и навигацию в последнюю очередь. Вообще-то, не делайте их вовсе. Начните с самых важных объектов на экране: с того, который помогает пользователю достичь своей цели. Все излишки времени и бюджет должен быть направлен на то, чтобы сделать этот экран идеальным. Зацикливайтесь на каждой детали. Тратьте все время для полирования каждого пикселя. Не отказывайте себе в удовольствии наслаждаться каждой минутой разработки.
Когда наступит дедлайн или закончится бюджет на разработку, ваш клиент/босс будет очень злым, будет кричать на вас, что вы не сделали все остальное фуфло, которые они хотели втиснуть в пользователя. Будьте немым, извиняйтесь и заработайте репутацию того, кто никогда не закончит ничего…
Проваливайте план, чтобы не проектировать ненужные части.
Будем надеяться, что весь ненужный мусор будет откладываться до следующей версии, а пользователь будет наслаждаться чистым продуктом, пока вас не уволят, и тот, кто вас заменит, испортит этот идеал. На рынке нет недостатка в UX-дизайнерах, которые делают то, что им говорят, и то, что от них ожидают. Вот почему так много некачественных продуктов. Не будьте одним из них.
7. Юзер-тесты убивают детей
Юзер тесты — это что-то невероятное, это хорошо известный факт. Не важно, насколько невероятно вы умны, и насколько хорош ваш интерфейс. Десять минут юзер-теста на ранних стадиях проекта может уберечь вас от неудачи в конце пути.
Юзер-тесты рулят. Если вы не делаете их — вы идиот.
Тем не менее, юзер-тесты не освобождают вас от необходимости быть умным, работать, потеть над каждой мелочью и пройти через сумасшедший, извилистый, причудливо аморфный процесс проектирования. Вы по-прежнему должны быть гением. И это особенно верно, когда вы разрабатываете инновационное решение или продукты.
Когда дело доходит до инноваций, пользователи могут быть злыми, недалекими, близорукими, тщеславными, глупыми и т.д. И с этим приходится мириться.
Юзер-тесты новых идей отстой. Если вы делаете их — вы идиот.
Когда у вас есть прекрасная новая идея, она начинает свою жизнь с хрупкого зародыша, едва дышащего. Она нуждается в воспитании и нежной заботе, чтобы превратиться в полностью сформированную инновацию, которая сможет стоять крепко на своих двух ногах и выдержать неосторожное обращение с корыстными пользователями. Юзер-тестирование новой идеи как акулотестирование нового ягненка. Это заканчивается плохо, как для идеи, так и для ягненка. Так что не позволяйте вашей идеи идти к непосвященным… но только пока она не будет готова.
Как узнать о том, что идея готова? Когда вы работали над ней достаточно долго, вы начинаете видеть существенные недостатки: проблемы, которые состоят в том, как идея работает в общем, а не в том, как это все совместить с уже существующими. Когда идея начинает работать близко к тому, как вы задумали, что сами начинаете думать об альтернативах – пора проверять.
Две истины о программистах
Вы можете думать, что ошибка кодеров — не ваша вина. Справедливо, но все-таки это ваша ответственность. Так же, как отправка сообщения, которое никогда не будет получено, дизайн, который не будет понят – пустая трата времени. Вы должны понимать свою аудиторию, а ваша аудитория – программисты. Они странные животные, но в конце концов вы тоже.
Если вы хорошо заботитесь о дев отделе, разработчики сделают вас богатым и знаменитым.
Научитесь уже кодить, вообще-то уже пора, но пока вы этого не сделали, вот что нужно знать о программистах:
8. Программисты учатся на ужасных примерах
Разработчики не исследуют хорошо разработанные приложения и сайты, чтобы узнать, как они создавались. Они тратят свое время на обучение с помощью демоверсий и руководств, которые написаны другими кодерами, пытаясь объяснить сложные понятия кодирования, используя надуманные и смешные примеры.
Учебники по программированию учат худшим UX-практикам.
Они не думают о реальном применении этих примеров. Они не думаю о UX этих примеров. Их не заботит, приведут ли эти примеры к положительным результатам в своих вымышленных сценариях.
Тысячи разработчиков изучают свое ремесло, слепо реализуя чрезмерно простые, плохо разработанные, глупые сценарии. Они разрабатывают свои приложения с помощью нескольких неуклюжих форм и сотен часов безумных руководств. Так что, возможно, вы должны быть немного более конкретными с вашими спецификациями?
9. Программисты любят нелепость
Программистам приходится беспокоится о вещах, о которых не подумает ни один нормальный человек. Вы можете поместить поле «Фамилия» в ваш дизайн, но у программиста возникнет сотня тревог:
• Что делать, если у человека нет фамилии?
• Что делать, если фамилия выражается в виде математического уравнения?
• Что делать, если фамилия длиннее 255 символов?
• Что делать, если фамилия содержит символы табуляции, несколько абзацев, неразрывные пробелы, смайлики, круглые скобки, запятые, одинарные и двойные кавычки?
• Что делать, если фамилия изменяется со временем?
Для любого нормального человека, эти вопросы являются абсурдными, но для программистов - нет. Для дизайнера это значит, что он должен держаться рядом с программистами, понять их как можно лучше, чтобы предвидеть подобные тревоги, и удержать их от полной невменяемости.
There’s much to learn on the internet about UX theory, but the tips below are 100% the result of hard-earned experience… a.k.a. painful moments. I’ve screwed up a lot, in the last twenty years, and these are some of the ways I’ve found to stop screwing up. Enjoy learning from my mistakes!
Four truths about design:
It’s actually not that hard, and you’re not half as clever as you think.
1. Color is meaningless
The users don’t understand your color-coding. Green might mean “good” to you, but to someone else, on a different screen, it might mean “unreadable,” or “goose shit,” or “Saigon — Shit — I’m still only in Saigon…”
Each person sees each color in a completely personal way, if at all. They like some colors, and hate some others, and it’s pretty much unpredictable. You can’t win.
Color is not verbal or rational. It’s contextual and emotional. It’s powerful, not meaningful.
The only things you can communicate with color are:
- Any color: this thing has a color.
- A different color: this thing is not the same as the other thing.
- Gray: this thing is broken.
- Red: the designer hates you and wants to make you angry.
2. Position matters most
Users don’t care what your button’s icons are, or what their labels say. You can redesign those every day and nobody will complain.
Move things around, and your users will have your head on a pike.
People use their natural positional memory to remember how to use your app. Moving their interface elements around feels to them like the most perverse form of torture. If you want to know what pure unfiltered burning hate feels like, go ahead and move things around.
3. Nobody reads
You’re probably not reading this sentence. If you are, you probably didn’t even read this article through the first time. You scanned the headlines and the quotes, and maybe you’re skipping through the short paragraphs now.
Since that’s true, why do we write instructional text? Why do we allow long paragraphs of copy into our interfaces? Why do we pretend that user manuals, and FAQs, are a valid solution to usability problems?
Because we’re lazy, that’s why. Too lazy to read, and also too lazy not to write.
4. Navigation is failure
Don’t be proud of your navigation interface, or your information architecture. If your app has a prominent navigation interface, you’re already on the path to failure.
Your job is to help the user achieve their goal. Navigating an interface is never the user’s goal. If you’d done your job right, the app would only do one thing, and would do it very well, and would do it all on one screen. But you’ve failed to decide on and eliminate choices, and you’re leaving it to the user to do it.
Design is making the tough choices so your user doesn’t have to. (Tweet this)
Yes, okay, navigation is necessary for most apps, most sites, most experiences. We have to make some compromises in life. I agree, of course. I almost always end up making compromises too, and providing navigation. Still, shame on me, and shame on you.
Three truths about process:
Not everything is equally important. There are some things you should do first, some things you should do more, and some things you can completely ignore. Here’s how to tell the difference:
5. Content is good, UI is bad
My first UX-related job title, before the concept of “UX” had been formulated, was Information Architect. That’s still the most important job there is on any project. Things have names, and need to be verbed. Defining the names and the verbs is the most important part of UX.
The content is the solution. If you’re not designing the content, you’re designing problems. (Tweet this)
Any time you create a wireframe with lorem ipsum, you’re insulting your users, and abusing your client’s trust. You’re also sabotaging yourself.
Loremipsitis is to design what chlamydia is to lovemaking. (Tweet this)
When you fail to grapple directly with the actual content, but focus on designing boxes for whatever the content will be, what you’re actually doing is putting pretty boxes between the user and their goals. Stop it. Design the content, and you’ll probably be just about done.
6. Procrastinate away complexity
On a project, do the sitemap and navigation last. Actually, never do them. Start with the most important object or screen: the one that helps the user achieve their goal. Waste all the project time and budget on making that screen perfect. Obsess over every detail. Lavish hours to the appearance of each pixel. Indulge every fancy and enjoy every minute of it.
Once there is no more time or budget, your client/boss will get very angry, and scream at you that you didn’t do all the other bullshit they wanted to cram down the user’s throat. Play dumb, apologize, and earn yourself a reputation as a flake who never finishes anything… but still, don’t design any of it.
Fail to plan to design the stupid parts. (Tweet this)
Hopefully the junk you didn’t design will be pushed to Version 2, and the users will get to enjoy Version 1, until you get fired and your replacement ruins it all for everybody. There’s no shortage of UX designers who do as they’re told, and deliver what’s expected of them. This is why there’s so much bloatware in the world. Don’t be one of them. Stay the course.
7. User testing kills babies
User testing is wonderfantasterrifically awesome, that’s a well-known fact. No matter how amazingly smart you are, and how clever your UI is, ten minutes of user testing early on in the process will save you from abject failure down the road.
User testing rules. If you don’t do it, you’re an idiot. (Tweet this)
However, user testing does not absolve you from the responsibility to be smart, to work hard, to sweat out the details, and to go through the crazy, tortuous, gut-wrenching, bizarrely amorphous process of design. You’re still going to have to be a genius, buster. And that’s especially true when you’re designing innovative solutions or products.
That’s because when it comes to innovation, users can be mean, narrow-minded, myopic, vain, philistine, petty, and stupid. And that’s coming from someone who’s dedicated his life to loving his users.
User-testing new ideas sucks. If you do it, you’re an idiot.
When you have a great new idea, it will start its life as a fragile embryo, barely viable. It needs nurturing and loving care to grow into a fully-formed innovation, that can stand on its own two legs, and withstand the careless handling by selfish users. User-testing a new idea is like shark-testing a new lamb: It doesn’t end well for the idea, or the lamb.
So don’t let your idea go untested… but only once it’s ready. How do you know when it’s ready? When you’ve worked on it long enough that you start seeing its fundamental flaws: Problems that are not about how it’s been put together (improvable), but about how it works in the absolute (intrinsic). When it works close enough to the way you intended that you can start thinking of better alternatives… then it’s probably ready to test.
Two truths about coders:
You may think that what coders do with your design isn’t your fault. Fair enough, but it’s still your responsibility. Just like sending a message that won’t be received, delivering design that won’t be understood is a waste of everybody’s time.
You need to understand your audience, and your audience is coders. They’re weird animals, but then again, so are you.
If you take good care of the DevX of your UX, devs will make you rich and famous. (Tweet this)
You really should get off your lazy designer butt and learn to code already. But until you do, here’s what you need to know about coders:
8. Coders learn from terrible examples
Developers don’t explore well-designed apps and sites to learn how to build apps and sites. They spend their time learning from demos and tutorials, which are written by other developers who are trying to explain complex coding concepts, by using contrived, ridiculous examples.
Coding tutorials teach UX worst practices. (Tweet this)
They don’t think about the real-life validity of these examples. They don’t think about the UX of these examples. They don’t give a rat’s ass whether these examples would lead to positive outcomes for the user in their fictional scenarios.
Thousands of developers learn their craft by blindly implementing overly simple, badly designed, stupid scenarios, for hours on end. Then they build your app based on a couple of flimsy wireframes, and on hundreds of hours of terrible tutorials. So perhaps you should be a bit more specific with your specs?
9. Coders love absurdity
Programmers have to worry about things no sane human being ever considers. You drop a “last name” field in your design without thinking about it, but to a coder, there’s a hundred anxieties associated with that:
- What if the person doesn’t have a last name?
- What if their last name is expressed as a mathematical equation?
- What if their last name is longer than 255 characters?
- What if their last name contains tab characters, multiple paragraphs, non-breaking spaces, emojis, parentheses, commas, single and double quotes?
- What if their last name changes between the time when they type it in and the time when they submit the form?
To any normal human being, these questions are absurd. To a coder, they are common sense. What this means for you, as a designer, is that you must keep close to your coders, try as much as possible to anticipate the anxieties that will besiege them, and keep them from derailing the experience with utter lunacy.
Good luck with that, by the way. Make sure you enjoy the ride.
