Skip to main content

Проектирование и дизайн сервиса

1. Сбор требований
• Дать общее представление о проекте.
• Собрать бизнес-требования.
• Не потерять суть в процессе работы.

2. Описание ЦА и портреты
Роли:
– Аналитик
– Маркетолог
– UX-архитектор

• Дать общее представление о пользователях системы (персоны).

Принимает участие в процессах:
• Проектирование интерфейса
• Тестирование системы

3. Сценарии взаимодействия
Роли:
– Аналитик
– UX-архитектор
– UI-дизайнер

• Сбор функциональных требований. Сценарии позволяют не только перечислить функции системы, но и во всех подробностях рассказать о том, как они работают.
• Зафиксировать типовые задачи (самые распространенные среди пользователей) для которых будет использоваться Mind. По этим задачам будет проходить usability-тестирование.

Принимает участие в процессах:
• Проектирование интерфейса.

4. Перечень функциональности
Роли:
– Аналитик

• Точный сбор функциональных требований. Благодаря детализации, требования к проекту зафиксированы и не изменяются в процессе реализации.
• Классификация требований по приоритетам. Позволяет создать удобный интерфейс Mind как инструмента регулярного использования.

Принимает участие в процессах:
• Проектирование интерфейса.
• Разработка и адаптация существующего функционала к новому интерфейсу.
• Управление процессом разработки в целом.

Назначение:
• Собрать требования к системе в одном документе. Документ должен быть сформирован таким образом, чтобы давать ответ практически на любой вопрос из серии – «Как это должно работать».
• Постановка задачи специалистам по проектированию и дизайну интерфейса.

5. Спецификация
Роли:
– Директор проекта
– Аналитик

6. Карта сайта и схема навигации
Роли:
– UX-архитектор
– UI-дизайнер

• Выстроить информационную структуру. Карта позволяет сгрупировать информацию и функционал в наиболее понятном и удобном для пользователя виде.

Принимает участие в процессах:
• Проектирование интерфейса.
• Подготовка контента.

На выходе: mind-map карта сайта

7. Диаграма взаимодействия
Роли:
– UI-дизайнер

• Соответствие интерфейса задачам пользователя. Диаграммы позволяют оптимизировать процесс работы пользователей с системой.
• Постановка заданий разработчикам. Самый наглядный пример постановки задачи для них — представление во Flow.

Принимает участие в процессах:
• Проектирование интерфейса.
• Тестирование интерфейса.
• Разработка и программирование.

8. Структурные схемы страниц
Роли:
– UI-дизайнер

• Постановка задачи дизайнеру. При отрисовке макетов дизайнер точно не упустит ни один элемент, и не должен будет брать на себя работу проектировщика — разрабатывать flow и информационную структуру проекта. Его задача — сделать красивую картинку на основе прототипов.
• Постановка задачи разработчикам. Прототипы демонстрируют весь функционал системы, который можно реализовывать уже на этапе дизайна.
• Демонстрация инвесторам и потенциальным пользователям. По своей сути прототип — это наглядное отображение системы и ее возможностей еще до этапа полной реализации.

Принимает участие в процессах:
• Дизайн интерфейса.
• Разработка системы.
• Usability-тестирование

9. Документация для дизайнера и разработчика
– UI-дизайнер

• Постановка задачи дизайнеру. Понимая как именно пользователь будет использовать интерфейс — дизайнер сможет правильно отрисовать определенные элементы. Особенно это относится к мобильным приложениям.
• Постановка задачи разработчикам. Наглядная демонстрация «клиентской» части системы. Программисты понимают, как пользователь будет использовать систему.

Принимает участие в процессах:
• Дизайн интерфейса.
• Разработка системы (и ее клиентской части).
• Usability-тестирование системы.

10. Дизайн пользовательского интерфейса
Роли:
– Дизайнер
– Арт-директор
– UI-дизайнер
– Креативный директор

• Внешний вид продукта
• Постановка задачи для разработчиков. Для них дизайн — это исходный материал, который они должны «оживить» прикрутив к нему свой функционал.

• Внешний вид продукта
• Постановка задачи для разработчиков. Для них дизайн — это исходный материал, который они должны «оживить» прикрутив к нему свой функционал.

Принимает участие в процессах:
• Разработка системы.

11. Сопроводительная документация (Документация для дизайнера и разработчика)
Роли:
– Директор проекта
– Дизайнер

12. HTML страницы пользовательского интерфейса
Роли:
– Разработчик
– UI-дизайнер

• Презентация инвесторам. Действующая модель продукта готова для публичной демонстрации еще до того, как начата разработка ее программной части.
• Доработка концепции. При работе над сложными и инновационными проектами постоянно идут эксперименты над концепцией и, соответственно, интерфейсом. В прототип легко вносить правки, а значит и сравнивать альтернативные решения.
• Раннее usability-тестирование. Прототип позволяет оценить удобство системы путем ее демонстрации потенциальным пользователям.
• Часть технического задания для разработчиков. Команде разработки проще понять ка должна работать система, поработав с ее визуальной моделью.

13. Презентация продукта
Роли:
– Директор проекта
– Аналитик
– Дизайнер

Демонстрация инвесторам. Презентация продукта позволяет построить рассказ с нужным содержанием, в нужной последовательности и с нужными акцентами. При этом благодаря удобному формату распространения этот рассказ может обойтись и без рассказчика. А значит получить больший охват слушателей.

Changing the Conversation about Product Management vs. UX

pm ux fight

If you had to pick one, would you rather be a Product Manager or UX Designer?

I’m both.

You can’t be both. We need to put you on the right team.

That’s not your job.

I had no idea what a Product Manager was when I started at Capital IQ, almost 10 years ago. I didn’t even apply for the job. A friend told me they were hiring, and I asked if there were any roles for people like me — engineers who liked Photoshop. After talking to a few people, I was told I’d make a good Business Analyst (their term for Product Manager, I’d later learn). The combination of business and analysis sounded intriguing, so I jumped on the offer.

My responsibilities were gathering business requirements, specifying features, passing the specs off to engineers, mocking up the interfaces in Photoshop, user acceptance testing, gathering feedback from customers, user research, and managing the scope. The company was far from Agile or Lean at the time, but I didn’t know any better. I loved it. Solving problems and watching them come to life was way better than my other options — supply chain management or coding.

Four years later at OpenSky, I heard the term “User Experience Designer” for the first time. My boss announced we were hiring a Director of UX. Apparently my role as a Product Manager was not the same as a UX Designer. What?! I was blindsided. The UX Director was now in charge of all the interface designs and mockups. He made it sound like a good thing. “Congrats! You don’t have to do any more wireframes.”

But I loved designing. I loved creating flows that solved problems.

The developers were finally participating in the process too. We were sketching together, incorporating each other’s ideas, and pairing on iterations. When the new Director of UX started, most of that went away. Now there were hand offs. I was still testing product ideas, but I didn’t get to participate in what that looked like for the user.

Quickly I realized this was not the role I wanted. I left to become the Lead UX Designer at another company. Now I had the opposite problem. I wasn’t allowed to participate in feature decisions. Those were made by the Product Managers. I was just the person who designed them. I felt like Lucy and Ethel in the chocolate factory, trying to wrap up all these features in pretty designs. The conveyor belt never stopped.

lucy and ethel

I wish product ideas were chocolate so I could eat them.

I saw features become approved that didn’t relate to the feedback I was hearing from customers. When I tried questioning why we were building them, I was quickly shot down. Once I brought up the idea of making an MVP. Wrong move. I got a few death stares and was told “We don’t do that here”.

I was confused. If I did both Product Management and UX, and I was good at doing both, where did I fit in?

There’s some UX in your PM.

When I compare these roles, I see responsibilities that are clear cut. For example, prioritizing feature requests has typically been led by a Product Manager.

Then, there are responsibilities that are murky. Who makes personas? At one company I’ve seen it as the PM, at another UX, and at another Marketing. Who owns User Research? Same story.

If you read different job descriptions, you’ll start to see a lot of overlap in major responsibilities:

 UX vs PM

When I was writing the Product Management curriculum for General Assembly, we had trouble here as well. There were weeks dedicated to topics some saw purely as UX — personas, research, wireframes, etc. But these are all necessary for Product Management too.

It’s not about roles, it’s about skills.

I’ve found the definition of roles matters less than how a company operates. Highly collaborative teams have Product Managers and UX Designers who assign each other tasks based off what they need for the project. Whoever is best suited in that moment to do it, does it. They agree on this. Sometimes the UX Designer might be doing research, other times the PM, and hopefully, more often than not, they’ll both work on it together. Everyone can move forward without feeling territorial.

Companies need to realize that both Product Managers and UX Designers are important, but what’s more important is that these two people can make decisions together. Product Management with no User Experience Design creates functional products that don’t make users excited. User Experience Design with no Product Management produces delightful products that don’t become businesses. If these two roles are not sharing responsibilities, then you will have a disconnect in both your team and product.

If we change the conversation to skill coverage instead of role definition, it becomes clearer. Do we have all the skills we need on this team to validate and execute a product idea? If we have a Product Manager who cannot wireframe, let’s hire a UX Designer. If we have a Product Manager who does UX Design, let’s hire a Visual Designer. If we truly want to iterate and get to market faster, we need to focus on limiting our team size. Having too many moving pieces only slows us down. Limit the scope of the work and make more teams rather than adding on roles or people to one.

My knowledge of UX Design makes me a better Product Manager and my knowledge of Product Management makes me a better UX Designer. It makes me better at creating products that delight users and solve their problems. There’s a lot of people like me out there. Find them. Hire them. Don’t make them choose.

sourse: http://melissaperri.com/2016/01/17/pmvsux/#.Vq5OZFN96fX