Антон Жиянов написал о транслитерации.

Чтобы вы представляли масштаб бедствия. Я насчитал 20 схем транслитерации, некоторые из которых предусматривают альтернативные наборы правил (например, с диакритикой и без). Из них 14 считаются действующими.

Как выбрать схему:

— Загранпаспорт или водительское удостоверение. По умолчанию используйте ICAO Doc 9303 — это требование закона. Впрочем, есть лайфхак: если написать отдельное заявление при подаче документов, сделают паспорт с нормальной транслитерацией. Тогда подойдёт старый стандарт МВД-310[8] или Мосметро.

— Если нужно обратимое преобразование (cyr ↔ lat). Используйте ГОСТ 7.79-2000. Это международный стандарт ISO 9:1995. Громоздкая, зато абсолютно непробиваемая схема. Есть варианты с диакритикой и без.

— Если визуальная красота превыше всего. Используйте схему Мосметро, она самая лаконичная и приятная на вид.

— В остальных случаях. Используйте схему Википедии. Она лучше всех по фонетике и лишь немного уступает Мосметро визуально.

https://antonz.ru/iuliia/

Опубликованы видео с митапа «Инклюзивный дизайн».

1. Mail.ru — Об исследовании Почты
youtube.com/watch?v=q7UbWH8gMqg

2. Валерия Курмак, AIC — Как заложить принципы инклюзивности в дизайн-систему
youtube.com/watch?v=Or7vNJ6W6KI

3. Билайн — Опыт внедрения стандартов доступности
youtube.com/watch?v=WMbbXF8EspY

4. Альфа-Банк — Инклюзивный подход в банковских продуктах
youtube.com/watch?v=EpVlFTV5gzo

5. Mos.ru — Внутренний инструмент подбора доступной палитры
youtube.com/watch?v=vOQT1Pvcga8

6. Круглый стол
youtube.com/watch?v=E-0Pput_hxM

Все видео в одном месте: youtube.com/playlist?list=PLzqQCeTtpSBpjt_4NBbLvBCVEzWpcPCvF

Игорь Штанг разобрал ошибки сравнительных таблиц на многочисленных примерах памяток с симптомами коронавируса, простуды и гриппа.

1. Многие таблицы пестрят иконками, которые иллюстрируют симптомы. Их сложно отличить друг от друга и интерпретировать, что никак не упрощает и не ускоряет восприятие информации.

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

3. Полезно обозначить цветом частоту симптома. Это ключевое свойство и оно незаметно при беглом просмотре: слова «часто», «иногда», «редко» внешне похожи друг на друга. Но важно подобрать правильную цветовую гамму, чтобы первым в глаза бросалось «часто».

4. В некоторых таблицах вместо слов стоят условные обозначения. Дизайнеры любят так делать: придумать хитрый шифр, а подсказку написать внизу мелким текстом. Текст работает лучше любых условных обозначений.

https://awdee.ru/naglyadnost-v-tablitsah/

Юля Кондратьева сравнила мнения знаменитых дизайнеров с исследованиями о том, какие шрифты легче читать: антикву (с засечками) или гротески (без засечек).

Юрий Гордон, Ян Чихольд и Сергей Сурганов считают, что легче читать текст, набранный шрифтом с засечками.

Исследования говорят, что для обычного человека отличий почти нет, а для тех, у кого есть проблемы с чтением (стариков, детей, людей с плохим зрением или дислексией), предпочтительнее шрифт без засечек.

Если смотреть не на читаемость, а на эмоции:

«В Лаборатории исследований юзабилити ПО в Wichita State University респондентов попросили заполнить опросник и указать, какими характеристиками обладают разные шрифты.

Интересно, что шрифты с засечками оказались первыми в рейтинге как формальные, „взрослые“, практичные и стабильные. А шрифты без засечек оказались первыми в рейтинге… нигде. То есть у них не оказалось какого-то ярко выраженного эмоционального следа».

https://habr.com/ru/company/tinkoff/blog/498878/

Александр Овчаренко написал, почему работа дизайнером несовместима с чёткими формулировками.

Деятельность по достижению целей сводится к решению задач и решению проблем.

Решить задачу — совершить определённую процедуру (порой весьма сложную) по известному алгоритму. Здесь понятно, что делать, главное, не забыть ничего и обладать необходимыми навыками.

Решить проблему — достичь цели при условии, что путь решения не известен, либо конечная точка не понятна или их множество, а может её и нет вообще.

Решить проблему — свести её к задаче, то есть определить критерии качества, выяснить, какие варианты достижения цели могут быть, провести необходимые исследования или попробовать решить боем, возможно, в несколько итераций.

Дизайнер — человек, который умеет решать проблемы, конвертировать мутные идеи заказчиков в нечто реально существующее в виде продукта.

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

Дизайн и искусство работают с концепциями и их реализацией в конечном продукте или произведении. Обе деятельности сочетают проблемный подход.

Отличие в том, что дизайнеры получают символы и знаки на входе от внешних стейкхолдеров. Разница между знаком и конечным продуктом может быть радикальной, но при этом мы всё равно будем решать поставленную извне проблему. Художник же будет решать что-то своё, придумывать свой собственный знак и его воплощение.

https://9dots.ru/2020/05/12/мутная-суть-дизайна/

Евгений Игнашов написал для начинающих об этапе анализа, который идёт перед проектированием интерфейса.

— Что надо спросить у заказчика;
— Какие показатели посмотреть в Яндекс Метрике (если есть);
— Как составить карточку пользователя и описать сценарий;
— Что смотреть у конкурентов;
— Две карты интерфейса: как сейчас (если есть) и как надо;
— Как подбирать примеры стилистики.

«При анализе конкурентов выписываю только то, что можно у них почерпнуть. Нет смысла выписывать слабые стороны. Клиенты с небольшой иронией в голосе говорили что-то вроде: „А, ну нормально. Просто взял, что увидел у кого-то, и к нам применяешь“. После этого я специально в презентацию добавил фразу „Можно почерпнуть у конкурентов“, сходу говоря, что если надо, то именно это я и возьму, не стесняясь».

После этапа анализа:
— Клиенту стало чуть-чуть понятнее, чего ожидать в итоге;
— Дизайнеру стало понятнее, как делать и почему именно так;
— Дизайнеру проще оценить сложность проекта и выдать почти точные сроки;
— Дизайнеру и клиенту проще сдать и принять результат;
— Проект будет более продуманным, и это хорошо.

https://habr.com/ru/post/500796/

Михаил Кравченко написал о создании интерфейса для игры.

Обзорно рассмотрел шаги:
— Описание проблемы;
— Работа с референсами;
— Пользовательский сценарий;
— Согласование с командой (особенно важно в самом начале, посмотрите примеры обратной связи от команды);
— Набросок структуры интерфейса;
— Создание и тестирование прототипа (желательно, если есть время);
— Оформление интерфейса, сбор из UI Kit’а;
— Подготовка материалов для программистов;
— Контроль качества сборки;
— Тестирование на игроках.

Если UI Kit’а нет, то перед оформлением интерфейса надо сделать:
— Визуальный стиль интерфейса под сеттинг игры;
— Работа с референсами визуального стиля;
— Наброски визуального стиля интерфейса;
— Чистовая отрисовка интерфейса;
— Сборка UI Kit’а.

Есть примеры артефактов.

«Хороший пример соответствия оформления интерфейса сеттингу игры в StarCraft II. Когда играем за людей, интерфейс состоит из металлических панелей, пластин, проводов и заклёпок. Когда играем за зергов, интерфейс представляет собой аморфную биомассу с прожилками из когтей, хитиновых пластин и подобного».

https://habr.com/ru/post/498600/

Павел Шерер написал об учёте требований информационной безопасности при проектировании интерфейса. Например:

Представьте, что пользователь прошёл по сценарию восстановления пароля, но ссылка на восстановление утекла к третьим лицам. Например, он воспользовался бесплатным, но скомпрометированным вайфаем.

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

Для предотвращения этого достаточно сделать ещё одну ветку сценария и отрисовать ещё один типовой макет. Через сутки мы деактивируем ссылку из письма с восстановлением доступа. Дизайнер собирает один макет, на котором показывает сообщение типа «Ссылка устарела».

Пользователь даже не заметит изменений — чаще всего ссылка используется в первые несколько минут после запроса.

https://zen.yandex.ru/media/id/5a8249f94826772d3da82e8c/5ebea1e37f5192548fb25a63

Дмитрий Ваницкий поделился краткими выводами из монументальной «Биологии добра и зла» Роберта Сапольски.

Роберт рассуждает о природе наших самых хороших и плохих поступков. Труд охватывает все ныне известные факторы влияния на наши решения: от эволюционных и генетических до культурных и социальных. Всё это с подтверждениями в виде сотен экспериментов.

Книгу можно рекомендовать всем, кто увлекается или хочет увлечься нейробиологической основой нашей модели принятия решений.

«Давайте представим, что вы участвуете в эксперименте по определению длины отрезков вместе с другими испытуемыми. Всё идёт хорошо, пока вам не показывают отрезки, 1-й из которых явно длиннее. Вы думаете: «Изи!». Но вот все остальные говорят, что длиннее 2-й отрезок. Настаёт ваша очередь. Что вы сделаете? Пойдёте против большинства или дадите заведомо неверный ответ, чтобы не выделяться? Я скажу, что с вероятностью 75% — второе.

Социальный конформизм, обнаруженный в экспериментах Аша с принятием мнения большинства, наглядно демонстрирует нашу жажду принадлежности».

https://medium.com/design-spot/e4b9bcd9d03a

Автомобильный дизайнер Артём Степанов рассказал об интерфейсах систем автомобиля.

Мы сейчас на этапе развития автомобильных технологий «Это ужасно, но все привыкли» и тихонечко его перескакиваем. 80% автомобилистов пользуются 10% функций автомобиля.

Из-за унификации в пределах больших концернов (например, Volkswagen-Audi Group) владельцы дорогих машин садятся на кожаные сидения, но видят те же панели (например, управления кондиционером), что и владельцы машин в 2 раза дешевле.

Маркетологи тоже думают, как сделать круто, ведь нельзя же покупателям новых моделей предлагать старые добрые крутилки. Так в БМВ 7-й серии мультимедиа можно управлять 5 способами:
— Крутилка на передней консоли;
— Касание экрана;
— Тач-панель на крутилке (вместо использования экранной клавиатуры можно рисовать буквы);
— Жесты рукой в воздухе (изменение громкости, переключение каналов);
— Голос.

Тач-панель в Тесле в виде огромного планшета — это просто экономия огромной кучи денег. Конечно, этот планшет дороже обычных экранов и пластиковых кнопок. Экономия происходит при разработке новых элементов.

https://www.youtube.com/watch?v=DR9a9t-cGug

Николай Бабич написал, как сообщить пользователю о состоянии системы.

— Выделить в меню раздел, в котором пользователь сейчас находится;
— Показать количество шагов, которое необходимо для завершения процедуры;
— Обратная связь на действия пользователя — нажатия на кнопки и переключатели;
— Показать индикатор загрузки; с прогресс-баром, если операция занимает больше 10 секунд;
— Анимированные экраны-заставки для мобильных приложений;
— Отобразить скелет страницы, пока загружается её содержимое (паттерн skeleton page/screen);
— Уведомления об изменениях в системе;
— Моментальная обратная связь о неправильно заполненном поле.

https://ux.pub/4-metoda-vizualnogo-fidbeka-v-interfeysah/

Матвей Правосудов написал, зачем дизайнеру уметь кодить.

«Когда работаешь в режиме концептов на дрибл, не видишь материала: делаешь статичные или анимированные картинки с летающими конями, параллаксом и эффектами. Работа уходит на сайт, собирает лайки и комменты и погибает в пучине одинаковых дрибловских шотов.

На реальных проектах с настоящими разработчиками всё печальнее: эффект сделать долго и дорого, таких данных нет и никогда не будет, такое взаимодействие почти невозможно реализовать. В общем, печаль и грусть. Но такова жизнь, не любую фантазию дизайнера можно воплотить.

Так вот, понимание принципов работы технологий (HTML/CSS/JS/API для веба, Swift для iOS и Kotlin/Java для Android) помогает сразу делать макеты более жизнеспособными, а иногда, при возникающих сложностях у разработчиков, ухищряться и выдавать оптимизированное решение, которое достигает того же эффекта, но заметно дешевле».

https://designpub.ru/f728cb8c1e39

Пол Боаг написал, почему тёмные паттерны — плохой выбор для компании, играющей в долгую.

Раньше потребители в основном не знали, что ими манипулируют, но всё изменилось. СМИ пишут о манипуляциях, пользователи становятся опытнее, чаще видят тёмные паттерны, и их это раздражает. Потребители избалованы выбором и легко уходят к конкурентам.

Недовольные клиенты делятся своими эмоциями: отзывы остаются в интернете навсегда, а отдельные истории становятся вирусными (Хасан Сайед и British Airways).

Обманутые клиенты могут создавать группы для защиты своих интересов. Иногда их аргументы доходят до государства, и оно включает регулирование (Великобритания и рынок онлайн-бронирования отелей).

Всё это в долгосрочной перспективе уменьшает выручку, количество повторных заказов, затрудняет привлечение новых клиентов.

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

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

https://ux.pub/kak-ubedit-drugih-ne-ispolzovat-temnye-patterny/

Павел Шерер написал о создании концепции — предварительном этапе перед проектированием.

Концепция предполагает базовые исследования и аналитику уже на самом старте проектного процесса. Её задачи:

1. Сформировать у команды единую картинку продукта. Сильно влияет на стабильность дальнейшей работы над ним.

2. Очертить первоначальные границы проекта: из каких частей будет состоять продукт, какие типы ресурсов потребуются для его создания, каким образом будет проходить коммуникация с клиентами, партнёрами и так далее.

«Между пользователями возможны конфликты. Если сделка проходит через сервис, мы должны эти конфликты решать. Нужен внутренний сервис тикетов — своеобразный арбитраж.

Сколько усилий уйдёт на создание внутренней арбитражной системы? При этом она не является функциональным ядром сервиса, и стартап спокойно запустится без неё. Умный проектировщик кратко опишет арбитраж как „следующие этапы развития“, предложит ввести рейтинг, а спорные вопросы первое время решать через поддержку».

3. Предусмотреть базовые риски, описать векторы развития, примерно представить, что может воспрепятствовать развитию продукта, — и подумать, как обойти такие препятствия.

4. Первично оценить проект и проектирование. Не придётся в середине проектирования столкнуться с тем, что продукт нежизнеспособен без какой-нибудь его части, а стоимость её создания сопоставима со всеми остальными работами.

— Задачи концепции: https://zen.yandex.ru/media/id/5a8249f94826772d3da82e8c/5ed3f26b709fb133f9734d4a
— Состав и структура: https://zen.yandex.ru/media/id/5a8249f94826772d3da82e8c/5ed67a182cf6c679060463e3

Константин Солодянников законспектировал книгу «Спроси маму».

«Ненужная информация бывает такой:
— Комплименты;
— Болтовня (общие фразы, гипотетические рассуждения, разговоры о будущем);
— Идеи.

Любой из пунктов — признак того, что мы получаем социально-желаемые ответы».

«Важные вопросы — неудобные. Типа, когда думаешь, да как я это вообще спрошу. Вдруг там что-то такое страшное скажут, и всё пропало, паника. Лучше не спрошу.

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

https://www.it-agency.ru/academy/summary-the-mom-test/

Тарас Бакусевич написал о дизайне текстовых полей и форм. Вот некоторые из его рекомендаций (не самые распространённые):

— Подчёркнутое поле ввода — не лучший стиль для текстового поля. Он распространился с появлением Material Design, но потом Гугл от него отказался;
— Длина поля должна быть пропорциональна вводимой информации. Формы с такими полями будут менее аккуратными, но более удобными;
— Заполняйте поля адекватными значениями по умолчанию, но только не при выборе размера или цвета товара;
— Отображайте полезные подсказки, которые помогут принять правильное решение или избежать ошибки. Например, показывайте баланс при совершении платежа;
— Не отображайте сообщение о некорректном заполнении поля, пока пользователь не закончил ввод;
— Иногда можно добавить индикатор корректного заполнения поля. Пользователь будет видеть прогресс и радоваться позитивной обратной связи;
— Если форма разделена на несколько шагов, показывайте пользователю ключевую информацию с уже пройденных шагов;
— Не отображайте такие формы в маленьких всплывающих окнах.

https://ux.pub/podrobnoe-rukovodstvo-po-dizaynu-tekstovyh-poley-i-form/

Кирилл Славецкий написал, как слепота невнимания и слепота к изменениям влияют на взаимодействие с интерфейсом и как с ними бороться.

Между этими эффектами есть разница. Способы борьбы с ними различаются и иногда противоречат друг другу.

Слепота невнимания — заметный объект, попавший в поле зрения, может остаться полностью незаметным для наблюдателя, если его внимание занято другими объектами и событиями, принятием решений или обработкой данных. (Знаменитый эксперимент с невидимой гориллой).

Так можно не заметить всплывающих сообщений или уведомлений, сосредоточившись на задаче и связанном с ней участке экрана.

Уровень подготовки пользователя на эффект особо не влияет.

Чем вызывается: объект малозаметен, находится далеко от фокуса внимания; наблюдатель не знаком с объектом, не ожидает его увидеть в этом контексте, невнимателен (например, устал), сильно нагружен текущей задачей.

Слепота к изменениям — наблюдатель плохо замечает изменения, если они происходят одновременно с прерыванием фиксации взгляда на сцене (например, одновременно со сменой ракурса в кино).

В интерфейсе так можно не заметить изменений, отвлёкшись на другую задачу, переходя с экрана на экран, переводя взгляд с одной части экрана на другую, моргая.

Чем вызывается: работа с несколькими мониторами, переключение между экраном и другими контекстами, отвлечение на клавиатуру (слабые навыки печати или использование экранной клавиатуры), появление модальных окон.

https://medium.com/slavetski/e18ff53bace5

Пабло Стэнли поделился вредными советами, как стать выдающимся лидером в сфере дизайна. Ироничное выступление — то что надо для маленькой пятницы.

Один из советов — сбивайте ваших коллег с толку профессиональным жаргоном.

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

Чем больше специальных терминов вы используете, тем меньше вам придётся обосновывать своё собственное дизайнерское мышление.

Запишите несколько жаргонизмов:
— Аффорданс;
— Карта эмпатии;
— Карточная сортировка — как ни странно, означает именно сортировку карт;
— MVP — это используют менеджеры проектов, чтобы уничтожить ваш дизайн;
— Карта пользовательского пути…

Почему мы так повернулись на этих картах, может быть, мы потерялись?»

https://www.youtube.com/watch?v=CT1PE5FruNM

Вадим Митякин выложил третью главу своей книги о создании цифровых продуктов — о возможности точной оценки сроков и бюджета.

Процесс создания цифровых продуктов в корне отличается от любой традиционной деятельности. Успех проекта зависит от того, насколько удастся побороть фактор неопределённости.

В главе разбираются источники неопределённости и подходы, с помощью которых её можно контролировать. Текст можно показывать заказчикам, чтобы объяснить, как лучше строить работу и избежать традиционных проблем.

«Необходимо перестать считать всех, кто работает в ИТ-отрасли, „программистами“. Это всё равно, что считать всех, кто занимается возведением зданий, „строителями“. Также необходимо отказаться от мысли, что программисты отличаются друг от друга „сообразительностью“ и при её достаточном уровне способны решить любые задачи. И наконец, не стоит рассчитывать, что программистам можно поставить задачу, просто „объяснив на пальцах“».

Почему сложную систему нельзя построить с нуля: «Компаниям стоит смотреть на цифровые сервисы как на истории, которые они рассказывают своим клиентам и сотрудникам. А хорошие истории невозможно быстро придумать, к тому же не узнав поближе тех, кому они адресованы. Для этого нужно время, внимательное отношение и диалог друг с другом».

https://mityakin.ru/paranoid-method-book-03

Некоторые тезисы и цитаты из 3-й главы книги Вадима Митякина, о которой написал ранее:

— Причины провала цифрового проекта не всегда очевидны.
— Бизнес уверен, что привлёк плохих разработчиков, а они уверены, что бизнес нечётко поставил задачи, выделил мало времени и денег. Все они отчасти правы.
— В начале, когда о проекте известно меньше всего, проблематично спланировать работы и рассчитать бюджет.
— Создание цифровых продуктов отличается от традиционных услуг степенью неопределённости.
— В начале есть только ожидание того, как проект повлияет на бизнес, и иногда смутные образы интерфейса.
— Техническое задание не вносит ясности, так как обычно оно таковым не является.
— Всё, что произойдёт в проекте, зависит от его участников и их способности разобраться, что же нужно получить в итоге.
— Создание нового продукта — создание одновременно и карты (представление о будущем продукте, проектная документация, дизайн, программный код), и территории (готовый продукт).
— Ключевой вопрос — кто платит за риск.
— Закон Галла: «Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде. Из-за неизвестности вы никогда не сможете предсказать все эти связи и переменные, а следовательно, будете постоянно сталкиваться с различными проблемами».
— Популярный приём переноса риска на бизнес — продавать процесс, а не результат.
— Гибкие методологии в основном не снижают неопределённость, а переносят риск на бизнес.
— В проектах надо снижать или локализовывать неопределённость.
— Она исходит из содержания задач (например, исследовательские задачи, не гарантирующие решения) и организационной стороны проекта (от получения требований до поиска подходящих исполнителей).
— Хорошо, если компании подходит типовой продукт. Плохо, если её бизнес-модель отличается. Тип проекта меняется с «Седины» на «Мозги», и процесс становится непредсказуемым.
— Иногда на вопрос о стоимости нельзя ответить из-за природы процесса создания сложных систем.
— Компания не может постоянно менять модель работы и радикально обновлять используемые инструменты. Проект типа «Мозги» или «Седина» должен завершиться и уступить место проектам типа «Процедуры».
— Ложные цели приводят к запуску проекта неподходящего типа: прорывной продукт вместо доработки существующих инструментов и наоборот.
— Чтобы запустить онлайн-продажи, надо пересмотреть почти все составляющие существующей бизнес-модели. Разработчики веб-сайта не могут решить эти вопросы.
— Для проектов разного типа процедура выбора исполнителей должна отличаться принципиально.
— Если это проект типа «Мозги», бизнес должен заинтересовать им потенциальных исполнителей.
— Если это «Процедуры», обязательно наличие подробного технического задания.
— Надо не только привлекать правильных специалистов, но и задавать правила и строить работу так, чтобы у каждого участника был мотив и возможность реализовать свой потенциал.
— Руководители должны участвовать в принятии важных решений на протяжении всего проекта, чтобы неопределённость не накапливалась скрытно.
— Опасный источник неопределённости — отсутствие сильного лидера проекта.
— При переходе незримой границы сложности невозможно создать продукт без предварительного проектирования.
— Начинающие разработчики и просто дилетанты, современная модель обучения, готовящая узких специалистов, непонимание, чем является проектирование, — всё это подпитывает скептическое отношение к проектной документации.
— В результате современные методы создания продуктов больше напоминают модные диеты, основанные на предрассудках, чем полноценные системы питания.
— Чем тщательнее к своей работе подходят проектировщики интерфейсов, тем чаще сталкиваются с тем, что реализовать всё задуманное не получается.
— Для кого-то это может показаться странным, но проектирование сокращает бюджет и сроки проекта.

— Проектирование — поиск наиболее подходящего способа реализации системы, которая решает задачи бизнеса. Если задачи не сформулированы, то проектирование не даст результата.