Необоснованный отказ от компании XCDS
Я очень редко делаю тестовые задания. Но для этой компании я решил сделать, так как мне реально нравился продукт. И получил необоснованный отказ с еще менее обоснованным фидбеком.
Само задание: https://docs.google.com/document/d/1kttKGdJ9zOIh6SQqzhCVbwypo29qP0gRkpMOQijw9I0/edit?usp=sharing. Если вкратце:
"You have an Mac application that allows you
to create and edit documents with a team.
Develop the screen where you can edit document
and start chat about selected part of document with
your colleague"
Немного скриншотов из их приложения, которое мне нужно было модифицировать:


Что сделал я:




На это все я получил фидбек:

"Тестовое задание было не достаточно детально проработано в разрезе взаимодействия с командой"
А что значит "проработка тестового в разрезе взаимодействия с командой"? На мои вопросы, которые я задавал дизайн лиду, тот отвечал "просто возьми и сделай", про какое тогда взаимодействие может идти речь?
"отсутствовало пояснение экранов"
А должно было присутствовать? Может мне еще целую конференцию провести на тему выполненного тестового? Меня просили презентовать дизайн? Нет, не просили.
"скриншоты были не подписаны"
А должны были? И чем это отличается от пояснения экранов?
"не проанализирован функционал продукта"
В чем это проявляется? Пустые слова какие-то, без какого-либо обьяснения.
"не предоставлено идей по улучшению продукта для пользователя"
Чтобы предоставить идеи, нужно вникнуть в приложение, пообщаться с командой, с руководителями. Да даже чисто вникнуть в приложение – это 5-10 потраченных часов.
1. Ко всему этому мне доступа не предоставили (кроме приложения)
2. Меня это сделать не просили
"В процессе взаимодействия с командой, данные нюансы будут замедлять процесс разработки продукта и увеличивать нагрузку на команду, т.к придется уточнять что демонстрируется команде."
Процесс разработки продукта и процесс выполнения тестового задания – абсолютно разные вещи.
- Не предоставляю идей по улучшению продукта? В некоторых командах это не приветствуется, потому что нужно четко выполнять задачу, а не думать как улучшать продукт.
- Я всегда пишу документацию для разработчиков, так что необходимости в пояснениях экранов обычно нет.
Оценка фидбека: 4 из 10 баллов.

- Слабая работа с пространством? В чем это выражается?
- Необоснованные паддинги/расстояния между блоками? В чем это выражается?
- Необоснованное выравнивание элементов? В чем это выражается?
Какая-то необоснованная дичь, честно говоря.
"На макете одновременно активны несколько элементов, непонятно куда смотреть, что за чем следует"
В чем это выражается? А то что у приложения "всраты" акценты на элементах это ничего? По-хорошему его нужно полностью переделывать.

- Много места? А должно быть мало?
- Использованы контроллы из андроид системы? Там где "Enter Message"? Есть пруфы? Вообще-то это кастомный элемент, которого нет в Android. Но да, я не заметил что в приложении уже есть дизайн активного состояния инпута и не взял его – тут мой косяк.
- Проблема с масштабностью элементов? В чем именно она выражается? Никакого обоснования.
