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

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

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

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

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

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

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

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

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

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

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

Это маска.

Т.е. верхний слой имеет форму нижнего.
Вот пример:
я выше положил свой с кругом и дал ему маску в виде нижнего слоя с квадратом. Делается это, если нажать alt между этими слоями -)

Привет!
Решение очень простое:
зайди в Preferences (ctrl+k) и на табе General и сними галочку Resize image during place :)

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

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

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

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

Привет!
Уже хорошо, что ты определился с направлением фотографии, отметает многое.
Но дальше надо бы узнать — а как вы собираетесь снимать пейзажи?
Одно дело взять средненькую зеркалку и ждать красивых снимков, другое дело читать мат часть по цветам, композиции и советы по сьёмки, т.е. именно заниматься этим.

В первом случае берем 600д и не паримся.
Во втором случае я бы посоветовал взять самую дешевую тушку, хороший светлый ширик (tokina 11-16 например) и хороший тяжелый штатив.

Почему самую дешевую? Быстрее разберешься что именно не хватает и какие настройки бывают.
Для меня было открытие, что боже мой есть брекетинг, как это удобно, как я без этого жил! Но для этого надо понять зачем это нужно и как это использовать. Покупать комбайн и использовать 20% от него — сомнительный выбор.
Тяжёлый штатив обязателен — сколько раз у меня старый китайский чуть не сносило течением\ветром.
Ну и не забывать про путешествия, подъём ради кадров в 5 утра — нетривиальное время и обстановка есть залог успеха пейзажей.

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

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

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

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

Надо на событие Show/Hide выбрать опцию Toggle:

Есть подозрение, что вы не понимаете для чего и что такое 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+ часов).

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