Продолжаем разговор про БИСКВИТНЫЙ, сука, ДВОР!
В прошлый раз мы с вами начали препарировать сочную, вкусную мякоть тату-салона и познакомились с первым всадником Апокалипсиса - с дурацким нарушением паттернов.
В этот раз мы продолжим изучать наших гостей из Харькова и обратим внимание на раздел «Блог», а именно на вот эту, гм, выдающуюся статью с фотографии выше. За ней скрывается интересный контент, цитирую полностью: «Вот такая вот теперь тут будет красоваться статья. Вот тут самый большой заголовок, типа H1. Вот так вот!».
«ПФФФ, - элегантно заявите вы, - ДА ЛАДНО ЛЁХА С КЕМ НЕ БЫВАЕТ ТЕСТОВЫЙ КОНТЕНТ ЗАБЫЛИ УБРАТЬ». Бывает, да. Но помните - я даден вашему телеграму не для того, чтобы прощать, миловать и распространять миленькие истории, но для того, чтобы злобным перстом обличения впиваться в хуикс-изъяны, давить из них здравый смысл и передавать вам его в обрамлении цветастых эпитетов - для наилучшего усвоения организмом.
И вот что мне вспоминается в связи с данным случаем про «ВОТ ТАК ВОТ!». На Западе есть горстка UX-фундаменталистов, которые в своем человеколюбии дошли до того, что считают дискриминационным слово «пользователь» и используют исключительно слово «гость». По их философии, хороший владелец продукта - это хозяин, который старается окружить своего гостя не просто функциональным окружением, но заботой и теплом, которые должны проявляться через все аспекты продукта.
Мне эта риторика нравится, потому что статус хозяина обязывает нас не только удовлетворять потребности, но превосходить ожидания и проявлять внимание. Пользователю мы всегда можем насрать в тапки и сделать вид, что так и нужно было - но с гостем такой оборот уже не пройдет, тогда мы однозначно будем плохими хозяевами.
А теперь давайте вернемся к нашему пациенту с «ВОТ ТУТ САМЫЙ БОЛЬШОЙ ЗАГОЛОВОК! ВОТ ТАК ВОТ!». Мешает ли мне эта дурацкая статья выполнять свои задачи и удовлетворять свои потребности как пользователю? Да нифига: я как находил контактный телефон, адрес, профили тату-мастеров Богдана «8BALLY» и Сони «SONY_BLACK» и что там еще на этом сайте положено делать - так и буду находить, и с точки зрения какой-нибудь методики Jobs To Be Done картина не изменится ни на йоту.
Но изменится ли мое отношение к сайту и бренду? Да, изменится, потому что я почувствую, что на меня тут откровенно плевать, что никто не заходил в раздел «Блог» с момента его создания, что весь блог создан исключительно для налива трафика, а я тут не гость - я тут сраный пользователь.
И вы повторите, нахмурив кустистые брови: «ЛЁХА ДА ЛАН ТЫ ДРАМАТИЗИРУЕШЬ ЭТО МЕЛОЧИ В ЭТОТ РАЗДЕЛ КРОМЕ ТЕБЯ И 900 ЧИТАТЕЛЕЙ ХУИКСА НИКТО И НЕ ЗАЙДЕТ». Что ж, пусть. Но я покину этот сайт с тем же ощущением, с каким я покидал свежепостроенную станцию Московского центрального кольца, на которой не удалили монтажный скотч, в углу лежал какой-то мешок с цементом, а стекла так и не были отмыты от строительной пыли и песка. Обо мне не подумали, мне не были рады - а я, по идее, должен был радоваться факту, что мне дали хоть что-то. Это неприятное ощущение.
Поэтому помните, что UX - это очень хрупкая, нежная и ранимая штука, которую очень долго строить - и сказку которой можно порушить неловким движением и дурацкой мелочевкой.
И, да, успех тату-салонов строится не на аккуратности оформления блога - но, тем не менее, все самые жуткие вещи начинаются с фразы «ДА ЛАДНО ЧЕ МОРОЧИТЬСЯ». Это путь, который заводит в никуда - пусть и не прямо сегодня, но в отдаленном и не очень добром будущем.
Будьте здоровы.
#бисквитныйдвор
В прошлый раз мы с вами начали препарировать сочную, вкусную мякоть тату-салона и познакомились с первым всадником Апокалипсиса - с дурацким нарушением паттернов.
В этот раз мы продолжим изучать наших гостей из Харькова и обратим внимание на раздел «Блог», а именно на вот эту, гм, выдающуюся статью с фотографии выше. За ней скрывается интересный контент, цитирую полностью: «Вот такая вот теперь тут будет красоваться статья. Вот тут самый большой заголовок, типа H1. Вот так вот!».
«ПФФФ, - элегантно заявите вы, - ДА ЛАДНО ЛЁХА С КЕМ НЕ БЫВАЕТ ТЕСТОВЫЙ КОНТЕНТ ЗАБЫЛИ УБРАТЬ». Бывает, да. Но помните - я даден вашему телеграму не для того, чтобы прощать, миловать и распространять миленькие истории, но для того, чтобы злобным перстом обличения впиваться в хуикс-изъяны, давить из них здравый смысл и передавать вам его в обрамлении цветастых эпитетов - для наилучшего усвоения организмом.
И вот что мне вспоминается в связи с данным случаем про «ВОТ ТАК ВОТ!». На Западе есть горстка UX-фундаменталистов, которые в своем человеколюбии дошли до того, что считают дискриминационным слово «пользователь» и используют исключительно слово «гость». По их философии, хороший владелец продукта - это хозяин, который старается окружить своего гостя не просто функциональным окружением, но заботой и теплом, которые должны проявляться через все аспекты продукта.
Мне эта риторика нравится, потому что статус хозяина обязывает нас не только удовлетворять потребности, но превосходить ожидания и проявлять внимание. Пользователю мы всегда можем насрать в тапки и сделать вид, что так и нужно было - но с гостем такой оборот уже не пройдет, тогда мы однозначно будем плохими хозяевами.
А теперь давайте вернемся к нашему пациенту с «ВОТ ТУТ САМЫЙ БОЛЬШОЙ ЗАГОЛОВОК! ВОТ ТАК ВОТ!». Мешает ли мне эта дурацкая статья выполнять свои задачи и удовлетворять свои потребности как пользователю? Да нифига: я как находил контактный телефон, адрес, профили тату-мастеров Богдана «8BALLY» и Сони «SONY_BLACK» и что там еще на этом сайте положено делать - так и буду находить, и с точки зрения какой-нибудь методики Jobs To Be Done картина не изменится ни на йоту.
Но изменится ли мое отношение к сайту и бренду? Да, изменится, потому что я почувствую, что на меня тут откровенно плевать, что никто не заходил в раздел «Блог» с момента его создания, что весь блог создан исключительно для налива трафика, а я тут не гость - я тут сраный пользователь.
И вы повторите, нахмурив кустистые брови: «ЛЁХА ДА ЛАН ТЫ ДРАМАТИЗИРУЕШЬ ЭТО МЕЛОЧИ В ЭТОТ РАЗДЕЛ КРОМЕ ТЕБЯ И 900 ЧИТАТЕЛЕЙ ХУИКСА НИКТО И НЕ ЗАЙДЕТ». Что ж, пусть. Но я покину этот сайт с тем же ощущением, с каким я покидал свежепостроенную станцию Московского центрального кольца, на которой не удалили монтажный скотч, в углу лежал какой-то мешок с цементом, а стекла так и не были отмыты от строительной пыли и песка. Обо мне не подумали, мне не были рады - а я, по идее, должен был радоваться факту, что мне дали хоть что-то. Это неприятное ощущение.
Поэтому помните, что UX - это очень хрупкая, нежная и ранимая штука, которую очень долго строить - и сказку которой можно порушить неловким движением и дурацкой мелочевкой.
И, да, успех тату-салонов строится не на аккуратности оформления блога - но, тем не менее, все самые жуткие вещи начинаются с фразы «ДА ЛАДНО ЧЕ МОРОЧИТЬСЯ». Это путь, который заводит в никуда - пусть и не прямо сегодня, но в отдаленном и не очень добром будущем.
Будьте здоровы.
#бисквитныйдвор
Вспомнил сегодня про любимый пример того, что такое UX.
Выше вы видите два скриншота с смсками, которые пришли мне при регистрации в двух каршерингах - слева Youdrive, справа Belkacar.
Функционально эти сервисы почти одинаковые; соответственно, практически одинакова у них и процедура регистрации: вы вбиваете данные о себе, подтверждаете телефон, подтверждаете паспорт, ждете смс с подтверждением, получаете доступ к приложению, арендуете машину и, опьяненный успехом, развозите девиц по кабакам или зачем вам там каршеринг понадобился.
Но при этом у Юдрайва и Белки есть одна существенная разница: коммуникация с пользователем. Посмотрите на скриншот выше и вчитайтесь, о чем нам говорят сервисы.
Юдрайв говорит казенным голосом: «Вас приветствует YOUDRIVE. Для завершения проверки ваши документов требуется дополнительная информация. Перейдите в приложение, чтобы завершить регистрацию». Так и хочется добавить: «Со слов потерпевшего записано верно. Сержант Иванов»
А что нам говорит Белка? «Алексей, мы проверили документы и готовы предложить вам автомобиль!» - именно «мы проверили», с восклицательным знаком и персональным подходом. К этой фразе уже не добавить «Сержант Иванов» - она одна дает нам понять, что за нас рады, что нас ждут, что нам сейчас дадут хороший сервис, что сейчас начнется какое-то приключение. Причем формально к Юдрайву не подкопаешься - они мне дали всю нужную информацию - но в сравнении с Белкой он безнадежно проигрывает, что лишний раз доказывает, что в высококонкурентной среде важнейшим преимуществом становятся не уникальные фичи, но уникальный и качественный UX.
И так во всем. В итоге я все равно пользуюсь обоими сервисами, у меня накатаны многие сотни километров и в Юдрайве, и в Белке - но одним сервисом я пользуюсь с большим теплом и охотой, а другим - просто когда больше некуда деваться, потому что там я не гость (привет мой предыдущий пост) - там я сухой субъект взаимодействия, которого ждет сержант Иванов.
#изкрестьянскогобыта
Выше вы видите два скриншота с смсками, которые пришли мне при регистрации в двух каршерингах - слева Youdrive, справа Belkacar.
Функционально эти сервисы почти одинаковые; соответственно, практически одинакова у них и процедура регистрации: вы вбиваете данные о себе, подтверждаете телефон, подтверждаете паспорт, ждете смс с подтверждением, получаете доступ к приложению, арендуете машину и, опьяненный успехом, развозите девиц по кабакам или зачем вам там каршеринг понадобился.
Но при этом у Юдрайва и Белки есть одна существенная разница: коммуникация с пользователем. Посмотрите на скриншот выше и вчитайтесь, о чем нам говорят сервисы.
Юдрайв говорит казенным голосом: «Вас приветствует YOUDRIVE. Для завершения проверки ваши документов требуется дополнительная информация. Перейдите в приложение, чтобы завершить регистрацию». Так и хочется добавить: «Со слов потерпевшего записано верно. Сержант Иванов»
А что нам говорит Белка? «Алексей, мы проверили документы и готовы предложить вам автомобиль!» - именно «мы проверили», с восклицательным знаком и персональным подходом. К этой фразе уже не добавить «Сержант Иванов» - она одна дает нам понять, что за нас рады, что нас ждут, что нам сейчас дадут хороший сервис, что сейчас начнется какое-то приключение. Причем формально к Юдрайву не подкопаешься - они мне дали всю нужную информацию - но в сравнении с Белкой он безнадежно проигрывает, что лишний раз доказывает, что в высококонкурентной среде важнейшим преимуществом становятся не уникальные фичи, но уникальный и качественный UX.
И так во всем. В итоге я все равно пользуюсь обоими сервисами, у меня накатаны многие сотни километров и в Юдрайве, и в Белке - но одним сервисом я пользуюсь с большим теплом и охотой, а другим - просто когда больше некуда деваться, потому что там я не гость (привет мой предыдущий пост) - там я сухой субъект взаимодействия, которого ждет сержант Иванов.
#изкрестьянскогобыта
🔥1
Зашёл я тут в грузинский ресторан и заказал себе хачапури по-аджарски, с яичком. Вы спросите, как это относится к вам?
А вот как: пока я жду кулинарное благолепие, я могу вам рассказать про что-нибудь интересное. Например, про зарплаты в отрасли - на мой субъективный, само собой, взгляд. Я же Лёха, могу себе позволить.
Сперва поговорим про стажеров. Если вы ничего не умеете, но от души лезете в UX, то на старте сможете рассчитывать на сумму тысяч 40-50.
Если у вас две прямые руки, растущие на достаточном расстоянии от задницы, а также какой-никакой, но опыт - можете рассчитывать на 60-80 тыщ.
Если вы крепкий середняк - то можете рассчитывать на 100+.
Дальше - от 120 тыщ - начинаются руководящие должности.
Интересно, что эти цифры не сильно отличаются для так называемых "проектировщиков" (не умеем красиво, умеем в задротские схемы, аналитику и логику) и так называемых "дизайнеров" (не умеем в задротство, умеем красиво): "дизайнеры" эти за красивые глаза получают на тыщ 10-20 больше, что не так много.
Это все на руки, после налогов. И надо понимать, что эти цифры справедливы: а) для агентского рынка заказной разработки; б) для Москвы.
Если брать не заказную, а продуктовую сторону, то ценник можно смело умножать на 1.3-1.7 в зависимости от отрасли и нажористости задач.
Если брать не Москву, то тут все сильно зависит от региона - иногда можно в далеком Ульяновске найти вполне московские з/п, а в недалекой Калуге - какой-то курам на смех.
А, и ещё нюанс: если вы выбились в дизайнерские суперзвезды, то ценник вас как специалиста (даже не как руководителя) может улететь до 200 и выше, такие кейсы науке известны. Но их мало, с ними все сложно и вообще мне хачапури принесли, до свиданья.
#батинаправда
А вот как: пока я жду кулинарное благолепие, я могу вам рассказать про что-нибудь интересное. Например, про зарплаты в отрасли - на мой субъективный, само собой, взгляд. Я же Лёха, могу себе позволить.
Сперва поговорим про стажеров. Если вы ничего не умеете, но от души лезете в UX, то на старте сможете рассчитывать на сумму тысяч 40-50.
Если у вас две прямые руки, растущие на достаточном расстоянии от задницы, а также какой-никакой, но опыт - можете рассчитывать на 60-80 тыщ.
Если вы крепкий середняк - то можете рассчитывать на 100+.
Дальше - от 120 тыщ - начинаются руководящие должности.
Интересно, что эти цифры не сильно отличаются для так называемых "проектировщиков" (не умеем красиво, умеем в задротские схемы, аналитику и логику) и так называемых "дизайнеров" (не умеем в задротство, умеем красиво): "дизайнеры" эти за красивые глаза получают на тыщ 10-20 больше, что не так много.
Это все на руки, после налогов. И надо понимать, что эти цифры справедливы: а) для агентского рынка заказной разработки; б) для Москвы.
Если брать не заказную, а продуктовую сторону, то ценник можно смело умножать на 1.3-1.7 в зависимости от отрасли и нажористости задач.
Если брать не Москву, то тут все сильно зависит от региона - иногда можно в далеком Ульяновске найти вполне московские з/п, а в недалекой Калуге - какой-то курам на смех.
А, и ещё нюанс: если вы выбились в дизайнерские суперзвезды, то ценник вас как специалиста (даже не как руководителя) может улететь до 200 и выше, такие кейсы науке известны. Но их мало, с ними все сложно и вообще мне хачапури принесли, до свиданья.
#батинаправда
❤1
Делюсь бесплатной годнотой: вот вам трансляция с собрания Гильдии вольных проектировщиков, где мы говорим о презентации результатов своего труда заказчику.
Излагает могучий Артем Авладеев из Росбанка и прекрасная Ольга Апрель из, что характерно, Студии дизайна Ольги Апрель.
Ссылка на первую часть: https://youtu.be/W6D2IFTnq6c
Ссылка на вторую: https://youtu.be/34KsQC_PL7w
(если кто не знает, Гильдия - это такое тайное общество интернет-масонов от мира дизайна, которые ведают тайны мира, практикуют мистические CJM-ритуалы, дышат дымом истолченных интерфейсов, дают UX-пророчества и знают Семь Неизвестных Имён Дмитрия Сатина, а в промежутке общаются про дизайн, цифровые продукты и всякое такое, потому что очень любят свою работу)
(а ещё Гильдия - мое любимое детище и туда можно вступить - и это даже бесплатно, - но об этом я потом расскажу)
#агабесплатнаягоднота
Излагает могучий Артем Авладеев из Росбанка и прекрасная Ольга Апрель из, что характерно, Студии дизайна Ольги Апрель.
Ссылка на первую часть: https://youtu.be/W6D2IFTnq6c
Ссылка на вторую: https://youtu.be/34KsQC_PL7w
(если кто не знает, Гильдия - это такое тайное общество интернет-масонов от мира дизайна, которые ведают тайны мира, практикуют мистические CJM-ритуалы, дышат дымом истолченных интерфейсов, дают UX-пророчества и знают Семь Неизвестных Имён Дмитрия Сатина, а в промежутке общаются про дизайн, цифровые продукты и всякое такое, потому что очень любят свою работу)
(а ещё Гильдия - мое любимое детище и туда можно вступить - и это даже бесплатно, - но об этом я потом расскажу)
#агабесплатнаягоднота
❤1
Друзья, сегодня у нас в гостях пятничный жир, спасибо товарищу Семену Злобину за подгон.
Вот, почитайте текстовый ответ от саппорта Microsoft на просьбу восстановить пароль от Скайпа. Важная вводная - учётка создана до покупки Скайпа Майкрософтом.
Полный текст читайте ниже (осторожно, много басурманских букв), короткий перевод для интриги я припрятал в конце.
Вот, почитайте текстовый ответ от саппорта Microsoft на просьбу восстановить пароль от Скайпа. Важная вводная - учётка создана до покупки Скайпа Майкрософтом.
Полный текст читайте ниже (осторожно, много басурманских букв), короткий перевод для интриги я припрятал в конце.
Hi,
Thank you for contacting Microsoft Online Safety. I understand that a situation like this one can be difficult and I appreciate your patience while I performed an investigation of your account. I am contacting you today to provide the results of my investigation.
The account and billing activity associated with your Skype Account was thoroughly reviewed and the Skype account in question has recently been converged with a Microsoft account (MSA). Unfortunately, when a Skype account has been converged with a MSA, we are unable to assist with an account recovery as the convergence takes account recovery completely out of control of customer service. We are unable to remove the unwanted MSA or make any changes to the security information on the account due to security protocols set up on the account.
The only option we have is to permanently suspend this account to prevent any further use of the account. I have verified that the account is suspended and will remain so.
I understand the frustration that can be involved with this specific issue. I imagine that my answer was not what you might have been hoping for, and I sincerely empathize with you. However; no further resolution can be offered due to the nature of the compromise.
Please know that you can always rely on our customer service for future issues by visiting https://support.microsoft.com. We sincerely apologize for any inconvenience that you have experienced, and I appreciate your understanding and patience while this problem was investigated.
Sincerely,
Jomar
Microsoft Online Safety
Thank you for contacting Microsoft Online Safety. I understand that a situation like this one can be difficult and I appreciate your patience while I performed an investigation of your account. I am contacting you today to provide the results of my investigation.
The account and billing activity associated with your Skype Account was thoroughly reviewed and the Skype account in question has recently been converged with a Microsoft account (MSA). Unfortunately, when a Skype account has been converged with a MSA, we are unable to assist with an account recovery as the convergence takes account recovery completely out of control of customer service. We are unable to remove the unwanted MSA or make any changes to the security information on the account due to security protocols set up on the account.
The only option we have is to permanently suspend this account to prevent any further use of the account. I have verified that the account is suspended and will remain so.
I understand the frustration that can be involved with this specific issue. I imagine that my answer was not what you might have been hoping for, and I sincerely empathize with you. However; no further resolution can be offered due to the nature of the compromise.
Please know that you can always rely on our customer service for future issues by visiting https://support.microsoft.com. We sincerely apologize for any inconvenience that you have experienced, and I appreciate your understanding and patience while this problem was investigated.
Sincerely,
Jomar
Microsoft Online Safety
Короткий перевод:
Здрасьте. Ваша учётка старая, восстановить ее нельзя, и я ее заблокировал для верности. Идите в жопу. Подпись: Джомар.
И вот вроде послали так послали, а ощущение - как будто тебя генсек ООН выслушал.
Красиво застелено.
#говоритджомар
Здрасьте. Ваша учётка старая, восстановить ее нельзя, и я ее заблокировал для верности. Идите в жопу. Подпись: Джомар.
И вот вроде послали так послали, а ощущение - как будто тебя генсек ООН выслушал.
Красиво застелено.
#говоритджомар
Как считаете, норм себя так вести?
anonymous poll
Нет – 103
👍👍👍👍👍👍👍 54%
Да нормально я ему ответил, чо вы прицепились – 51
👍👍👍 27%
Да – 20
👍 10%
Не знаю – 18
👍 9%
👥 192 people voted so far.
anonymous poll
Нет – 103
👍👍👍👍👍👍👍 54%
Да нормально я ему ответил, чо вы прицепились – 51
👍👍👍 27%
Да – 20
👍 10%
Не знаю – 18
👍 9%
👥 192 people voted so far.
Пришло время швырнуть увесистым кирпичом в хорошее и емкое слово: ТЗ.
Проблема с этим словом та же, что и со многими другими понятиями в дизайне и проектировании: все подразумевают под ним что-то свое и дальше радостно за это свое топят.
Вот какие ярые вопли можно услышать от разработчиков, клиентов, экспертов и прочих сумрачных обитателей наших продуктовых подворотен:
1. «ТЗ СОСТАВЛЯЕТ И ПРИСЫЛАЕТ КЛИЕНТ»
2. «ТЗ ПИШУТ В САМОМ НАЧАЛЕ РАЗРАБОТКИ»
3. «ТЗ - ЭТО ПОСТАНОВКА ЗАДАЧИ ДИЗАЙНЕРУ И РАЗРАБОТЧИКАМ ОТ АНАЛИТИКОВ»
4. «ТЗ СОЗДАЕТСЯ В РЕЗУЛЬТАТЕ ЭТАПА ПРОЕКТИРОВАНИЯ»
5. «ТЗ ПИШУТ РАЗРАБОТЧИКИ ДЛЯ СЕБЯ»
6. «ТЗ - ЭТО ПРИЛОЖЕНИЕ К ДОГОВОРУ»
7. «ТЗ - ЭТО ФАНТОМ, ЭКЗИСТЕНЦИАЛЬНЫЙ ПШИК И ИГРА ЗАБОЛЕВШЕГО РАЗУМА»
За 5 лет жизни на агентском рынке я наелся этих разговоров по самое не хочу, и сейчас при слове «ТЗ» вздрагиваю и начинаю нервно озираться словно ветеран Вьетнама, услышавший взрыв петарды.
И прежде чем я прочищу свое ветеранское горло и расскажу, что же такое ТЗ на самом деле, я хочу спросить вас - а сами-то вы что думаете?
Проблема с этим словом та же, что и со многими другими понятиями в дизайне и проектировании: все подразумевают под ним что-то свое и дальше радостно за это свое топят.
Вот какие ярые вопли можно услышать от разработчиков, клиентов, экспертов и прочих сумрачных обитателей наших продуктовых подворотен:
1. «ТЗ СОСТАВЛЯЕТ И ПРИСЫЛАЕТ КЛИЕНТ»
2. «ТЗ ПИШУТ В САМОМ НАЧАЛЕ РАЗРАБОТКИ»
3. «ТЗ - ЭТО ПОСТАНОВКА ЗАДАЧИ ДИЗАЙНЕРУ И РАЗРАБОТЧИКАМ ОТ АНАЛИТИКОВ»
4. «ТЗ СОЗДАЕТСЯ В РЕЗУЛЬТАТЕ ЭТАПА ПРОЕКТИРОВАНИЯ»
5. «ТЗ ПИШУТ РАЗРАБОТЧИКИ ДЛЯ СЕБЯ»
6. «ТЗ - ЭТО ПРИЛОЖЕНИЕ К ДОГОВОРУ»
7. «ТЗ - ЭТО ФАНТОМ, ЭКЗИСТЕНЦИАЛЬНЫЙ ПШИК И ИГРА ЗАБОЛЕВШЕГО РАЗУМА»
За 5 лет жизни на агентском рынке я наелся этих разговоров по самое не хочу, и сейчас при слове «ТЗ» вздрагиваю и начинаю нервно озираться словно ветеран Вьетнама, услышавший взрыв петарды.
И прежде чем я прочищу свое ветеранское горло и расскажу, что же такое ТЗ на самом деле, я хочу спросить вас - а сами-то вы что думаете?
Хуикс via @multi_vote_bot
А ну-ка выберите правильные утверждения про ТЗ (можно натыкать несколько)
ТЗ СОСТАВЛЯЕТ И ПРИСЫЛАЕТ КЛИЕНТ - 21
👍 8%
ТЗ ПИШУТ В САМОМ НАЧАЛЕ РАЗРАБОТКИ - 35
👍👍👍 14%
ТЗ - ЭТО ПОСТАНОВКА ЗАДАЧИ ДИЗАЙНЕРУ И РАЗРАБОТЧИКАМ ОТ АНАЛИТИКОВ - 87
👍👍👍👍👍👍👍👍 35%
ТЗ СОЗДАЕТСЯ В РЕЗУЛЬТАТЕ ЭТАПА ПРОЕКТИРОВАНИЯ - 58
👍👍👍👍👍 23%
ТЗ ПИШУТ РАЗРАБОТЧИКИ ДЛЯ СЕБЯ - 6
👍 2%
ТЗ - ЭТО ФАНТОМ, ЭКЗИСТЕНЦИАЛЬНЫЙ ПШИК И ИГРА ЗАБОЛЕВШЕГО РАЗУМА - 34
👍👍👍 13%
Я НЕ НАШЕЛ НУЖНЫЙ ВАРИАНТ ОТВЕТА И ПРОТЕСТУЮ - 63
👍👍👍👍👍 25%
👥 247 people voted so far.
ТЗ СОСТАВЛЯЕТ И ПРИСЫЛАЕТ КЛИЕНТ - 21
👍 8%
ТЗ ПИШУТ В САМОМ НАЧАЛЕ РАЗРАБОТКИ - 35
👍👍👍 14%
ТЗ - ЭТО ПОСТАНОВКА ЗАДАЧИ ДИЗАЙНЕРУ И РАЗРАБОТЧИКАМ ОТ АНАЛИТИКОВ - 87
👍👍👍👍👍👍👍👍 35%
ТЗ СОЗДАЕТСЯ В РЕЗУЛЬТАТЕ ЭТАПА ПРОЕКТИРОВАНИЯ - 58
👍👍👍👍👍 23%
ТЗ ПИШУТ РАЗРАБОТЧИКИ ДЛЯ СЕБЯ - 6
👍 2%
ТЗ - ЭТО ФАНТОМ, ЭКЗИСТЕНЦИАЛЬНЫЙ ПШИК И ИГРА ЗАБОЛЕВШЕГО РАЗУМА - 34
👍👍👍 13%
Я НЕ НАШЕЛ НУЖНЫЙ ВАРИАНТ ОТВЕТА И ПРОТЕСТУЮ - 63
👍👍👍👍👍 25%
👥 247 people voted so far.
Так вот, про ТЗ. Как вы заметили по голосованию выше, под ТЗ все подразумевают совершенно разное, и дискуссия «что такое ТЗ» неизбежно вырождается в спор глухого с тупым - очень сложно сойтись в своих оценках, когда ты даже под одними и теми же словами понимаешь разное.
Поэтому во исполнение Федеральной программы по соблюдению здравого смысла (которую я выдумал только что) я хочу призвать вас отвлечься от ТЗ и задуматься - а какую роль вообще выполняют всякие описательные документы в процессе разработки?
Этих ролей не так уж и много - всего четыре штуки.
Роль первая - выражение идеи. Когда вы придумываете продукт (будь вы заказчик или разработчик), то вы рано или поздно должны сформулировать его общую идею и донести ее до окружающих - заказчика, подрядчика, команды, начальства, самого себя, в конце концов. Хорошо, если идея будет сопровождаться еще и описанием решаемой задачи - это облегчает понимание того, нахрена вы все тут собрались. Это полезно делать как с чисто коммуникационной точки зрения, чтобы все были в курсе, так и с точки зрения планирования - сложно составлять какие-либо дорожные карты, когда ваш продукт описывается словами «ХОЧУ КАК ХЕДХАНТЕР ТОЛЬКО С БЛОКЧЕЙНОМ И ГЕОЛОКАЦИЕЙ».
Требования к подобному документу простые: ясность выражения мысли, отсутствие ненужных деталей (дабы не затуманивать идею и не влезать раньше времени в проектирование) и, самое главное, честность - если вам предстоит какая-то рискованная жопа, про это стоит начать говорить как можно раньше.
Я лично называю документы этого типа концепцией, широкие народные массы называют это по-разному - от «брифа» до «ТЗ». И это нормально: по факту, идея может рождаться на стороне заказчика и дозревать потом в руках разработчика, по ходу пьесы принимая формат самых разных документов.
Роль вторая - постановка задачи. Когда вы спроектировали продукт, то вам надо объяснить вашим разработчикам (а иногда - и самому себе), что именно вы хотите получить в итоге. Тут есть важная хитрость - степень подробности описания будет сильно зависеть от степени доверия команде: если крутому, дружественно настроенному тимлиду может быть достаточно описания уровня «вот нарисованные интерфейсы, вот общее описание процессов, давай фигачить и разбираться вместе с мелочами в процессе», то горе-разработчику с фриланс.ру нужно будет нудно расписывать, а что же вы подразумеваете под словами «при нажатии на кнопку покупки происходит добавление товара в корзину».
Схожая тема касается и формальности документа - она будет зависеть от ваших взаимоотношений с командой. Если вы работаете со своей командой, то можно использовать емкие, простые описания, если же у вас куча сменяющих друг друга подрядчиков, то не обойтись без формального, системного документа со всякими «Историями изменений», «Словарем терминов» и прочей бюрократической мутью, единственная цель которой - в случае чего схватить зарвавшегося подрядчика за яйца (об этом, впрочем, не сегодня).
Требования к этой группе документов такие: однозначность и достаточность (у вашего конкретного разработчика, который прочтет документ, не должно остаться к вам важных вопросов), а также читабельность (как правило, описания продуктов большие, и если вы сделаете документ мутным и запутанным - на пользу это никому не пойдет).
Именно эту группу документов чаще всего называют техническим заданием, потому что вся она действительно представляет собой задание на разработку. И я с этой позицией полностью согласен.
Нам осталось поговорить про третью и четвертую роли документации, а также про еще кое-какие мелочи (например, кто все это должен писать). Об этом я расскажу вам завтра, чтобы не травмировать ваш ДЕНЬ РОССИИ огромной простыней из текста.
#вашидокументы
Поэтому во исполнение Федеральной программы по соблюдению здравого смысла (которую я выдумал только что) я хочу призвать вас отвлечься от ТЗ и задуматься - а какую роль вообще выполняют всякие описательные документы в процессе разработки?
Этих ролей не так уж и много - всего четыре штуки.
Роль первая - выражение идеи. Когда вы придумываете продукт (будь вы заказчик или разработчик), то вы рано или поздно должны сформулировать его общую идею и донести ее до окружающих - заказчика, подрядчика, команды, начальства, самого себя, в конце концов. Хорошо, если идея будет сопровождаться еще и описанием решаемой задачи - это облегчает понимание того, нахрена вы все тут собрались. Это полезно делать как с чисто коммуникационной точки зрения, чтобы все были в курсе, так и с точки зрения планирования - сложно составлять какие-либо дорожные карты, когда ваш продукт описывается словами «ХОЧУ КАК ХЕДХАНТЕР ТОЛЬКО С БЛОКЧЕЙНОМ И ГЕОЛОКАЦИЕЙ».
Требования к подобному документу простые: ясность выражения мысли, отсутствие ненужных деталей (дабы не затуманивать идею и не влезать раньше времени в проектирование) и, самое главное, честность - если вам предстоит какая-то рискованная жопа, про это стоит начать говорить как можно раньше.
Я лично называю документы этого типа концепцией, широкие народные массы называют это по-разному - от «брифа» до «ТЗ». И это нормально: по факту, идея может рождаться на стороне заказчика и дозревать потом в руках разработчика, по ходу пьесы принимая формат самых разных документов.
Роль вторая - постановка задачи. Когда вы спроектировали продукт, то вам надо объяснить вашим разработчикам (а иногда - и самому себе), что именно вы хотите получить в итоге. Тут есть важная хитрость - степень подробности описания будет сильно зависеть от степени доверия команде: если крутому, дружественно настроенному тимлиду может быть достаточно описания уровня «вот нарисованные интерфейсы, вот общее описание процессов, давай фигачить и разбираться вместе с мелочами в процессе», то горе-разработчику с фриланс.ру нужно будет нудно расписывать, а что же вы подразумеваете под словами «при нажатии на кнопку покупки происходит добавление товара в корзину».
Схожая тема касается и формальности документа - она будет зависеть от ваших взаимоотношений с командой. Если вы работаете со своей командой, то можно использовать емкие, простые описания, если же у вас куча сменяющих друг друга подрядчиков, то не обойтись без формального, системного документа со всякими «Историями изменений», «Словарем терминов» и прочей бюрократической мутью, единственная цель которой - в случае чего схватить зарвавшегося подрядчика за яйца (об этом, впрочем, не сегодня).
Требования к этой группе документов такие: однозначность и достаточность (у вашего конкретного разработчика, который прочтет документ, не должно остаться к вам важных вопросов), а также читабельность (как правило, описания продуктов большие, и если вы сделаете документ мутным и запутанным - на пользу это никому не пойдет).
Именно эту группу документов чаще всего называют техническим заданием, потому что вся она действительно представляет собой задание на разработку. И я с этой позицией полностью согласен.
Нам осталось поговорить про третью и четвертую роли документации, а также про еще кое-какие мелочи (например, кто все это должен писать). Об этом я расскажу вам завтра, чтобы не травмировать ваш ДЕНЬ РОССИИ огромной простыней из текста.
#вашидокументы
Третья роль документов - это хранение и передача знаний. Когда вы что-то разработали, то важно задокументировать результат, чтобы потом было понятно, как все устроено. С этим в разработке всегда большая беда: подобная описательная документация или вообще не ведется (ибо некому и некогда), или же в ее роли используется тот же документ, который применялся для постановки задачи - то самое ТЗ в моей терминологии.
Это однозначно плохая практика: ТЗ может не включать в себя технические детали, которые не важны на момент постановки задачи, но важны с точки зрения развития продукта (например, описание каких-то хитрых внутренних процессов или базы данных), а еще продукт в процессе разработки может сильно поменяться.
Я всегда ратую за то, чтобы процесс разработки включал в себя составление спецификаций - документа, который описывает уже сделанный продукт. Чаще всего этот документ составляется на основе ТЗ, но пишется уже после разработки и включает в себя больше деталей и актуальных нюансов. Если в дальнейшем происходит доработка продукта, то этот документ обогащается новыми разделами и деталями, но сам он остается единым.
Требования к спецификациям: однозначность, полнота (обратите внимание - не достаточность для конкретного разработчика, а полное описание всех деталей!), системность (описание всех аспектов продукта - от интерфейсов до функциональности) и читабельность.
Четвертая роль документов - это формальная фиксация договоренностей с заказчиком или подрядчиком. Тут возможны многие варианты - к договору может быть приложено как реальное ТЗ, так и формализованная концепция, а то и просто невнятная декларация о намерениях. Когда я работал с госпроектами, в норме вещей было взять нормальное ТЗ для разработчиков, отдать его в специальную контору и получить обратно лютый пакет документов на государственном языке, с которым было безумно тяжело работать, но которое хорошо укладывалось в бюрократические процедуры госзакупок.
Форматов оформления масса, и я бы выделил два главных требования к ним: соответствие ситуации (работаете с госами - подавай документацию по ГОСТу, работаете с лояльным заказчиком - расслабься и описывай общую дорожную карту) и юридически выверенный язык, поскольку этот документ все же важен с точки зрения делопроизводства и несет юридическую силу.
Тут, впрочем, будьте внимательны: как показывает моя жизнь, классное «юридическое» ТЗ является гарантией в суде, но не является гарантией качественной разработки или адекватного поведения заказчика. Да и вообще никакое ТЗ не является гарантией хорошей разработки, потому что отдельные чудилы ничего не читают и читать не собираются. Поэтому помните про Agile-манифест и заморачивайтесь не документами, а людьми.
P.S. А еще документы не обязательно должны быть текстовыми - это могут быть, например, изображения интерфейсов или схемы бизнес-процессов. Более того, одна и та же картинка может выполнять разные роли: макет интерфейса может быть иллюстрацией идеи, постановкой задачи для верстальщика, входить в состав спецификаций и прикладываться к договору. Главное - соблюдать требования, которые я описал выше.
P.P.S. Еще я вам пообещал сказать о том, кто же должен писать ТЗ. Ответ такой: да кто угодно. Главное, чтобы писать умел и свое дело знал.
P.P.P.S. Ладно-ладно, почти шучу. Вопрос про писателей документов настолько нажористый, что я про него еще отдельно расскажу.
#вашидокументы
Это однозначно плохая практика: ТЗ может не включать в себя технические детали, которые не важны на момент постановки задачи, но важны с точки зрения развития продукта (например, описание каких-то хитрых внутренних процессов или базы данных), а еще продукт в процессе разработки может сильно поменяться.
Я всегда ратую за то, чтобы процесс разработки включал в себя составление спецификаций - документа, который описывает уже сделанный продукт. Чаще всего этот документ составляется на основе ТЗ, но пишется уже после разработки и включает в себя больше деталей и актуальных нюансов. Если в дальнейшем происходит доработка продукта, то этот документ обогащается новыми разделами и деталями, но сам он остается единым.
Требования к спецификациям: однозначность, полнота (обратите внимание - не достаточность для конкретного разработчика, а полное описание всех деталей!), системность (описание всех аспектов продукта - от интерфейсов до функциональности) и читабельность.
Четвертая роль документов - это формальная фиксация договоренностей с заказчиком или подрядчиком. Тут возможны многие варианты - к договору может быть приложено как реальное ТЗ, так и формализованная концепция, а то и просто невнятная декларация о намерениях. Когда я работал с госпроектами, в норме вещей было взять нормальное ТЗ для разработчиков, отдать его в специальную контору и получить обратно лютый пакет документов на государственном языке, с которым было безумно тяжело работать, но которое хорошо укладывалось в бюрократические процедуры госзакупок.
Форматов оформления масса, и я бы выделил два главных требования к ним: соответствие ситуации (работаете с госами - подавай документацию по ГОСТу, работаете с лояльным заказчиком - расслабься и описывай общую дорожную карту) и юридически выверенный язык, поскольку этот документ все же важен с точки зрения делопроизводства и несет юридическую силу.
Тут, впрочем, будьте внимательны: как показывает моя жизнь, классное «юридическое» ТЗ является гарантией в суде, но не является гарантией качественной разработки или адекватного поведения заказчика. Да и вообще никакое ТЗ не является гарантией хорошей разработки, потому что отдельные чудилы ничего не читают и читать не собираются. Поэтому помните про Agile-манифест и заморачивайтесь не документами, а людьми.
P.S. А еще документы не обязательно должны быть текстовыми - это могут быть, например, изображения интерфейсов или схемы бизнес-процессов. Более того, одна и та же картинка может выполнять разные роли: макет интерфейса может быть иллюстрацией идеи, постановкой задачи для верстальщика, входить в состав спецификаций и прикладываться к договору. Главное - соблюдать требования, которые я описал выше.
P.P.S. Еще я вам пообещал сказать о том, кто же должен писать ТЗ. Ответ такой: да кто угодно. Главное, чтобы писать умел и свое дело знал.
P.P.P.S. Ладно-ладно, почти шучу. Вопрос про писателей документов настолько нажористый, что я про него еще отдельно расскажу.
#вашидокументы
А вот давайте про пустые состояния интерфейсов поговорим, но сперва поиграем в картинки и гражданское голосование.
Есть два интерфейса. Куда сами сядете, куда пользователя посадите?
Есть два интерфейса. Куда сами сядете, куда пользователя посадите?
Отвечайте на вопрос, поставленный выше!
anonymous poll
Странный вопрос, но мне нравится вариант с кнопкой – 148
👍👍👍👍👍👍👍 49%
Я не понял сути шутки, но мне нравится вариант без кнопки – 76
👍👍👍👍 25%
Лёха, хорош уже с этими шутками, ты бы еще про полотенце на полу спросил – 41
👍👍 13%
Я отказываюсь отвечать, зовите адвоката – 40
👍👍 13%
👥 305 people voted so far.
anonymous poll
Странный вопрос, но мне нравится вариант с кнопкой – 148
👍👍👍👍👍👍👍 49%
Я не понял сути шутки, но мне нравится вариант без кнопки – 76
👍👍👍👍 25%
Лёха, хорош уже с этими шутками, ты бы еще про полотенце на полу спросил – 41
👍👍 13%
Я отказываюсь отвечать, зовите адвоката – 40
👍👍 13%
👥 305 people voted so far.
А вы хороши - в основной своей массе проголосовали за вариант корзины с кнопкой. Хороши, потому что он и вправду эффективный, как подсказывает мне моя крестьянская жилка.
Ведь пользователь - он что? Он, подобно врубелевскому демону, лихо летает над интерфейсами и хочет решать свои задачи максимально быстро и максимально не задумываясь. Оп! - и пользователь зашел в интернет-магазин. Оп! - и пользователь нашел нужный ему товар. Оп! - и пользователь заказал товар. Оп! - и товар уже мчит к пользователю в руки. И так далее. Пользователь зрит перед собою цель - и летит к ней.
Что же происходит, когда пользователь попадает на экран, где его не ждут - например, на экран пустой корзины?
Дурной UX-дизайнер скажет: «А НИЧЕГО НЕ ПРОИСХОДИТ» - и намалюет интерфейс, где, натурально, ничего не происходит. Например, сделает белый экран с надписью «Ваша корзина пуста». Особо отмороженный дизайнер просто сбацает полностью белый, как холодильник, экран. Как бы человеколюбивый дизайнер сделает экран с надписью «Добавьте товар, чтобы в корзину добавился товар». И все.
И это белое полотно для нашего пользователя - метущегося по сайту врубелевского демона - будет сродни бетонной стене: он столкнется (жестко, до хруста костей!) с пустым экраном и не будет понимать, что делать дальше. Будто бы само мироздание в этот момент скажет ему: «О пользователь! У тебя была твоя цель, ты находился в контексте и логике пользовательской задачи и перемещался в веселии своем с экрана на экран! У тебя было это - и прошло. Теперь смотри на белый экран и думай сам, что тебе делать дальше. Я тебе более не помощник».
И что сделает пользователь? Что угодно. Возможно, он нажмет «Назад». Или перейдет на главный экран. Или будет копаться в меню. Или вообще свалит с сайта, уедет на Тибет и примет там секретное дао Дракона. Кто знает?
И вот это что угодно - это кошмарный сон для любого проектировщика, который стремится удерживать пользователя в контексте задачи, не заставляет его излишне думать, направляет его к продуктивному сценарию и не надеется на волю случая, дизайнерский фантом, юзабилити-пшик.
Вдумчивый, мудрый UX-дизайнер относится к пустым состояниям интерфейса не как к ничтожному месту, но как к восхитительно пустому холсту, на который еще предстоит нанести полезный рисунок и наладить полезное взаимодействие.
Такой дизайнер, как минимум, оценивает - а как пользователь воспримет пустой интерфейс. Он просто пройдет мимо и не будет отвлекаться от своей задачи? Тогда пользователя можно особо не трогать, достаточно лишь обозначить, почему это место пустует и как оно будет заполнено. Пользователь налетит на пустое состояние как на непреодолимое препятствие? Тогда пользователю нужно не просто объяснить, что это за пустое место - но дать ему понятные инструменты для продолжения работы в его контексте.
В руках мудрого дизайнера пустая корзина обзаведется кнопкой «продолжить покупки», чтобы пользователь не терял контекст работы и не думал, что его бросили на произвол судьбы. Возможно, пустая корзина обзаведется превьюшками товаров, которые пользователь мог бы положить в эту корзину - причем они будут зависеть от предполагаемой цели пользователя. А возможно, там вообще будет что-то третье - нестерпимо полезное и оригинальное.
В любом случае это не будет стена, конец, тепловая смерть пользователя от демотивации, а будет жизнь, радость, достижение цели, вселенская гармония. Это будет рай свободы нашего врубелевского демона.
Ради того и живем.
#изкрестьянскогобыта
Ведь пользователь - он что? Он, подобно врубелевскому демону, лихо летает над интерфейсами и хочет решать свои задачи максимально быстро и максимально не задумываясь. Оп! - и пользователь зашел в интернет-магазин. Оп! - и пользователь нашел нужный ему товар. Оп! - и пользователь заказал товар. Оп! - и товар уже мчит к пользователю в руки. И так далее. Пользователь зрит перед собою цель - и летит к ней.
Что же происходит, когда пользователь попадает на экран, где его не ждут - например, на экран пустой корзины?
Дурной UX-дизайнер скажет: «А НИЧЕГО НЕ ПРОИСХОДИТ» - и намалюет интерфейс, где, натурально, ничего не происходит. Например, сделает белый экран с надписью «Ваша корзина пуста». Особо отмороженный дизайнер просто сбацает полностью белый, как холодильник, экран. Как бы человеколюбивый дизайнер сделает экран с надписью «Добавьте товар, чтобы в корзину добавился товар». И все.
И это белое полотно для нашего пользователя - метущегося по сайту врубелевского демона - будет сродни бетонной стене: он столкнется (жестко, до хруста костей!) с пустым экраном и не будет понимать, что делать дальше. Будто бы само мироздание в этот момент скажет ему: «О пользователь! У тебя была твоя цель, ты находился в контексте и логике пользовательской задачи и перемещался в веселии своем с экрана на экран! У тебя было это - и прошло. Теперь смотри на белый экран и думай сам, что тебе делать дальше. Я тебе более не помощник».
И что сделает пользователь? Что угодно. Возможно, он нажмет «Назад». Или перейдет на главный экран. Или будет копаться в меню. Или вообще свалит с сайта, уедет на Тибет и примет там секретное дао Дракона. Кто знает?
И вот это что угодно - это кошмарный сон для любого проектировщика, который стремится удерживать пользователя в контексте задачи, не заставляет его излишне думать, направляет его к продуктивному сценарию и не надеется на волю случая, дизайнерский фантом, юзабилити-пшик.
Вдумчивый, мудрый UX-дизайнер относится к пустым состояниям интерфейса не как к ничтожному месту, но как к восхитительно пустому холсту, на который еще предстоит нанести полезный рисунок и наладить полезное взаимодействие.
Такой дизайнер, как минимум, оценивает - а как пользователь воспримет пустой интерфейс. Он просто пройдет мимо и не будет отвлекаться от своей задачи? Тогда пользователя можно особо не трогать, достаточно лишь обозначить, почему это место пустует и как оно будет заполнено. Пользователь налетит на пустое состояние как на непреодолимое препятствие? Тогда пользователю нужно не просто объяснить, что это за пустое место - но дать ему понятные инструменты для продолжения работы в его контексте.
В руках мудрого дизайнера пустая корзина обзаведется кнопкой «продолжить покупки», чтобы пользователь не терял контекст работы и не думал, что его бросили на произвол судьбы. Возможно, пустая корзина обзаведется превьюшками товаров, которые пользователь мог бы положить в эту корзину - причем они будут зависеть от предполагаемой цели пользователя. А возможно, там вообще будет что-то третье - нестерпимо полезное и оригинальное.
В любом случае это не будет стена, конец, тепловая смерть пользователя от демотивации, а будет жизнь, радость, достижение цели, вселенская гармония. Это будет рай свободы нашего врубелевского демона.
Ради того и живем.
#изкрестьянскогобыта
А, забыл сказать: скриншоты корзин из голосования выше взяты с wildberries.ru и lamoda.ru, можете зайти и сравнить их сами.