Comments 13
Спасибо, интересно.
диаграммы - вот да
сортировать столбики - да!
мокапы с разбиением на элементы и писанием - оооо даа!!
PS: всякое служебное - версии и "для чего" и прочие ARPU - это ИМХО лучше делать или скрывающимися элементами (или в подвале документа, чтобы не скроллить их каждый раз)
Спасибо, полезный гайд !
Вообще мне очень близка идея "диздока", и мне не понятно почему в области разработки пользовательских приложений не используют такой же подход. Там как правило с документацией проекта все плохо. Она делается часто для галочки, а не для того чтобы внести ясность среди участников о назначении приложения и роли каждой отдельной функции в рабочих сценариях пользователя. Даже если мы имеем "юзер-стори" то написаны они часто так что необходимой ясности и связности в них нет. Впечатление, что в разработке приложений нет никакой конечной цели, общего видения и дизайна в широком смысле, а работа делается там где возникла сиюминутная необходимость.
Спасибо, полезная и информативная статья!
подбирайте тип графика под цель анализа данных;А какая цель в вашем примере: показать линейный характер изменений или запутать? А то правый зеленый график гораздо нагляднее левого демонстрирует, что категория D в два раза (а не на 6%) больше категории B
Как тесен геймдев, а?)
Было бы здорово, если бы в статье были указаны удобные сторонние инструменты, которыми можно удобно пользоваться. В моих кругах очень нахваливают Notion, и, скрывать не буду, это лучшее решение на моей памяти. Но может я чего не видел?
Уже год прошел Т_Т
Ку) Я приверженец мнения, что документацию можно вести хорошо где угодно, лишь бы команду устраивало. И плохо ее можно вести везде, даже в Notion.
Я сама по инструментарию старовер и люблю гугл доки: стабильно, не возникает технических проблем (а вот у Confuence и Notion бывает) и отличный табличный функционал Таблиц
Как вести дизайн-документацию, чтобы ваша команда понимала, что она делает