Блог #UX/UI

Как сделать так, чтобы проектная команда усваивала документацию с тем же рвением, что и быстрые углеводы? Есть несколько правил и хаков.

Мы все знаем, что такое бесшовный опыт. Мы даже проектируем контекстное переключение между сервисами/приложениями/устройствами — и тратим порой на это довольно много времени. Так почему же бесшовное взаимодействие поддерживают лишь считанные единицы даже самых крутых наших продуктов? Ответ не так прост, как может показаться.

На территории стран бывшего Союза есть извечный, казалось, вопрос: дизайн — это про что? Про продукт в целом или только про его UI, внешнее проявление? И как к дизайну относится проектирование? А может, это вообще одно и то же? Давайте разбираться.

Любое перепроектирование предполагает меньше неопределенности — а значит, оно безопаснее, проще. Но почему-то многие берутся за него со старым подходом: обычным, привычным и унылым. А там же нюансов — миллион. Не учтешь какие-то, и работать придется больше, а результат будет не таким стабильным.

Все мы фэйлимся. Но даже самые матёрые из нас, набравшись храбрости, вещают со сцен полубесполезные истории о том, как они слажали — и сразу все исправили. И стало даже лучше, чем было. Это вредно. Это создает вокруг ошибок ореол несерьезности, некой «возвратности», когда все можно поправить. Как так получается и почему каждый должен вспомнить хотя бы один свой «окончательный» фэйл — и поведать о нем миру.

Небольшая заметка-памятка тем дизайнерам и арт-директорам, которые решили создать для своей компании дизайн-систему. Не претендую на непреложность нижеизложенного, ибо пишу во славу смысла здравого, а не хайпа ради.