ドキュメンテーションのための３つの課題 Web サイトデザインはもちろん、アプリデザインでも画面ではなく部品から始める [http://www.yasuhisa.com/could/article/wd101-start-with-components/] ほうが有効です。画面ごとで制作していくと、いつの間にか一貫性を失うことがありますし、様々なスクリーンサイズに対応するためのルールを後付けにすると、結局またやり直しになってしまうこともあります。 では、インターフェイスを一度見直してスタイルガイド（パターンライブラリ）を作り始めれば良いのかというと、それほど単純は話ではありません。私の中で以下の 3 つの課題があると考えています。 * 人とコトの課題 – これはワークショップを通して指摘しましたが [http://www.yasuhisa.com/could/article/ui-pattern-workshop/] 、ステークホルダーによって優先順位が違えば、指している要素の呼び名が違うことがあります。制作側視点だけで作ると思わぬ誤解が発生する可能性があります。

カンプ2.0になっていないか プロトタイプを作ることが今日のデザインプロセスにおいて、不可欠になりつつあります。3年前ではなかなか響かなかった話題 [http://www.yasuhisa.com/could/article/prototype-the-future/]でしたが、ますます複雑になるアプリ / Web サイトデザインにおいて、いきなり完成品に近いものを作り込むという手法が通用し難くなりつつあります。また、高機能ツール [http://www.yasuhisa.com/could/article/wcan-prototype-design/]も手軽に使えるようになったことで、 とりあえず作って見せるという行為がしやすくなりました。 実機で画面遷移を確認するだけでなく、アニメーションもコードの知識なしで作れるようになった現在。ツールはますますパワフルになっていきますが、プロトタイプツールの目的は実装のための青写真を作るためにあるわけではありません。 ビジュアルデザイン（インタラクションデザインも含）と実装には以前から大きな溝が存在します。デザインカンプと呼ばれる、あた

孤独だから見えにくい デザインは孤独な作業になりがちです。ひとりでデザインファイルと向き合う時間が長いので、自分がつくったものに対し感情的な繋がりができてしまうことがあります。また、プログラムのように、ひとつのファイルを何人かが触るということも少ないので、ある程度のステージに到達するまで誰もデザインを目にしないことがあります。つまり、『完成品』しか提示されないので、その間どのような試行錯誤がなされたのかも分からないわけです。 自分の視点だけに閉じこもることを避けるために、デザイン批評 [http://www.yasuhisa.com/could/article/design-ciritique/] を通して、何が改善できるかをクライアントや同僚と話し合いをおこないます。批評を意識した会話は、ひとりのデザイナーとしての成長にも大きな影響を及ぼしますが、誰でも会話ができる環境にいるわけではありません。フリーランスはもちろん、まだデザインの会話を始めにくい環境で働いている方もいるでしょう。 デザイン批評は複数人で実践するのが理想的ですが、ひとりで自分のデザインを批評することもできます