Не знаю, как пропустил ваш вопрос О_о Для прототипов я использую Axure 8. Иногда приходится иметь дело с Фигмой. Для проектной документации (функциональные требования и функциональные спецификации) — гугл.доки. Картинки — это один из лучших способов передать информацию о том, что нужно сделать. Но без документов, описывающих логику работы, может возникнуть много вопросов.
Я тут как раз и подразумевал свод правил, используя слово «фреймворк». На самом деле сам же, получается, и нарушил свои правила: использовал термин, который не всем будет понятен, и не расшифровал его. Поправил этот момент, спасибо!
Можно делать выводы по себе, это один из подходов. В моём случае — это называется «экспертный аудит без привлечения респондентов». Более того, во многих случаях он оправдан. Например, вполне возможно, что вы правы, и действительно любой владелец СС знает своё поколение.
Я же, не являясь владельцем СС, всё-таки понаблюдал бы за людьми. Возможно, какой-нибудь молодой человек, не особо интересующийся машинами и получивший СС в наследство от родителей, не сможет ответить на вопрос, какого года машина и какие там были поколения. Или девушка, которой кто-то сделал такой дорогой и приятный подарок. Но это я фантазирую. Вполне возможно, окажется, что часть владельцев не интересовались историей автомобиля просто потому что не интересовались.
И, получается, статья не про другое. Она как раз про это. Так что спасибо за комментарий!
Воу, это было неприятно. Мне кажется, что одна из самых важных штук в общении — узнать контекст и детали, а уже потом делать выводы.
Например, как вы выразились, «программеры-рукожопы». Я аудировал сайт мирдворников.ру, я его не разрабатывал. Программером-рукожопом, получается, вы называете автора этого проекта. Сегодня он генеральный директор этой компании, а в 2009 году, да, своими руками делал интерфейс. Вот даже можно на веб-архиве убедиться, что именно этот элемент интерфейса появился 16 лет назад (https://web.archive.org/web/20100109111232/https://www.mirdvornikov.ru/) и с тех пор не сильно поменялся.
Чел, который «с умным видом рассказывает, как ему плевать на мнение пользователя» — это я, UX-дизайнер, а не разработчик. И моя задача — не «сделать тяп-ляп» интерфейс, а провести аудит существующего интерфейса, чтобы порекомендовать его улучшения. И суть статьи в том, что я сначала рекомендую исправлять те вещи, которые мешают пользователям достигать целей. А не те, которые кажутся им неудобными или некрасивыми. Кстати, иногда совпадает так, что это одни и те же вещи. Но это редко.
Вы сравниваете себя с профильным фронтендером, но, получается, что сайт делал не профильный фронтендер. И делал 16 лет назад. Возможно, это и будет ответом на вопрос «почему» вы сделали так, а в этом проекте сделано иначе.
Согласен, конечно делать надо всё нормально сразу. Если бы так делали, то моя услуга по аудиту и не нужна бы была, верно?
На самом деле вы своим комментарием поднимаете гораздо больше тем. Например, должен ли клиент, который действительно нанимает разработчиков, разбираться в их работе достаточно хорошо, чтобы замечать ошибки и обращать на них внимание?
Или вот, например, «найти хороший пакет для фильтра с поиском». У меня была история, когда я в собственный стартап встраивал визуальный редактор для текста. И думаете разрабы мне предложили несколько вариантов на выбор и проконсультировали, какой из них подойдёт в моём случае? Нет, как раз они использовали тот, с которым однажды работали в прошлом. Правильный ли это подход? И вообще — их ли это задача и зона ответственности?
Где-то разработчики принимают все эти решения самостоятельно, где-то они делают ровно то, что их попросили на основе проектной документации, прототипов и макетов в Фигме. Где-то проект делается для себя своими руками. Везде будут разные подходы и истории.
Вот вы свой проект в пример ставите. А мы же о нём ничего не знаем. Это тоже что-то коммерческое с тысячами покупателей? Вы его тоже делали в 2009-м и нашли нужное решение в те времена? Какими бы ни были ваши ответы — они и будут самым интересным и полезным в беседе. И, собственно, основой для этой самой беседы.
Мы прямо сейчас находимся на странице с примером. Под статьёй — список комментариев. Под списком комментариев — форма добавления нового комментария. Если поставить в неё автофокус, то страница будет автоматически быстро пролистываться до формы, мешая вам читать статью.
А так-то вы правы — на десктопе автофокус в первом поле действительно чаще помогает, чем мешает. И если бы форма располагалась сразу в первом экране (и это был бы десктоп, плюс в силе все те нюансы, которые я перечислил в статье), я бы, скорее всего, сам поставил автофокус.
Но если форма, например, находится внизу длинной страницы, автофокус может неожиданно перехватывать управление и мешать дочитать текст до конца. Важно не то, что он чаще помогает — важно, что вариант без автофокуса безопаснее в большем числе контекстов.
Спасибо вам — благодаря вашему комментарию и моему ответу я понял, что в статье не хватало этого нюанса, и дополнил её. Статья стала лучше.
Если форма находится внизу страницы из трёх экранов (например, на лендинге с формой захвата в конце), вы же не будете слать лучи неодобрения тем, кто не поставит автофокус в её первое поле?
Думаю, у нас с вами получилось разное восприятие намерений статьи, и я бы хотел пояснить.
Цель публикации — не в том, чтобы защищать собственный дизайн или указывать, как именно нужно оценивать чужую работу. Речь не о том, что кто-то неправ. И не о том, чтобы поучать читателей.
Я постарался составить список факторов, которые могут влиять на восприятие интерфейса, если вы смотрите на него по скриншоту, вне контекста использования. Это наблюдение из практики — не более того. Я не ставлю под сомнение право на мнение, а лишь напоминаю, что итоговая оценка может быть неполной, если не учитывать некоторые параметры.
Что касается моего дизайна — он указан в подводке с комментарием «статья вообще не о моём дизайне». И да, статья не о нём. Просто на статью навёл мой ответ к комментарию из прошлой статьи — и я решил, что из этого будет удачная подводка. А ещё даже если бы речь всё же шла о критике моей работы — в этом не было бы ничего плохого. Важнее всего то, что клиент остался доволен результатом и дизайн решает свою задачу.
Понимаю, откуда такая реакция — если воспринимать статью как попытку защитить конкретный простой экран, то список действительно может показаться избыточным.
Но на самом деле я говорил не столько про этот экран, сколько про общий подход к критике интерфейсов по скриншоту. Хотелось показать, как много факторов может оставаться за кадром — и что иногда вместо мгновенного вердикта полезнее сначала задать пару уточняющих вопросов.
Иногда за кажущейся простотой — довольно интересные и неоднозначные решения :)
«Любая текстура под текстом — зло» — звучит категорично :)
На самом деле всё, как обычно, зависит от контекста. В этом случае я специально обсудил с клиентом, насколько важна читаемость этих индикаторов — и выяснил, что они носят почти декоративный характер, а читают их крайне редко. Поэтому решили не усложнять задачу подбором отдельных цветов и оставить всё как есть: лаконично, аккуратно, без визуального шума.
Если бы это была рабочая информация — конечно, никаких текстур под текстом не было бы. Но «всегда зло» — это, пожалуй, перебор.
Спасибо за комментарии! Рад, что в целом стало лучше.
Особенно понравился пятый пункт про батарейку. Три уровня заряда действительно выглядят скудно, но за этим стоит интересная техническая подоплёка.
Например, во многих устройствах (включая, например, мою старую беззеркалку Sony A7R2) тоже всего три деления — и я всё недоумевал, почему так. Оказалось, что это не просто прихоть дизайнеров. Всё дело в том, что определить заряд батареи точно довольно сложно. Есть несколько методов: по напряжению, по подсчёту кулонов, с помощью фильтра Калмана и даже нейросетей — но ни один не даёт стопроцентной точности.
Чтобы сделать иконку батареи, которая выглядит просто, но при этом не вводит пользователя в заблуждение, нужно учитывать, насколько надёжны данные в конкретном устройстве. Например, в дешёвых гаджетах часто используют самый простой метод — по напряжению. Его точность может колебаться в пределах плюс-минус 10–20%, а под нагрузкой уровень заряда может прыгать ещё сильнее.
Я потому и выбрал именно три (на самом деле четыре) условных уровня, чтобы не создавать иллюзию точности там, где её нет. Да, выглядит упрощённо — но зато не обманывает.
Кстати, всё это — ещё один повод задуматься, как глубоко «железо» влияет на интерфейс. И как важно учитывать не только эстетику, но и механику получения данных.
Ну а статья как раз про это — про то, как легко ошибиться в оценке, глядя только на скриншот. И почему перед критикой стоит сначала задать пару вопросов :)
Чтобы числа в интерфейсе не «скакали» при изменении значений. Это особенно важно для приёмопередатчиков: частоты, уровни сигнала, временные метки и другие параметры меняются постоянно, и при использовании пропорционального шрифта текст бы дёргался на глазах у пользователя. А так всё стабильно и читаемо.
Можно было бы выбрать пару шрифтов: один для чисел, другой для текстов. Но посмотрели на то, что получилось, и решили, что и этот один неплохо смотрится.
Было бы очень интересно узнать, откуда у вас появилось такое ощущение. Ни один из моих предшественников не нарисовал ни одного варианта и не предоставил ни одного КП. Как эта планка может быть понижена?
Итоговый вариант в единственной цветовой гамме. Если в будущем возникнет желание «примерить» на него другие варианты, это делается за десять минут на стилях и их переменных.
Пока ничего, я только 8 июля сдал работу. Но вам верно ответили: каких-то особенных отличий от веба нет. Разве что будут чаще использоваться битмапы в качестве подложек. Плюс используется LVGL библиотека, которая, например, не позволяет задавать полупрозрачность для градиентов. Вы всё это можете посмотреть самостоятельно в коде проекта на Гитхабе.
Чтобы оценить размер, контрастность и читаемость, вам необходимо понимать следующие параметры:
— Физический размер устройства; — PPI дисплея устройства; — Тип матрицы дисплея устройства (его цветопередачу, контрастность, время отклика и прочие параметры); — Номинальную яркость дисплея устройства и её различные вариации.
По картинкам из статьи, на которые вы смотрите со своего монитора или телефона, вы не сможете определить, как будет выглядеть тот или иной дизайн на том или ином устройстве.
Обратите внимание на пассаж из статьи: «Например, можно будет ещё «примерить» дизайн к живому устройству — и если будут какие-то проблемы с яркостью или контрастом — подкорректировать цветовую схему».
—— А, чуть не забыл. Ещё один важный параметр, который нужно учитывать — это предполагаемое расстояние от глаз пользователя до дисплея устройства в распространённом сценарии использования.
Написал всё это и чувствую, что это неплохая тема для статьи. А то часто сталкиваюсь с ситуациями, когда дизайнеры дают обратную связь по работе других дизайнеров, не учитывая все или часть из этих параметров.
Прикол. Это скриншоты из чата проекта.
А это из нового чата, не связанного с проектами:
Видимо, какой-то непонятный частный случай.
Ух ты! Интересно, как это понимать?
Не знаю, как пропустил ваш вопрос О_о
Для прототипов я использую Axure 8. Иногда приходится иметь дело с Фигмой.
Для проектной документации (функциональные требования и функциональные спецификации) — гугл.доки.
Картинки — это один из лучших способов передать информацию о том, что нужно сделать.
Но без документов, описывающих логику работы, может возникнуть много вопросов.
Я тут как раз и подразумевал свод правил, используя слово «фреймворк». На самом деле сам же, получается, и нарушил свои правила: использовал термин, который не всем будет понятен, и не расшифровал его. Поправил этот момент, спасибо!
Можно делать выводы по себе, это один из подходов. В моём случае — это называется «экспертный аудит без привлечения респондентов». Более того, во многих случаях он оправдан. Например, вполне возможно, что вы правы, и действительно любой владелец СС знает своё поколение.
Я же, не являясь владельцем СС, всё-таки понаблюдал бы за людьми. Возможно, какой-нибудь молодой человек, не особо интересующийся машинами и получивший СС в наследство от родителей, не сможет ответить на вопрос, какого года машина и какие там были поколения. Или девушка, которой кто-то сделал такой дорогой и приятный подарок. Но это я фантазирую. Вполне возможно, окажется, что часть владельцев не интересовались историей автомобиля просто потому что не интересовались.
И, получается, статья не про другое. Она как раз про это. Так что спасибо за комментарий!
Воу, это было неприятно. Мне кажется, что одна из самых важных штук в общении — узнать контекст и детали, а уже потом делать выводы.
Например, как вы выразились, «программеры-рукожопы». Я аудировал сайт мирдворников.ру, я его не разрабатывал. Программером-рукожопом, получается, вы называете автора этого проекта. Сегодня он генеральный директор этой компании, а в 2009 году, да, своими руками делал интерфейс. Вот даже можно на веб-архиве убедиться, что именно этот элемент интерфейса появился 16 лет назад (https://web.archive.org/web/20100109111232/https://www.mirdvornikov.ru/) и с тех пор не сильно поменялся.
Чел, который «с умным видом рассказывает, как ему плевать на мнение пользователя» — это я, UX-дизайнер, а не разработчик. И моя задача — не «сделать тяп-ляп» интерфейс, а провести аудит существующего интерфейса, чтобы порекомендовать его улучшения. И суть статьи в том, что я сначала рекомендую исправлять те вещи, которые мешают пользователям достигать целей. А не те, которые кажутся им неудобными или некрасивыми. Кстати, иногда совпадает так, что это одни и те же вещи. Но это редко.
Вы сравниваете себя с профильным фронтендером, но, получается, что сайт делал не профильный фронтендер. И делал 16 лет назад. Возможно, это и будет ответом на вопрос «почему» вы сделали так, а в этом проекте сделано иначе.
Согласен, конечно делать надо всё нормально сразу. Если бы так делали, то моя услуга по аудиту и не нужна бы была, верно?
На самом деле вы своим комментарием поднимаете гораздо больше тем. Например, должен ли клиент, который действительно нанимает разработчиков, разбираться в их работе достаточно хорошо, чтобы замечать ошибки и обращать на них внимание?
Или вот, например, «найти хороший пакет для фильтра с поиском». У меня была история, когда я в собственный стартап встраивал визуальный редактор для текста. И думаете разрабы мне предложили несколько вариантов на выбор и проконсультировали, какой из них подойдёт в моём случае? Нет, как раз они использовали тот, с которым однажды работали в прошлом. Правильный ли это подход? И вообще — их ли это задача и зона ответственности?
Где-то разработчики принимают все эти решения самостоятельно, где-то они делают ровно то, что их попросили на основе проектной документации, прототипов и макетов в Фигме. Где-то проект делается для себя своими руками. Везде будут разные подходы и истории.
Вот вы свой проект в пример ставите. А мы же о нём ничего не знаем. Это тоже что-то коммерческое с тысячами покупателей? Вы его тоже делали в 2009-м и нашли нужное решение в те времена? Какими бы ни были ваши ответы — они и будут самым интересным и полезным в беседе. И, собственно, основой для этой самой беседы.
Мы прямо сейчас находимся на странице с примером. Под статьёй — список комментариев. Под списком комментариев — форма добавления нового комментария. Если поставить в неё автофокус, то страница будет автоматически быстро пролистываться до формы, мешая вам читать статью.
А так-то вы правы — на десктопе автофокус в первом поле действительно чаще помогает, чем мешает. И если бы форма располагалась сразу в первом экране (и это был бы десктоп, плюс в силе все те нюансы, которые я перечислил в статье), я бы, скорее всего, сам поставил автофокус.
Но если форма, например, находится внизу длинной страницы, автофокус может неожиданно перехватывать управление и мешать дочитать текст до конца.
Важно не то, что он чаще помогает — важно, что вариант без автофокуса безопаснее в большем числе контекстов.
Спасибо вам — благодаря вашему комментарию и моему ответу я понял, что в статье не хватало этого нюанса, и дополнил её. Статья стала лучше.
Если форма находится внизу страницы из трёх экранов (например, на лендинге с формой захвата в конце), вы же не будете слать лучи неодобрения тем, кто не поставит автофокус в её первое поле?
Я исхожу вот из чего: если рекомендация не навредит в большем количестве сценариев — она более универсальна.
Да, известная проблема. Причём, часто даже не забывают про скролл, а делают его по-дизайнерски тонким и незаметным.
Представь форму, где собирают email и телефон. Обязательно для заполнения одно любое из них.
Думаю, у нас с вами получилось разное восприятие намерений статьи, и я бы хотел пояснить.
Цель публикации — не в том, чтобы защищать собственный дизайн или указывать, как именно нужно оценивать чужую работу. Речь не о том, что кто-то неправ. И не о том, чтобы поучать читателей.
Я постарался составить список факторов, которые могут влиять на восприятие интерфейса, если вы смотрите на него по скриншоту, вне контекста использования. Это наблюдение из практики — не более того. Я не ставлю под сомнение право на мнение, а лишь напоминаю, что итоговая оценка может быть неполной, если не учитывать некоторые параметры.
Что касается моего дизайна — он указан в подводке с комментарием «статья вообще не о моём дизайне». И да, статья не о нём. Просто на статью навёл мой ответ к комментарию из прошлой статьи — и я решил, что из этого будет удачная подводка. А ещё даже если бы речь всё же шла о критике моей работы — в этом не было бы ничего плохого. Важнее всего то, что клиент остался доволен результатом и дизайн решает свою задачу.
Спасибо, что поделились мнением.
Понимаю, откуда такая реакция — если воспринимать статью как попытку защитить конкретный простой экран, то список действительно может показаться избыточным.
Но на самом деле я говорил не столько про этот экран, сколько про общий подход к критике интерфейсов по скриншоту. Хотелось показать, как много факторов может оставаться за кадром — и что иногда вместо мгновенного вердикта полезнее сначала задать пару уточняющих вопросов.
Иногда за кажущейся простотой — довольно интересные и неоднозначные решения :)
«Любая текстура под текстом — зло» — звучит категорично :)
На самом деле всё, как обычно, зависит от контекста. В этом случае я специально обсудил с клиентом, насколько важна читаемость этих индикаторов — и выяснил, что они носят почти декоративный характер, а читают их крайне редко. Поэтому решили не усложнять задачу подбором отдельных цветов и оставить всё как есть: лаконично, аккуратно, без визуального шума.
Если бы это была рабочая информация — конечно, никаких текстур под текстом не было бы. Но «всегда зло» — это, пожалуй, перебор.
Спасибо за комментарии! Рад, что в целом стало лучше.
Особенно понравился пятый пункт про батарейку. Три уровня заряда действительно выглядят скудно, но за этим стоит интересная техническая подоплёка.
Например, во многих устройствах (включая, например, мою старую беззеркалку Sony A7R2) тоже всего три деления — и я всё недоумевал, почему так. Оказалось, что это не просто прихоть дизайнеров. Всё дело в том, что определить заряд батареи точно довольно сложно. Есть несколько методов: по напряжению, по подсчёту кулонов, с помощью фильтра Калмана и даже нейросетей — но ни один не даёт стопроцентной точности.
Чтобы сделать иконку батареи, которая выглядит просто, но при этом не вводит пользователя в заблуждение, нужно учитывать, насколько надёжны данные в конкретном устройстве. Например, в дешёвых гаджетах часто используют самый простой метод — по напряжению. Его точность может колебаться в пределах плюс-минус 10–20%, а под нагрузкой уровень заряда может прыгать ещё сильнее.
Я потому и выбрал именно три (на самом деле четыре) условных уровня, чтобы не создавать иллюзию точности там, где её нет. Да, выглядит упрощённо — но зато не обманывает.
Кстати, всё это — ещё один повод задуматься, как глубоко «железо» влияет на интерфейс. И как важно учитывать не только эстетику, но и механику получения данных.
Ну а статья как раз про это — про то, как легко ошибиться в оценке, глядя только на скриншот. И почему перед критикой стоит сначала задать пару вопросов :)
Чтобы числа в интерфейсе не «скакали» при изменении значений. Это особенно важно для приёмопередатчиков: частоты, уровни сигнала, временные метки и другие параметры меняются постоянно, и при использовании пропорционального шрифта текст бы дёргался на глазах у пользователя. А так всё стабильно и читаемо.
Можно было бы выбрать пару шрифтов: один для чисел, другой для текстов. Но посмотрели на то, что получилось, и решили, что и этот один неплохо смотрится.
Было бы очень интересно узнать, откуда у вас появилось такое ощущение. Ни один из моих предшественников не нарисовал ни одного варианта и не предоставил ни одного КП. Как эта планка может быть понижена?
Итоговый вариант в единственной цветовой гамме. Если в будущем возникнет желание «примерить» на него другие варианты, это делается за десять минут на стилях и их переменных.
Пока ничего, я только 8 июля сдал работу. Но вам верно ответили: каких-то особенных отличий от веба нет. Разве что будут чаще использоваться битмапы в качестве подложек. Плюс используется LVGL библиотека, которая, например, не позволяет задавать полупрозрачность для градиентов. Вы всё это можете посмотреть самостоятельно в коде проекта на Гитхабе.
Чтобы оценить размер, контрастность и читаемость, вам необходимо понимать следующие параметры:
— Физический размер устройства;
— PPI дисплея устройства;
— Тип матрицы дисплея устройства (его цветопередачу, контрастность, время отклика и прочие параметры);
— Номинальную яркость дисплея устройства и её различные вариации.
По картинкам из статьи, на которые вы смотрите со своего монитора или телефона, вы не сможете определить, как будет выглядеть тот или иной дизайн на том или ином устройстве.
Обратите внимание на пассаж из статьи:
«Например, можно будет ещё «примерить» дизайн к живому устройству — и если будут какие-то проблемы с яркостью или контрастом — подкорректировать цветовую схему».
——
А, чуть не забыл. Ещё один важный параметр, который нужно учитывать — это предполагаемое расстояние от глаз пользователя до дисплея устройства в распространённом сценарии использования.
Написал всё это и чувствую, что это неплохая тема для статьи. А то часто сталкиваюсь с ситуациями, когда дизайнеры дают обратную связь по работе других дизайнеров, не учитывая все или часть из этих параметров.