. Нам следует объединить действия выполняемые в продукте в рабочие процессы (workflows). Например: процесс покупки (purchase workflow), процесс обновления информации профеля (profile update workflow) и т.д. Как только мы выделили и описали процессы, следующим шагом мы начинаем упрощение шагов в каждом из них. Правило упрощения всегда одно: если нам кажется, что какой-то элемент чуть сложнее, чем мог бы быть – значит для пользователей он гораздо сложнее чем нам кажется, и мы должны придумать решение.

. Нам следует учитывать закон Миллера так, чтобы ни на одной странице не требовать у пользователей оперировать слишком многим кол-вом элементов. Обилие объектов это всегда плохо. Даже если мы думаем, что пользователи к ним привыкли.

. Причиной ощущения сложности может быть выпадение какого-то компонента из общего контекста продукта. Выпадение из контекста может быть результатом неудачно подобранной формы/типа объекта (, ).

. Для упрощения каких-либо концептов в продукте, может быть полезно использовать картинки, небольшие анимации (.gif) и т.п. Простейший пример: замена 1 инструкции из 70 слов одним .gif изображением длительностью 4 секунды, объясняющем то же самое.

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

. Мы можем заменить какую-то часть видимого функционала, конвертировав его в «подсказки системы». Это поможет значительно облегчить интерфейс. Идея в том, чтобы показывать пользователю какие-то кнопки/действия только тогда, когда они нужны, и скрывать их в остальное время.