【27】UI の「正解」を求めて

栗城 桂子

　近年のゲームにおけるグラフィック、システムの複雑化、多様化と共に UI も設計、構築の難易度が上がってきています。そんな中、より良い UI を実現する為の方法としてよく語られるのが以下のようなものです。

　これは「正しい」方法です。なぜなら実際にユーザーに触ってもらった方がより早く「正解」に近づけるし、開発者がどんなに頭をひねって決めた仕様でも、それが覆される事も多々あるからです。

　ですが、この理想を実現するのが難しい現場も多いのではないのでしょうか。そもそも、ユーザーテストの文化が無いという問題を抱えているケースもあるかと思います。ソーシャルゲームやネットワークゲームでは、β版で一般にリリースし、調整期間を設けるのは一般的になってきていますが、コンソールゲーム開発はパッケージ発売での一発勝負になりがちです。開発段階で一般のテストユーザーを入れるという文化と環境が無い会社やチームの場合、それを 1 から構築しなければならず、1 セクションとしてではなくチーム全体で対応しなければいけない課題となります。

　そのような問題を抱える中で、UI デザイナーはどう動くべきでしょうか。せめて部内、社内テストを行える状況を早めに作れれば調整できるチャンスは増えます。なるべく早く実装にこぎつけるために一番重要なのは、セクションの垣根を作らず、やれる事にチャレンジすることです。

仕様が遅延した場合

　遊びの根本的な仕様に関しては待たざるを得ないかもしれませんが、情報整理や、フローやレイアウトの仕様作成をデザイナーで引き受けるのは効果的です。完成の絵を頭の中で想像できる分、仕様調整が早く済み、全体のスピードアップに繋がります。

実装担当プログラマが多忙な場合

　例えデザイナが早期にデータを作成できたとしても、担当プログラマがタスクを多く抱えて多忙な場合、実装までがスムーズに行かない事は多々あるかと思います。その場合は、プログラマのタスクを減らす工夫をします。企画の検証用にダミー UI を実装する場合は、なるべくシンプルな構成にし、プログラマの負担を減らします。

　発注前に画面遷移や操作フローを紙の上で練る事も有用です。初めに、どんなに頭で練ったとしてもユーザーにとっての正解とは限らないとは言いましたが、それでも準備段階で企画とシミュレーションを行うことで、早期に様々な問題点を発見する事はできます。

　データを実装する機能は、その一部だけでも良いので、デザイナーが作業できるように作ってもらいます。例えば階層構造やデータの関連付け等を別で管理できる機能を作ってもらった結果、プログラマが 1 日かかるタスクをデザイナーが 1、2 時間作業することで達成できた事もあります。

スケジュールに余裕がない場合

　UI が開発フローの下流部分に位置する場合、開発スケジュールの後半に多数の発注が来ます。そうなると実装に精いっぱいで、テストして調整を入れる余裕は無くなってしまいます。このような事態を避けるためには、より正確な見積りが重要になってきますが、その際はプログラマのタスクも考慮しましょう。

　可能であれば担当プログラマのタスクをデザイナー側で細かく管理するのが良いです。把握しておく事が重要です。

　これらは一見デザイナー側の負担が増えているようにも思えますが、全体の進行をスムーズにする上では非常に有効な手段です。例え少し煩わしい作業が増えたとしても、これはデザイナーの仕事ではないと一線を引かず、チャレンジすることが結果としてトータルスピードを早め、正解に近づく近道になります。