Принято считать, что дело заказчика — сосредоточиться на бизнес-требованиях и не влезать в задачи дизайнеров и проектировщиков. Как и большинство широко известных истин, эта тоже не приносит своим адептам ничего, кроме больно бьющих по лбу граблей. Зачем — и как — правильно привлекать заказчика к «рисованию картинок»? Хороший вопрос, с ним и разберёмся.

1. Технологии вовлечения
заказчика
в процессы визуализации
интерфейсов

2. Штуки

3. Техническое задание

4. Прототипы интерфейсов

5. Структура навигации

6. Пользовательские сценарии

7. План проекта

8. Методология проекта

9. Архитектура IT-решения

10. Решения

11. Наши страшненькие wireframes

12. MindMapping — модный старт

13. Почему не работает UML?

14. По почте? Нет шансов!

15. Календарь выработки
интерфейса

16. Снимаем дизайн-показания

17. Рефлекс концептуальных схем

18. Обсуждение с ручкой и
листочком

19. Люди

20. Микроменеджмент в
интерфейсах

21. Мне проще 100500 букв
написать

22. Адепты религии guidelines

23. Ой, мамочки, это что, наш
сайт?

24. Генеральному должно
понравиться

25. Я знаю, как управлять
дизайнерами

26. ТЗ никто не читает, а картинки
— смотрят

27. Мы тут улучшили: по-нашему,
по-дизайнерски

28. А почему шапка криво висит?

29. Надо как у конкурентов, только
лучше

30. Мифы

31. Картинки — иллюстрации к
тексту

32. Нужна универсальная нотация

33. Рисовать может только
проектировщик

34. Разработчик плохого не
посоветует

35. Проектирование — это магия

36. Люди умеют читать

37. Portfolio does matter

38. Переписки достаточно

39. Бумага и ручка — это не для IT

40. Существуют специалисты по
интерфейсам

41. Презентации — способ
согласования интерфейса

42. Правда

43. Как мы приняли решение о
редизайне

44. Как мы узнали, кому что
нравится

45. Как мы уволили
проектировщика

46. Как мы визуализировали
требования

47. Как мы поняли, что в IT бардак

48. Как мы согласовывали дизайн

49. Спасибо!
olga@pavlova.cc