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

1. Мобильные телефоны — 320px. Ориентируемся на viewport айфона, т.к. он самый маленький. У современных андроидов вьюпорт больше, поэтому их игнорируем (растянется на верстке).

2. Планшеты — 768px. Опять-таки ориентируемся на айпад в портретной ориентации , т.к. у андроид планшетов вьюпорты обычно имеют размер от 800×1200 или совпадают с айпадом. Планшеты с вьюпортом 600×1024px устарели. К тому же ничего страшного, если в вертикальной ориентации сайт на таком планшете будет выглядеть как на мобильнике, а в горизонтальной ориентации — как на десктопе.

3. Десктоп и планшеты в ландшафтной ориентации — 1000px. Почему 1000, а не 1024: первое, в настольных браузерах полоса прокрутки съедает (обычно) 18px ширины; второе, от 1000px верстальщику удобнее расчитывать размеры в процентах, а до 1024 все равно растянется при верстке.

В принципе, этого достаточно, чтобы верстальщик справился.

Если дизайн не имеет максимальной ширины и тянется от края до края окна браузера, то на усмотрение дизайнера можно нарисовать еще один или несколько эскизов для более широких экранов.

В каком порядке рисовать? Смотря как поставлено тех.задание. Чаще всего в задании описан полный функционал для настольной версии. Тогда проще нарисовать дизайн под 1000px и перекомпоновать под 768 и 320, выбросив или упростив по пути менее значимые элементы сайта. Т.е. двигаться от сложного к простому.

Верстать при этом удобнее от меньшего экрана к большему (от простого к сложному). При mobile first верстальщику приходится дописывать новые стили для бóльших экранов поверх базовой версии в 320px вместо того, чтобы обнулять написанные для настольных браузеров стили. В результате для мобильника css весит меньше и парсится быстрее.

Для начала максимально упростите жизнь ревьюверам. Чем меньше усилий потребуется с их стороны, тем больше шанс получить код ревью. Отправлять на почте zip-архив и просить посмотреть — это для ревьювера неудобно, многие откажутся. К тому же как передать комментарии обратно.

Для каких-то маленьких простых вещей делайте демку на codepen.io или аналогичных сервисах — это очень удобно и быстро открыть ссылку, увидеть код и результат, форкнуть, исправить или оставить комменты.

Если это уже сайт (даже одностраничник), заливайте его на github pages (https://pages.github.com/).
Для этого вам придется разобраться с git (если еще не изучили), но git вам точно в профессии понадобится. Когда код на github, его удобно просматривать и оставлять комментарии к конкретным строкам кода, или сделать исправления через pull request. К тому же, не покупая домен и хостинг, вы соберете себе на github портфолио.

Когда вам будет что показать, ищите ревьюверов прямо здесь на тостере.

Дополнил этот ответ и написал статью на paulradzkov.com/2016/code_review