x
 
Владимир Якимов
6 июля 2009

Здравствуйте, коллеги!

Нужно разработать интерфейс администрирования интернет-магазина новых оригинальных запчастей. На картинке дизайн модуля «Отгрузка товара».

Краткая схема работы магазина: клиент выбирает запчасти по каталогу и заказывает их. Менеджер после получения оплаты делает заказ поставщику. После прихода на склад запчасти отправляются клиенту службой доставки, которую клиент выбрал при оформлении заказа.

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

Запчасти могут быть сняты с производства и заменены на более новые, об этом можно узнать только после заказа к поставщику, а точнее, после прихода запчастей на склад компании. Т. к. поставщик информирует, что запчасти будут заменены на новые, но может отправить и старые, если были запасы на складе. Получается, что о заменах мы узнаем в момент заказа к поставщику, а о том, что в посылке, только после прихода запчастей на склад компании (вот такая консервативная особенность работы поставщиков в Японии :-)

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

Если запчасти сняты с производства или имеют проблемы с сертификацией в РФ, они снимаются с отгрузки и клиенту возвращаются деньги.

Операции «отгрузка» и «снятие с отгрузки» можно отменить.

Удалось изобразить написанное выше? Какие недостатки имеет интерфейс, что можно улучшить?

Спасибо за внимание!



  • Вкратце:
  • повысить информативность названия заказа, перенести ссылки с номеров на названия запчастей;
  • избавиться в меню от стоп-слов «информация», «содержимое»;
  • раскрасить блоки, чтобы сразу отличать недоотгруженные заказы;
  • сделать замены более наглядными.

Я не совсем понял суть мультизамены, в этой части пришлось пофантазировать.


Поделиться
Отправить

Комментарии

Дмитрий Зимин
6 июля 2009

1. Мне кажется, что все эти динамические переключение поля «шт.» не нужны. Там, где поле редактируемое — поле input, где нередактируемое — обычный текст. Так глазом будет легче восприниматься, значит и путаницы меньше да и программировать динамику не надо будет, что тоже важно (представьте, что в момент обработки заказа у IE «уносит крышу» и происходит какой-нибудь сбой скрипта, а клиент на телефоне ждет).

2. Артём, мне кажется, вы зря поле поиска по номеру отгрузки поставили рядом с командными кнопками. Так как сами кнопки не в конце страницы (что распространено), то кажется, что они связаны с полем. А это не так (вроде бы).

Судя по всему, это поле вообще не нужно, лучше пользоваться встроенным поиском браузера по странице. Для этого достаточно менеджеру во время инструктажа показать «Ctrl+F».

3. Возможно, Артём, вы марку детали (Kawasaki) тоже зря вверх вынесли. Что если заказ будет из нескольких брендов?

4. В правом верхнем поле поиска не понятно, что делает флажок «расширенный поиск». В поисковых системах (которые выработали привычку) он работает не так, а значит у нас — когнитивный диссонанс :)


6 июля 2009

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

Производитель (или список производителей) указан в заголовке заказа всегда для удобства, а вот в таблице его стоит указывать, если в заказе несколько разных брендов.

Михаил Едошин
6 июля 2009

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

Насколько я понимаю ситуацию, заказчик заказывает у дилера детали, которые затем заказываются у производителя или оптового поставщика, потом попадают на склад дилера, потом отгружаются заказчику. Перед нами интерфейс уже сделанного где-то там в каталоге заказа. Заказ идет долго и разные части приходят в разное время, плюс заменяются, отсюда необходимость как-то всё это сообщать. Плюс нам иногда нужно изменять отдельные позиции.

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

Мне кажется, стоит разделить интерфейс по этому принципу: вот текущий статус заказанных позиций, а вот возможность изменить состояние отдельных позиций. По-моему, статусов нужно больше:

1. Детали заказаны дилеру, но ещё не заказаны у поставщика.
2. Детали заказаны поставщику, но ещё не пришли.
3. Детали пришли, ждут комплектации
4. Детали скоро будут отправлены заказчику
5. Детали в пути
6. Детали доставлены
7. Детали отправлены обратно.
8. Детали, от которых заказчик по той или иной причине отказался до доставки.

То есть восемь штук, причем замена и мультизамена сюда не входят. Статус — это состояние позиции во времени, каждая позиция проходит почти каждый статус (кроме необязательного отказа), а замена — это всего лишь особая ситуация, которая, во-первых, не факт, что случится, потому что старая деталь всё ещё может быть на складе, а во-вторых, не предполагает каких-то особых действий. Заказчик, конечно, может отказаться от замены, но точно так же он может отказаться от любой другой позции.

По умолчанию позиции проходят стадии 1—6. Заказчик может изменить состояние каждой позиции, причем возможный выбор зависит от текущего статуса и невелик — один-два варианта. В статусе 1—4 заказчик может отказаться от позиции; в статусе 3 (ждут комплектации) заказчик может ускорить отправку и перевести позицию в статус 4 или, наоборот, отложить позицию из статуса 4 (готовится) обратно в 3 (ждёт). В статусе 5 заказчик подтверждает получение и, принимая/отвергая отдельные позиции, переводит их в статус 6 или 7.

То, как это всё могло бы выглядеть, я набросал на прилагаемом рисунке, чуть ниже пояснения, а пока мелкие примечания.

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

— Я больше чем уверен, что длинные номера имеют внутреннюю структуру (например, какие-то цифры обозначают тип, категорию и т. д. ); если так, хорошо бы её как-то выделить, скажем, так: 13.2.361.186.

— Штуками считают одинаковые вещи, а «к отгрузке» лучше писать «124 предмета».

Пояснения к рисунку:
— То, что на сером фоне — информация, ее можно смотреть, но не менять; на белом — возможные действия. Предполагается, что множественные действия спрятаны за одной надписью «Изменить» с выпадающим меню, например, а там, где возможно только одно действие, оно и написано.

— Если позиция не снята с производства, в число действий входит «дозаказать», которое не меняет статус позиции, а добавляет новую в статусе 1.

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

— Замена и мультизамена никак специально не озаглавливаются и никакой специальной разницы между заменой и мультизаменой не отображается (за исключением понятной разницы в количестве позиций).

— Когда замена ведёт к изменению цены, система показывает разницу между ценой заказа и возможной ценой замены.

— У позиций, предлагаемых на замену, есть только действие «дозаказать» (ведь эти позиции не заказаны, да и замена может не произойти).

— Отдельные малоинтересные статусы могут сворачиваться.

Владимир Якимов
7 июля 2009

Артём, спасибо за проявленную фантазию! Вариант выглядит очень интересно.

Понравилась идея с цветами блоков и заменами, но совершенно не понравились три неуравновешенных текстовых блока в шапке (но идея понятна, нужно из однообразной массы выделить наиболее важную информацию).

Про разделы подумаю, возможно будет более правильными объединить разделы «содержимое» и «отгрузка» в один раздел «товары».

Про мультизамены. Выпускалась запчасть под номером 12345-98760 и называлась «Болт с шайбой и гайкой» и стоила эта запчасть 10 руб. Производитель снимает запчасть 12345-98760 с производства и заменяет ее на 3 новые: 12345-98761 — «Болт», 12345-98762 — «Шайба», 12345-98760 — «Гайка» и ставит каждей запчасти цену 4 рубля. Это и есть мультизамена.

Владимир Якимов
7 июля 2009

1) Дмитрий и Артём, а чем плох мой вариант?
Есть список запчастей готовых к отгрузке. Выделяем чекбоксами, что хотим отгрузить.
Если кол-во деталей в заказе > 1, то активируется edit с кол-вом, которое указал клиент при заказе. Т. е. даем возможность менеджеру отгрузить всё или меньше чем заказано для частичной отправки заказа.
Если кол-во = 1 то edit вообще не нужен, так как больше чем заказано отправлять не нужно.


2) Дмитрий, это не поиск по номеру отгрузки, это поле ввода номера отгрузки, которое выдается транспортной компанией и по которому в дальнейшем идёт отслеживание заказа.

3) Заказ действительно может содержать нескольких производителей.

4) Расширенный поиск был заменен на более интеллектуальный обычный с авто-дополнением.

Игорь Старков
7 июля 2009

А почему бы нам в таблице не вынести в заголовки колонки «шт.» и «руб.»?

Почему у нас они повторяются?

Михаил Едошин
9 июля 2009

>> 1) Дмитрий и Артём, а чем плох мой вариант?

Вообще, это неудобный вариант. У вас, получается, список работает в двух режимах: 1) показывает, что заказано и 2) позволяет перенести часть позиций в новый список для отгрузки (или отмены). И вот для этих вот позиций получается, что строчки, которые вот-вот будут перенесены, закрывают информацию о том, сколько штук было заказано. Поверьте на слово, что это плохо. Эти две цифры (сколько заказано и сколько будет перенесено) нужно видеть одновременно и не должно быть так, что в одной (неотмеченной) строчке цифра обозначает сколько было заказано, а в другой (отмеченной) такая же цифра в том же самом месте уже обозначает, сколько будет отгружено.

Дмитрий Зимин
9 июля 2009

Игорь, чтобы не произошло, как с тем брокером, который вместо одной акции за 620 тыс. йен продал 620 тыс. акций по цене 1 йена за штуку :)


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

2 6 5 3




Недавно всплыло

Все уже успели заметить, что вы почти во всех пятничных примерах советуете немного поунижаться 12 Почему в переписке нельзя использовать «Доброго времени суток»? 2 Какой движок выбрать для сайта рекламного агентства? 2 Какие законы для текста, который будет восприниматься только на слух? 1