Как пример именно работы с репитером — хорошо.
Как пример с работой по таблицей — мне кажется не очень хорошим этот пример.
Прототип выше не отвечает на вопросы:
— Почему нет поиска и кому нужна таблица без поиска;
— Поиск серверный или клиентский должен быть?
— Какая она будет, если элементы не найдены;
— Какая она будет, если элементов пока нет;
— Как будет выглядеть 100500 элементов — автоматическая подгрузка при скроле или пагер?
Плюс некоторые замечания:
— Зачем нужна сортировка по полу? Здесь фильтр нужен.
— Нет визуальной индикации по каким столбцам можно сортировать;
— Почему телефонный номер в разном формате?
— Не отображён фильтр по дате и какую разметку в нём лучше сделать: Сегодня \ Вчера \ За прошлую неделю \ Месяц \ Кастомный период (и правила указания диапазона дат);
— Ну и всякая вкусовщина, а ля пол можно иконкой и рядом с возрастом, черезполосица не нужна :)
Я хочу донести, что такой прототип не отвечает на вопрос «Как должна вести себя таблица в интерфейсе», а лишь показывает работу с репитером в Axure.
Пока они не перестанут искать UX-дизайнеров, которые должны выдавать качественную вёрстку, этот момент вряд ли станет лучше. Но статья не про юзабилити всё-таки, эти притензии надо другим людям адресовывать -)
Рассказ хороший, сам прошёл примерный путь.
Добавил бы чуть больше буков о команде разработчиков, с которыми дизайнер будет постоянно общаться.
— Если в студии процесс линеен — дизайн разработчики уже увидели утверждённый, то в продуктовой компании на этапе концепта\ранних скетчей уже обязателен тимлид разработчиков.
— Фактор времени: все понимают, что дизайн решение отличное, но надо на него чуть больше времени. Поэтому проектируется ещё одна промежуточная версия. Чуть позже достроим (и достроим). В этом случае дизайнер одновременно держит в голове около трёх версий одной задачи:
1. Попроще чтобы вот сейчас;
2. Нормальная (по требованиям);
3. Идеальная (или близко к этому).
Немного не понял из эпилога,
как отступы и иконки решают проблемы пользователя?
Хочу сказать, что советы правильные, но не для проектировщика, а для UI-дизайнера (=технического дизайнера).
При проектировании вообще нужно забить на всё это и заниматься именно решением проблем людей, которые столкнуться с интерфейсом. А вот когда интерфейс спроектирован, при «раскраске» эти советы имеют смысл.
Я бы добавил ещё к советам кратность размеров шрифта (заголовки N уровней, основной текст и т.п. кратны какому-либо числу).
И не согласен с иконками — если иконка не отображается смысла подписи, то от неё можно избавиться, т.к. она только отвлекает внимание.
Небольша путанция в заголовках статьи, либо в самой статье мне показалась:
Может сложится впечатление, что при только в Data driven (=Data Centered Design) дизайне появляются новые должности, что не так, в принципе сфера расширяется, это не зависит от пути (user-CD, customer-CD, system-CD).
В целом общего посыла не нашёл)
Что меня самого беспокоит в целом в этом подходе, так тот факт, что берем в расчет только числа.
Ну узнали, что при переходе теряется N% людей, дальше ещё M%, а почему они отваливаются — ответа нет. Мы можем отследить поведение на экране, но о чем думает, какие цели, какая обстановка у человека — не всегда понятно.
Много хороших пунктов, как-то итеративность процесса, эмоциональность сервиса, про это забывают.
Извините, что вмешиваюсь, но вы противоречите немного насчет страйкбола:
Начальный комплект в 6-7 тысяч никак не коррелируется с игрой по афганистану, представленная вами, где талибы шьют костюмы себе сами, либо под заказ, а контингент НАТО в полной снаряге, которая стоит 50к+ просто за реплику (оригинал в 2-4 раза дороже).
Плюс не забываем, что аппетиты растут и на сезон другой уже будешь выбирать себе ПНВ и ИК-лазерами, а затем военные тепловизоры пойдут в кладовке дома…
А мне видится другая причина трудности улучшений почты — это копание в песочнице.
Построил башенку, другую, покрасивее и ничего нового.
Только тактические улучшения в основной массе делаются, стратегии почти нет.
У меня сейчас несколько мессенжеров на телефоне, несколько ящиков с почтой, пара аккаунтов в соц сетях — всё оно для общения.
И везде есть аккаунты. Их надо помнить. Но есть хорошая тенденция приравнивать аккаунт к почте.
Давайте немного пофантазируем: что если так и останется?
Интернет всё доступнее, аккаунт есть email, а значит на почту звонить будем, продукты оплачивать оттуда же, фоточку прислать бабушке, не задумываясь, какую программку поставить надо. Даёшь единый контроль!
Может email ровнять на соц ID! (утопия.jpg)
Интересно появится ли такой здоровый агрегатор информации?
Как пример с работой по таблицей — мне кажется не очень хорошим этот пример.
Прототип выше не отвечает на вопросы:
— Почему нет поиска и кому нужна таблица без поиска;
— Поиск серверный или клиентский должен быть?
— Какая она будет, если элементы не найдены;
— Какая она будет, если элементов пока нет;
— Как будет выглядеть 100500 элементов — автоматическая подгрузка при скроле или пагер?
Плюс некоторые замечания:
— Зачем нужна сортировка по полу? Здесь фильтр нужен.
— Нет визуальной индикации по каким столбцам можно сортировать;
— Почему телефонный номер в разном формате?
— Не отображён фильтр по дате и какую разметку в нём лучше сделать: Сегодня \ Вчера \ За прошлую неделю \ Месяц \ Кастомный период (и правила указания диапазона дат);
— Ну и всякая вкусовщина, а ля пол можно иконкой и рядом с возрастом, черезполосица не нужна :)
Я хочу донести, что такой прототип не отвечает на вопрос «Как должна вести себя таблица в интерфейсе», а лишь показывает работу с репитером в Axure.
Добавил бы чуть больше буков о команде разработчиков, с которыми дизайнер будет постоянно общаться.
— Если в студии процесс линеен — дизайн разработчики уже увидели утверждённый, то в продуктовой компании на этапе концепта\ранних скетчей уже обязателен тимлид разработчиков.
— Фактор времени: все понимают, что дизайн решение отличное, но надо на него чуть больше времени. Поэтому проектируется ещё одна промежуточная версия. Чуть позже достроим (и достроим). В этом случае дизайнер одновременно держит в голове около трёх версий одной задачи:
1. Попроще чтобы вот сейчас;
2. Нормальная (по требованиям);
3. Идеальная (или близко к этому).
как отступы и иконки решают проблемы пользователя?
Хочу сказать, что советы правильные, но не для проектировщика, а для UI-дизайнера (=технического дизайнера).
При проектировании вообще нужно забить на всё это и заниматься именно решением проблем людей, которые столкнуться с интерфейсом. А вот когда интерфейс спроектирован, при «раскраске» эти советы имеют смысл.
Я бы добавил ещё к советам кратность размеров шрифта (заголовки N уровней, основной текст и т.п. кратны какому-либо числу).
И не согласен с иконками — если иконка не отображается смысла подписи, то от неё можно избавиться, т.к. она только отвлекает внимание.
Может сложится впечатление, что при только в Data driven (=Data Centered Design) дизайне появляются новые должности, что не так, в принципе сфера расширяется, это не зависит от пути (user-CD, customer-CD, system-CD).
В целом общего посыла не нашёл)
Что меня самого беспокоит в целом в этом подходе, так тот факт, что берем в расчет только числа.
Ну узнали, что при переходе теряется N% людей, дальше ещё M%, а почему они отваливаются — ответа нет. Мы можем отследить поведение на экране, но о чем думает, какие цели, какая обстановка у человека — не всегда понятно.
Много хороших пунктов, как-то итеративность процесса, эмоциональность сервиса, про это забывают.
Начальный комплект в 6-7 тысяч никак не коррелируется с игрой по афганистану, представленная вами, где талибы шьют костюмы себе сами, либо под заказ, а контингент НАТО в полной снаряге, которая стоит 50к+ просто за реплику (оригинал в 2-4 раза дороже).
Плюс не забываем, что аппетиты растут и на сезон другой уже будешь выбирать себе ПНВ и ИК-лазерами, а затем военные тепловизоры пойдут в кладовке дома…
все эти Ивановы Иваны Иванычи и прочие Путины.
Поэтому совет: используйте более живые имена. Приятней будет, точно вам говорю.
Любой имягенератор даст эту возможность (пример например).
Построил башенку, другую, покрасивее и ничего нового.
Только тактические улучшения в основной массе делаются, стратегии почти нет.
У меня сейчас несколько мессенжеров на телефоне, несколько ящиков с почтой, пара аккаунтов в соц сетях — всё оно для общения.
И везде есть аккаунты. Их надо помнить. Но есть хорошая тенденция приравнивать аккаунт к почте.
Давайте немного пофантазируем: что если так и останется?
Интернет всё доступнее, аккаунт есть email, а значит на почту звонить будем, продукты оплачивать оттуда же, фоточку прислать бабушке, не задумываясь, какую программку поставить надо.
Даёшь единый контроль!Может email ровнять на соц ID! (утопия.jpg)
Интересно появится ли такой здоровый агрегатор информации?
Тринадцать этапов и два этапа. Одиннадцать разница.
На самом деле имеет место обощение одного и усложнение второго процессов.
Сделали акцент на проблемах при работе с цифровым интерфейсом, но неужели нет проблем в реальном мире?