Никита Гарейшин

Привет,
обычно этот стиль называют FUI: Future или Futuristic User Interface.

Подборку веду даже на бехансе и пополняю её:
https://www.behance.net/collection/25329517/Future...

Привет, немного знаю про таблицы.
Опускаем вопрос точно ли таблица нужна и перейдём сразу к данным.

Важно для начала понять, какой флоу у человека при работе с таблицей: это поиск, модерация, редактирование или менеджемент объектов? От главной задачи зависит дизайн таблицы, например,
- Если задача поиск массива объектов, то акцент на фильтрах, а не таблица.
- Если это редактирование одного объекта, то задача в поиске и быстром переходе к изменению.

В целом я бы посоветовал пойти так:
1. Понять задачу, для которой таблица нужна;
2. Определить самый минимум атрибутов для объекта, которые стоит вынести в таблицу (прекрасно помогает сессия с пользователями);
3. Оптимизировать их, проходясь по каждому: почему дата важна, зачем нужно время и тд, визуально трансформировать и делать индикаторы где уместно.

Под оптимизацией я понимаю такие вещи как аналитика ещё. Пример: было у нас поле симптомов и было это поле изначально textarea, куда забивали всё подряд. Просмотрев большой массив этих значений мы выделили список, превратив поле из 300 символов в 40, что сказалось на ширине исходной таблицы.

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

Не очень прозрачен контекст задания,
но предложу ситуации, для которых совет Михаил Проскурин не очень подойдёт.

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

Если мы наймём «крутого дизайнера», чтобы он ещё раз прошёлся по всему приложению, то это займёт нормально времени клиента. Мы ведь не знаем масштаб продукта, вдруг у товарища готовы основные скрины по генотипированию образцов для вьетнамской лаборатории в спец сфере исследования.

А вот если реально требуется «раскрасить» макеты, создать и описать полноценный кит для системы, не сильно вдаваясь в сценарии - это хорошая работа для технического дизайнера. И опять же нюанс - всю его работу контролировать и проверять должен тот, кто делал исходные макеты.
И стоимость в $1500-2000 за 2-3 недели работы вполне себе неплохая.

По вопросу ТС:
я бы посоветовал искать через знакомых, либо через hh, выделяя интересные резюме.

Привет,
Тут напрашивается дискавери фаза, если есть только список фич.

Для полноценного сервиса, хорошо бы понимать:
- Общий подход к проектированию - для кого создаём? Для покупателя (Customer Centered Design), оператора (System CD), человека с улицы (Human CD), пользователя в целом (User CD) и пр;
- Определить количество ролей, описать их - проблемы, ежедневные задачи, боли и пр (Personas);
- Определиться с методологией производства (Waterfall, Agile и пр);
- Если это существующий процесс, то описать As-Is Workflow для понимая, если нет - описать будущий процесс;
Из этого всего можно прикинуть концепт (Proof of Concept) и смотреть что получается.
Когда будет этот минимум, можно садится и думать над MVP - какой сервис будет, из чего состоять, что делать в первую очередь, а что нет.

Более того, я бы в картах не путал фичи и объекты.
Отобразить товар и управление им - это разные схемки.
Ещё есть экраны, где есть некоторые экраны и некоторые фичи)

Для проработки каждого экрана надо понимать:
- Кто им пользуется;
- Какую проблему мы решаем в данный момент.
Вывалить всё и вся тоже можно - пусть человек сам разбирается, но спасибо вам не скажут)

Насколько я понял, речь про закрытое производство и операторов.
Вывод первый: это профессиональная тула и речи про всякие воронки, конверсии не стоит вести.

Есть возможность найти исходные цели, с которыми проектировалось приложение?
Должны же были удостовериться, что сделали верно. По идеи, оттуда метрики и стоит взять.

Если этого совсем нет, звучит как дискавери фаза - надо заново понять несколько вещей:
1. Кто сказал что интерфейс неудобен? Кто сказал, что есть проблема? Почему её надо решать?
2. Затем - для кого решать? Хорошо, если этот оператор один, но обычно есть супервайзер, а над ним ещё и менеджер, который распределяет нагрузку. Это уже создание и работа с персонами.
3. Экраны - они часть процесса, нужно получить весь процесс. Мы делали целую AS-IS Workflow диаграмму, где искали узкие места и непонятные белые пятна. А это недели работы.
4. Условия работы - операторы могут работать в костюмах биологической защиты с баллонами кислорода и масками, а могут быть на заводе в пыли и температуре +40°С.

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

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

Я считаю без мат части и деталей нормально посоветовать что-то бОльшее сложно будет.

Tour, wizard, steps, etc - это всё инструменты, частные варианты.

Этот процесс называется Onboarding.
Поэтому можно гуглить что-то из серии "web site onboarding best practice"

Behance - для портфолио (смотрите что делал!)
Dribbble - для похвастаться деталями, которые рисуешь (смотрите как я могу!)

Для критики, для позадавать глупые вопросы другим, для всего этого я бы посоветовал
techdesigner.ru (пример поста на критику)

Так ответ в вопросе:

Убрать кучу лишнего функционала, которые не нужен обычным операторам

Идёте к операторам, смотрите как они работают, выписываете ненужный функционал, переделывайте функционал, тестируете, снова переделывайте (повторить нужное количество раз) — ура, готово!

Или только визуальная часть интересна? Стоит учесть, что с удобством тут ничего общего нет, только рюшечки.
В этом случае любые популярные на сегодня работы на Dribbble и Behance например.

Привет!
Если я правильно понял, то для такого поведения меню надо добавить проверку на видимость каждой соответствующей динамической панели.
Т.е. на каждый пункт меню на событие OnMouseEnter создаем проверку Visibility of widget для динамической панели как, например, false и вешаем событие Show MyMenuItem, которая по умолчанию скрыта. Тогда второй кейс для того же OnMouseEnter при условии ElseIfTrue будет Hide MyMenuItem.

И пара нюансов:
- для чего вам пустое состояние? Крайние состояние, такие как пустые и перегрузочные, лучше прорисовывать в конце когда основная архитектура готова и все (=большинство) требований устаканились. А иногда можно и на графического дизайнера это оставить);
- лучше сразу указывать нормальные названия всем состояниям, переменным и состояниям, в будущем запутаться не долго.

Если что-то я криво описал — укажи, переформулирую)

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

Вы пишите про данные во главе угла, затем про наблюдение (видимо за пользователями) — вещи абсолютно разные.

Дело в том, что есть несколько методик разработки интерфейса, одни из них Data Centered Design, где основываемся на данных, без учета людей вообще, например чисто по статистике измеряем эффективность решения, а есть User Centered Design, где все решения идут от человека, за которым следим и на котором тестируем (не на одном само собой, больше разговоров и взаимодействия проектировщика с людьми). Вы же это почему-то равняете к одному знаменателю, это не верно. Совершенно разные подходы.

Есть ещё например Customer Centered Design, System Centered Design.

Почитать про генерацию идей, да, Де Боно норм,
я бы ещё методику Дизайн Мышления посоветовал и Lean UX (хотя по сути тоже самое).

Алексей, тут такое дело — дизайн это не про фотошоп.
Я тоже когда думал, что чем больше уроков по фотошопу я пройду, тем сильнее я дизайнер. Но вот дела обстоят так, что инструмент вторичен.

Теперь кратко — читайте про стратегию (хоть Сунь Цзы), про логику, про мышление людей, да даже строение букв откроет громадные горизонты.
Что читать? Берем грамотного дизайнера с блогом, ищем и вот например подборка — ludwigbistronovsky.ru/books

Там выше увидел, что по интерфейсам есть интерес. Тогда есть рекомендация одна, но для завершения курса вам потребуется ух сколько сил. Дерзайте. Скоро начало курса:
https://www.coursera.org/course/hciucsd

Вот когда будете знать Что рисовать, встанет вопрос Как. Только тогда имеет смысл заглянуть на всякие dribbble & behance.

Юра Ветров хорошо рассказывает о продуктовом дизайнере, вот тут презенташка например:
www.slideshare.net/jvetrau/design-weekend-2014

В первую очередь это стратег, потом уже дизайнер (в простом понимании слова).
Ещё и менеджер ко всему прочему.

Один.
Рассказываю почему — прежде, чем нарисовать что-то в фотошопе, надо выяснить много всего, пройти несколько этапов, а именно:
1. Аналитика — что за фирма, узнать чем живёт, как продаёт, что продаёт и пр.;
2. Прототипирование — хоть на салфетке, но накидать примерную структуру будущего сайта. В идеале интерактивный прототип, если есть сложные формы и под подпись с утверждением;
3. Только сейчас поднимаем тему о цветах и прочей лабуде — показываем примеры, разговариваем много и долго о будущем оформлении, выясняем чем руководствуется человек и как ему помочь в выборе;
4. Рисуем концепт — мы уже не летаем в облаках, а рисуем обговоренный макет (трачу на это не более 7-8 часов);
5. Вносим поправки и дорабатываем детали главной страницы (20+ часов на это закладываю);
6. Рисуем внутренние (20+ часов).

Не надо гадать что понравится, выясните что нужно. Говорите, обсуждайте, зачем эти игры в напёрстки?
Доступно донёс?)