Post #117

(Продолжение) После этого этапа полезно, если есть время, также пробежаться по маркетинговым материалам — как увиденное только что позиционируется, продается, какими ценностями (пусть даже на словах) обладает. Также, возможно, у вас есть пользовательские руководства, какие-то обломки спецификаций и т.п. — можно пробежаться и по ним, обращая внимание не на то, что вы уже видели в экранах, а на то, что не увидели — может быть, этого нет в вашем доступе, либо это не было реализовано, либо отсутствуют какие-то данные и поэтому эти функции скрыты. В результате мы можем уже понимать, как конкретные увиденные экраны и интерфейсы стыкуются с тем, что заявляется при продаже или в пользовательских гайдах. А значит, мы можем это интерпретировать и оценивать уже лучше. (В принципе, тут могут быть и нормальные этапы аналитики — кто есть пользователи, какие есть жалобы и т.п., но это уже как будет получаться и не является темой этого поста) Закончив с предыдущими этапами, мы можем, мучая стейкхолдеров или даже самостоятельно, теперь пробегаться по всем экранам и записывать свои соображения прямо поверх них либо, если они касаются стыков между экранами, на полях — что вызывает вопросы, что выглядит явно неправильным, как могло бы быть (даже если это потом окажется чушью) и так далее. Не факт что у вас получится проработать всё, но каждая озвученная и зафиксированная мысль — это то, что будет вам помогат дальше работать и развивать это уже нормальным проектным образом. Помните, что чтобы решить проблему, нужно её сформулировать. Иначе вы можете начать решать что-то не то или не так. Теперь можно начинать работать нормальным способом, шаг за шагом. step by step, корак по корак. Но иногда описанного выше не достаточно, ибо может быть слишком абстрактным для коммуникации с коллегами — они то мыслят совсем другими категориями и хоть у вас есть уже какое-то представление о направлениях деятельности и улучшений, его еще нужно донести. И тут новый хак, как обойти ресурсное проклятие — вместо того, чтобы придумывать как сделать лучше всё с нуля, начинаете в фигме двигать блоки скриншотов новым образом, дорисовывая грубо то, чего не хватает или как должно быть. Боритесь с перфекционизмом — это не виденье продукта, не дизайн, не предложение. Это прототип, даже субпрототип (как сгустки протоплазмы формирующейся Солнечной системы несколько миллиардов лет назад), который запустит коммуникации и споры, будет платформой для озвучивания вопросов и гипотез, а также синхронизации ожиданий. В моем случае я делаю так прототип интегрированного продукта — просто собираю в одну навигационную модель версию 0 (Zero), собирая все в кучу по моим еще дефрагментированным и наивным представлениям — чтобы размапить не только состояние дел с текущими системами, но и увидеть, что склеивается, а что не склеивается. Что теперь с этим делать? Теперь у вас в кармане есть зафиксированное состояние дел на данный момент. Есть некий сгусток мыслей о том, как это состояние дел может быть склеено не самым лучшим, но хоть каким-то образом. Теперь можно планомерно заняться обсуждениями и улучшениями этого сгустка, доводя его до версии MVP. Но я также в таких случаях часто делаю “фоновую версию с нуля” — забрасывая ее, когда много более приоритетных и конкретных задач, и возвращаясь когда появляется время. Это как раз попытка отразить всё то, что я узнал, и создать совершенно чистовую концепцию системы (в новом дизайне, новой архитектуре), которая будет решать и проблемы текущих систем, и версии Zero так, как будто нет никаких ресурсных и легаси ограничений. Версия «а как я бы сделал это», которая отражает только мои личные ограничения и т.п. — еще один полюс для обкатки проектных решений и потом «спускания» их в конкретные задачи.