Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

В первой статье разбирается просмотр данных.

1. Рабочая таблица должна занимать максимум места на экране. Как вариант — опция «на весь экран».
2. Объединяйте данные. Если есть данные о фамилии, имени и отчестве, их целесообразно вывести в один столбец ФИО. Должность или роль в системе тоже можно присоединить к ФИО.
3. Бесконечная прокрутка и кнопка «Показать ещё» не подходят для отображения строк таблицы. Делайте постраничную навигацию. Это удобно и для коллективной работы с таблицей.
4. Показывайте по умолчанию больше строк на одной странице: 50, 100, 500.
5. Используйте цветовые индикаторы. Красить строку целиком стоит только при отклонении от нормы.
6. При наличии цветовых индикаторов полезно отображать легенду цветов.
7. Храните пользовательские настройки вида, не сбрасывайте их после окончания сеанса.
8. Связанные сущности (название организации может быть связано с карточкой организации) полезно делать ссылками на соответствующие карточки. Но если таких сущностей в строке много, выделите только полезные в работе.
9. Строка должна подсвечиваться при наведении курсора. Должна быть возможность выделить строку кликом на неё.
10. Нет ничего страшного при появлении горизонтальной прокрутки.
11. В некоторых случаях полезно маркировать просмотренные записи.
12. Должна быть настройка отображения столбцов с системными свойствами (ID, дата создания, автор, дата изменения).
13. Переход к просмотру записи удобно сделать по двойному клику.
14. Иногда удобен режим предпросмотра, когда по клику открывается не вся запись, а сводка по ней, как в Google Drive.

«Строка в таблице часто является прелюдией к просмотру полной информации по записи. На моей практике в 99% рабочих таблиц модальный режим просмотра уступал просмотру записи на отдельной странице».

Как спрашивать «зачем»?

Как вы помните из заметки про фичреквесты, которые не стоит выполнять (https://t.me/pmdaily/98), вопрос «зачем?» — самый важный вопрос, который нужно задавать любому представителю бизнеса, который пришел к вам с задачей.

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

Вот пара трюков, чтобы процесс задавания вопросов пошел легче:

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

Хорошей практики пост

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

Олег Якубенков написал о разнице между Customer Development и Custdev.

Знание термина Customer Development в англоязычном IT очень низкое. Не говорите, что вы кастдевили своих клиентов, вас не поймут. Также это будет звучать странно в контексте изначального значения термина.

Изначально Customer Development — методология создания новых продуктов и стартапов, где через взаимодействие с потенциальными клиентами проверяются гипотезы о проблеме, решении, рынке, каналах привлечения. Состоит из этапов:

  1. Обнаружение клиентов;
  2. Подтверждение клиентов;
  3. Создание клиентов;
  4. Построение компании.

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

В русскоязычном IT методология сузилась до конкретного метода проверки гипотез — глубинных интервью. То, что мы называем кастдев, англоязычные коллеги называют User Research.

https://gopractice.ru/customer-development-custdev/

И вместо Чтобы: слабая связь

И вместо Чтобы: слабая связь

Союзы «чтобы», «поэтому» и «если» — самый простой способ показать зависимость одного факта от другого. Но слишком топорный.

Напишите email, чтобы получить подарок.

Тут всё строго. Не написал email — не получил подарок. Не получил подарок — значит, не написал email. Мозг воспринимает такое предложение за следствие (не очень корректно).

Иногда причинную связь не хочется подчеркивать. Тогда поможет союз «и».

Организуйте кошке теплое место для сна, и она будет вам благодарна.

Последовательность есть, но она неявная. Коша не обязательно будет благодарна. Кошка вообще никому ничем не обязана.

С заходом солнца принесите жертву, и солнце снова взойдет.

А что если солнце восходит само по себе? Но мы и не говорили, что эти события связаны. Где там «если» или «чтобы»? Ручки-то вот они.

Ок, ближе к реальности. Сравните:

Купите диван-кровать и наслаждайтесь уютом-комфортом.

и

Купите диван-кровать, чтобы наслаждаться уютом-комфортом.

Не начинать с отмазки и нытья

Плохая практика начинать свой рассказ с отмазки, давления на жалость и запроса преференций:

  • Версия пока сырая, не судите строго.
  • Я, конечно, не профессионал в этом, но пара комментариев у меня есть.
  • Возможно, вам совсем не понравится, главное собрать обратную связь.
  • Я понимаю, что уже много есть статей на эту тему, но у меня ещё не было.
  • Я понимаю, что вы устали — постараюсь рассказать побыстрее.
  • Это мой первый проект, надеюсь, что вы не будете меня сильно критиковать.
  • Мне не рассказать так круто, как это сделал прошлый докладчик, но всё равно послушайте.
  • ... и т.д. и т.п.

Зачем ты мне это показываешь, если не хочешь, чтобы я дал честную обратную связь?
Если сам знаешь, что показываешь откровенное Г., то зачем вообще показываешь?
Если у тебя нет опыта, но ты почему-то взялся и написал/сделал — почему я не должен критиковать?

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