Array Array - Getting Real

Обратите внимание, задает ли соискатель вопросы о вашем проекте. Увлеченные программисты хотят максимально разобраться в проблеме и готовы сразу предложить потенциальные решения или улучшения, — и поэтому много спрашивают. Разбирая вопросы, вы также поймете, что проект можно реализовать сотнями способов и очень важно точно, с предельной чёткостью выразить своё видение того, как будет работать ваше веб-приложение. По мере того, как вы углубляетесь в детали, вы всё больше чувствуете на сколько опыт и характер человека соответствуют вашей команде.

Нанимайте хороших писателей

Если вы задумываетесь над тем, какого рода специалиста можно еще пригласить на не занятое место, — наймите того, кто лучше других умеет вести документацию. Не важно кто он — дизайнер, программист, специалист по продажам или кто-то еще, его умение хорошо писать окупится с лихвой. Понятная, последовательная документация ведет к понятному и последовательному коду, дизайну, письмам, объявлениям и т. д.

Хороший писатель не просто тот, кто грамотен. Хорошие писатели знают как донести суть. Они делают сложное — понятным. Они умеют посмотреть на вещи «непонимающим» взглядом. Они знают что лишнее. Их мысли ясны. И они те, кто вам нужен.

Умение хорошо писать — показатель того, насколько организован человек; способен ли он упорядочивать, систематизировать и подавать информацию так, чтобы другим было легче её понять. Это сказывается на коде, общении, чатах (для коллективов которые работают удаленно) и даже на таких сокровенных понятиях как профессионализм и надежность.

Отчетливое письмо делает отчётливее и мысли. Вы не знаете что именно вы знаете пока вы не выразите это. Умение понятно писать — это, в некоторой степени, черта характера. Вместо того, что упрощать что-то для себя, упростите это для своих читателей.

Создавайте дизайн интерфейса до того как начнете программировать

Слишком много приложений создаются с подходом «сначала программируем». Это неудачная идея. Программирование — самое сложное в создании приложения, а это значит, что и самое дорогое. И, создав код, вам будет сложно его изменить. Вместо этого начинайте с дизайна интерфейса.

Дизайн относительно легко изменять. Бумажный набросок дешев и его легко изменить. html-наброски тоже довольно просто изменить или просто выбросить. Но в отношении программирования это неверно. Подход «сначала дизайн» позволит вам быть гибкими. Подход «сначала программирование» ограничивает вас и приводит к дополнительным затратам.

Другая причина для того, чтобы начинать с дизайна в том, что интерфейс и есть продукт. Вы продаете людям то, что они видят. И если вы оставите интерфейс «на потом», огрехи будут заметны.

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

Как только я понял, что готовые приложения для выставления счетов меня не устраивают, я решил нарисовать на бумаге, как я представляю такое приложение. Я взял оранжевую ручку, потому что больше в тот вечер было нечем рисовать, и через несколько часов три четверти будущего приложения были готовы. Я показал всё своей жене, Рейчл, которая как раз гладила и спросил её, что она думает по этому поводу. И она ответила с улыбкой: «Тебе надо сделать это. Правда.»

Следующие две недели я дорабатывал дизайн, и сделал статические наброски для всех страниц первой версии того, что потом стало называться Blinksale. Мы никогда не делали никаких каркасов кроме тех набросков оранжевой ручкой, и то, что мы перешли сразу к html-страницам, подстёгивало нас, так как проект становился более реальным, хотя в то время мы и не знали что именно происходит.

Как только html-макеты были готовы, мы рассказали идею нашему разработчику, Скотту. То, что большая часть дизайна была уже создана, было весьма кстати. Во-первых, это дало Скотту реальной представление о направлении, в котором мы движемся, и вовлекло его. Это было больше чем идея, это была реальность. Во-вторых, это помогло нам подсчитать, сколько усилий и времени потребуется от Скотта, чтобы превратить дизайн в работающее приложение. Когда вы финансируете проект с самого начала, то чем раньше вы сможете предсказать бюджет тем лучше. Дизайн пользовательского интерфейса стал нашим мерилом для границ проекта. И последнее — дизайн интерфейса служил нам для того, чтобы напомнить нам о том, для чего предназначено приложение, по мере того, как продвигалась разработка. Каждый раз как появлялся соблазн добавить новые возможности, мы не могли просто сказать «А давайте-ка добавим вот это и ещё это!». Мы должны были бы вернуться к дизайну и спросить себя, где надо добавить новую возможность, и если для неё не было места, мы её не добавляли

Начинайте с самого важного на странице и двигайтесь вширь

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

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

Только когда эпицентр готов, можно подумать о втором по критичности элементе на странице. После второго вы можете перейти к третьему и так далее. Это и есть дизайн «от эпицентра».