もうWebデザインしないなんていわないよ、絶対（3）

デザイナのためのUI設計段階のデモ制作6カ条

ワンパク　宮城秀雄、吉森大介、野村政行
2009/10/2

新人デザイナーが、泣く子もさらに泣くクライアントに自信を粉々にされた経験から導く、UI設計段階のデモ制作6カ条

イントロダクション

　新人デザイナーが、Webデザイナーとして成長する連載も第3回になった。「入社1年目、デザインしないデザイナなんて!?」「デザイナーは消費されるもんだぞ」で、不安と戦いつつ、スキルの相乗効果が生まれ、仕事が楽しくなるまでをお伝えした。今回はいよいよクライアントとのやりとりの具体的なコツを伝授したい。泣く子もさらに泣く猛者達を目の前にし、自信を粉々にされた苦い経験から導き出した、UI設計段階のデモ制作6カ条だ。

---

　どんよりと曇った渋谷に僕は降り立った。僕は月に1度水曜日にここへやって来る。

　にぎやかなハチ公前やセンター街ではなく、娯楽の空白地新南口だ。
空白地に見えることはともかく、歩いている人々がみんなデッドピープルに見えることは、僕がオスメント君ではないことを考えると気分的なものに違いなかった。

　自動販売機でデカビタを買っているとマイパートナーのMがやって来た。

「おはよう」「ああ、おはよう」

　ハリウッド映画なら、いろいろ会話をするのだろうけど、あいにくここはジャパンなのでシンプル、かつ、あまり必要とは思われないあいさつを交わすと、僕らは目的地へと向かった。

　「RIAデモ開発」

　2005年下半期から2006年上半期にかけて、僕とマイパートナーMは、Web業界の割と有名な企業が名を連ねる、とある団体でRIAのデモサイトを制作していた。

　デモ制作に参加することになったのは、自ら手を挙げたわけではなく、当時の上司が参加表明をし、僕らに一方通行のパスを寄越した結果だった。（いまでは、たくさんの経験が得られたデモ開発に参加することになったことを感謝しているが、当時の気持ちとしては……）

　デモ開発には、何社か参加していたのだが、デザイナーは自分たち2人のみだったため、デザイン部分は僕らがすべて担当することになった。

　とはいえ、始まってしまったものは仕方ないので、覚悟を決めてデモ開発に取り組むことにした。

　参加企業で議論をした結果、デモ開発ではPCの架空ECサイトを作ることになった。

　説明しなければならない人数が多いため、必要なドキュメントは独り歩きしてもいいよう丁寧に作成し、ターゲットユーザーやワイヤーフレームを月に1度の集まりでコンセンサスを取りつつ進めていた。歩みは遅かったが着実にゴールに向かっているはずだった。

　しかし、要件やワイヤーフレームが固まり、いざデザインを披露するとたくさんの辛辣（しんらつ）な指摘が飛んでくることになった。

　どこがボタンか分からない、操作部分がバラバラし過ぎ、などなど忌憚（きたん）のなさ過ぎる意見が見た目の部分からフィックスしたはずの根本的なUIにまで及び、何カ月か前の議論にまで話が戻ってしまった。

　1時間近くの間、思い出しただけでも憂鬱になるさまざまな指摘にさらされた。

　いま見れば、未熟な僕らが作ったデザインは、指摘するべき個所だらけなのだが、当時はそれが精いっぱいだった。その指摘を受け止める心にも限界があり、自然と心は沈んでいく。

　冒頭部分は、そんな指摘を受けた翌月、修正を施したデザインを披露する場へ向かう緊迫の1シーンである。

　「決戦」

　エレベーターを降り、一生縁がなさそうな受付嬢に会社名と名前を告げ、会議室に向かう。

　予定の時間になり、いよいよ件の会議が始まった。まずは、この団体の近況が簡単に述べられ、いよいよ我々デモ開発チームの出番となった。もともと静かだった会議室がさらに静かになっていく気がした。

「えー、前回たくさんのご指摘をいただいた個所を直したものを、今回はお持ちしました」

「まず、ボタン等のUIですが、場所をまとめ、機能ごとにデザインを統一しました」

……という具合に1つ1つ前回指摘をしていただいた部分を説明していった。

　そうやって少しずつ意識を擦り合わせていった。

　それでも、前回参加ができなかった方からアグリーとなったはずの仕様への意見や、突拍子もないような指摘が飛んできたりもした。

「右メニューで作っているが左メニューの方がいいのではないですか？」

とか

「このシーンでもこの値は変更できるべきです」

などだ。

　しかし、今回はその辺りもその場で1つ1つ丁寧に説明をしていった。

　ほとんどがあらかじめ想定していた質問だったからだ。

　いままでも、デザインやUIに理由があるにはあった。ただその理由が弱かったり、語彙（ごい）が少なく説明がおざなりだったりで、今回のようなプロ中のプロを相手にした場合に、きちんと納得させられなかったのだ。

　だが、それでは相手にとっては理由がないも同然で、団体を代表する成果物としては許可できなかったのだろうと思う。

　経験があれば、その場で答えていくことはできたかもしれないが、そのスキルは当時なかったので（いまもないかもしれないけども）、穴の開くほどデザインを見て、すべてに論理的な理由を付与していく作業を前もって行った。

　そうすると不思議なもので、説明できないものは変更するべきだと思うようになり全体の精度は上がっていった。

　それでも20人近くの人が見ていれば、全員が納得するわけもないのではあるが、細かい修正を残してその日にどうにかデザインはFIXした。

　「RIAの勘所」

　デザインFIX後も、実装、動画撮影、ドキュメント作成などをたくさんの方々の協力の下進めていきましたが、厳しく指摘される方もいれば、半年以上の間、業務以外で継続してやっていることを賞賛してくれる方もいて、人の優しさと厳しさを体験することができたプロジェクトでした。

　こうしてRIAデモ制作体験は無事終了したのですが、同時に進めるうえでの問題点や自分への課題が見えたプロジェクトでもありました。そこでこのプロジェクトも含め、いくつかRIAをやっていて気が付いたことを少し書いてみたいと思います。

1. 機能はシンプルに！
2. デザインとUI設計は分離不可！
3. 仕様書はすべてを伝えない
4. 自分タスク＋αを心掛けよう
5. 実装負荷が高いものは、大概使う側も理解困難
6. 実装は自分のペースで

1. 「機能はシンプルに！」

　いくら“リッチ”だからといって機能を盛り込み過ぎてはいけません。

　HTMLベースのモノを、遷移が多いからという理由でRIA化した場合は、クライアントも１画面にたくさんの機能を詰め込もうとしがちです。

　ですが、同時に触るボタンが多いほどユーザーは混乱します。

　必要とあれば、「遷移」という選択もアリです。客観的に判断しましょう。 クライアントが望むすべての機能を実装することがいいとは限りません。

2. 「デザインとUI設計は分離不可」

　UIの設計をいくら詰めても、デザイン段階のワンアイデアでガラっと変わってしまうことがあります。設計段階で考え抜くことは当然大事ですが、デザインで変わることも覚悟しましょう。

　できれば、スケジュールもそれを鑑みて組んだ方がいいです。

3. 「仕様書はすべてを伝えない」

　実装者は、ディレクターやデザイナーに深くコミットするか、できるならば企画段階から参加しましょう。

　仕様書だけでは、すべての機能を把握するのは難しいです。

　そしてたくさんの人と話をしましょう。とにかくコミュニケーションです。

　ただし、ディレクターはそれに甘えて、仕様書をおざなりにしないようにしましょう。

4. 「自分タスク+αを心掛けよう」

　RIAは、なにかと重複するタスクが多いもの。どちらがやるかがあいまいだったりするので、デザイナーが用意し切れなかったものを実装者がカバーしたり、ディレクターが拾い切れなかった仕様をデザイナーがカバーしたりなど、協力し合わないとうまくいきません。

5. 「実装負荷が高いものは、大概使う側も理解困難」

　良いアイデア！と思って採用したものも実装になってたくさんの条件分岐やらロジックが必要になってしまう。そんなことって結構ありますよね。

　そのような機能は大概使う側も理解が困難です。実装者からのアラートも必要です。

6. 「実装は自分のペースで」

　RIAは実装者の裁量が大きく、細かいロジックは都度考え実装していきます。

　仕様を咀嚼（そしゃく）し切らないうちに、実装を始めてしまうと、後でにっちもさっちもいかなくなってしまいます。

　早く手を付けることよりも、じっくり考えながら実装していきましょう。時には思い切って部分的に作り直すことも考えましょう。

　今後、立場が変われば増えたり減ったりはするかもしれませんが、現在デザイナー・Flash実装者として自分が考えているRIA制作時の注意点です。
もし、なんらかの形でRIA開発にかかわることになったらこの辺りを少し注意してもらえると円滑に進むかなと思います。

　それから、社内の体制がきっちり分業制になっている場合には、特に連携が薄くなりがちです。チームの利益よりも、成果物が会社の代表になるという気持ちで臨みましょう。

　そのような気持ちで臨むとまた違った視点で仕事が進められると思います。

　理想のプロトタイプ作りは

　デモ開発は、ルーチン化しかけていた日々の業務に、いろいろな視点を持って望むという選択肢を僕に与えてくれました。

　また、いま割り当てられているポジションも、流動的なもので完璧な切り分けはできないということも気付かせてくれました。

　次回は、経験談から少し離れて、いま僕らが考えている理想の体制についてお話ししたいと思います。

　では、また次回！

著者プロフィール：ワンパク（1PAC.INC.）：Webサイト企画・制作・運営を行う。人、アイデア、技術、モノを最適なカタチで組み合わせる仕事で注目される

■ ＠IT関連記事

WebとUIをつなぐトリックスター　 Webサイト制作の要となるエンジニアとデザイナのチームワーク。異なる者同士をつなぐトリックスターからヒントを探る デザインハック ＜ リッチクライアント

GoogleSitesを使って制作プロジェクトをハックしよう GoogleSitesでプロジェクト管理（1）　Web制作の現場をサンプルに、GoogleSitesをツールに用いたプロジェクト管理の方法を紹介する。使いこなしてプロジェクトをハックしよう デザインハック ＜ リッチクライアント 2009/3/17

クリエイターであるためにFlash待ち受けを出し続ける D89クリップ（9）　 トイレメーカーのサラリーマンはいかにしてFlashアニメ作家になったのか？ クリエイターになる1つの方法を聞くとともにFlash待ち受けの簡単な作り方を教えよう デザインハック ＜ リッチクライアント 2009/6/5

デザイナーとの飽くなき闘争−前哨戦 ASP.NET Webアプリ開発の裏事情　Webデザイナーとチームを組んでのWebアプリ開発は今や当たり前。感性も思考方法も異なる彼らと共同作業するためには…… 「Insider.NET」フォーラム 2004/11/27

ルネサンスの巨匠たちに学ぶエンジニアリングの技 The Rational Edge　偉大な絵画の多くはチーム作業の成果だ。師匠がデザインを描き、重要な部分を塗る。そして、熟練労働者や見習いが残りの作業を分担した 情報マネジメント > アーキテクチャ 2005/9/23

「デザインハック」コーナーへ

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）