Chris Atherton氏がGOTO Berlin 2015カンファレンスで閉会講演を行い，ソフトウェアの設計について語った。講演の中で氏は，ソフトウェアがいかにあるべきかという専門家の意見に頼るよりも，外に出て実際のユーザの声を聞くべきだ，と提案した。InfoQは氏に，ユーザインターフェースの設計とテストについてインタビューした。
InfoQ: 基調講演 “You Can’t Always Get What You Want” では，システムの望ましい外観や動作の設計について話されていましたが，なぜそれが重要で，そして難しいのか，詳しく説明して頂けますか？
Atherton: 設計のよくないユーザインターフェース(UI)には，誰がどのような状況で使用するのか，という点の考慮が欠けています。この種の失敗は，(外見が趣味に合わないという程度の)ちょっとした不満で終わる場合もありますが，航空や医療といった産業では，文字通り生死に関わる問題にもなりかねません。実際に遭遇するほとんどのケースは，この両極端の中間，といったところでしょう。UIの中には，それを使う必要のある人たちにとって明確でないために不便を感じさせたり，実際のユーザとの調整が不十分なためにワークフローの考慮が不十分であったり，あるいはユーザが行うべきこととUIが行わせようとすることの間のミスマッチのために，非効率的で手間がかかるものがあります。
UI設計が難しいとはいっても，それは達成可能な難しさです。それが本当に不可能になるのは，実ユーザにアクセスする手段のない時です。その場合は，製品を実際に開発する設計者や開発者のチームが推測しなくてはなりません。チームがいかに前向きでも，あるいは推測がいかに優れたものであっても，実際にユーザではない以上，100%正確ということはあり得ません。とは言っても，この問題を解決するのは簡単です — ソフトウェアチームが実際のユーザに対して，定期的に製品を公開すればよいのです。プロトタイプをユーザに示してフィードバックを得るという，フィードバックをベースとしたイテレーションを行うのです。
InfoQ: システムを設計する場合，そのシステムに望む外観や動作に関して，設計者自身の経験とアイデアが反映されることが少なくありません。これはよい事なのでしょうか？
Atherton: システムに対して実際に求められる動作という意味であれば，自分自身のアイデアを出発点とすることに問題はないでしょう — 現時点で求められていることと，すでに完了していることの差異について，プロジェクトの参加者が事前に理解する上では非常に有用だと思います。直接的に，あるいは少しの修正で流用可能な，簡単な設計ソリューションが存在するかも知れないからです。ですが，それが最終的なものになることはありません。新しいシステムは，すでに解決済みの類似の問題を適用するのではなく，システムを実際に使用するユーザのニーズによって進められなくてはならないのです。この場合も，本当のユーザと現実の問題をチーム全体が認識することで，既存の考え方を抜け出し，私たちはよいと考えていたが，実際には正しくなかった設計に対するフィードバックを得られます。設計されたソリューションの動作に対する意見だけでは十分ではありません — それをテストし，有用性についての実際のデータを取得することも必要です。ですから２人の開発者が，どちらの方法が“よい”のかを議論するというのは，あまり意味のあることではありません — ユーザに見せて意見を聞くべきです。彼らが専門家なのですから。
InfoQ: 設計が優れていても意図が十分でなかった，という例をあげて頂けますか？UIの設計が問題だったのでしょうか？
Atherton: そうですね，まず最初に指摘しなければならないと思うのは，意図的に問題を起こす人はいない，ということです — 必要な情報というのは，なかなか自由には手に入らないものなのです :) 例えば，私は以前に，非常に手の込んだダッシュボードを設計したことがあります。与えられていた要件は，ダッシュボードに表示されている情報の閲覧と変更が可能であること，というものでした。そこで私は，情報の検索，フィルタリング，ソートなど，レイアウトやインタラクション設計にかなり工夫をしました。扱うデータ量が多かったので，長々としたリストから必要なものを探すような操作を，ユーザに求めたくはなかったのです。それをクライアントに見せたところ，“でも実際にエンドユーザが見たいのは，６つ程度ですよ。それも事前に分かっている場合がほとんどですし，変更が必要なのは，せいぜい２つか３つです。” そういうことならば，UIに対する取り組みも全然変わってきますよね！つまり，よい設計をしようという意思があり，十分に確立されたデザインパターンを使用して使いやすいものを作ろうとしていたのですが，ユーザが実際に行おうとしていたことにうまくマッピングされていなかったのです。この件では，最低限必要なものだけを表示した，ごく単純な設計に落ち着きました。
InfoQ: 意見に頼らずにデータを取得すべき，というのがあなたの提案ですが，データの入手が難しかったり，あるいは実際に使用するユーザから本当の証拠を手に入れたくても，それが困難であったり，対価を伴うような場合もあると思います。そういった場合には，どのように対処すればよいでのでしょう？
Atherton: まず，基本的なデータを得るために必要なコストは，それほど高くはないと思います。意味のあるフィードバックを提供してくれる人(本当のユーザか，合理的な代理人となる誰か)を特定して，直接席を同じくするか，インターネット経由でやり取りすれば，設計やプロトタイプ，あるいは取りあえず作ったものに対するフィードバックを得ることは可能です。セッションを始めた途端に，設計の変更の必要な場所が分かるはずです。何が最も重要なのかをより明確にするためには，これを何度か行う必要があります。６人中４人は失敗するという場合もあるでしょうし，あるいは実際問題として，数十万人のユーザの行動をひとりで見極めるのは不可能なことだからです。
もうひとつの面から言えるのは，この作業を*行わない*ほど余裕のある会社はないはずだ，ということです。プロジェクトのリスクを低減するには，これが間違いなく最高の方法なのです。ユーザ向けに何らかの開発を行う場合，彼らのニーズが分からないということは，コストもリスクも非常に高くなります。開発が完了するまで設計上の問題点を特定できないとすれば，目的に対して適応しないものをリリースするという大きなリスクを抱えるか，あるいは，多大なコストを費やして修正を行うという別のリスクを抱えることになるでしょう。
InfoQ: ソフトウェア製品の設計をテストする時に，適用可能なアプローチをいくつか紹介して頂くことはできますか？
アサートン: もちろんです。軽いタッチのアプローチとしては，紙やホワイトボードなど，何でもよいですからスケッチしたものを内部で見せて，どう実現するつもりなのか説明しながら，何らかの指摘をしてもらう，という方法があります。実施すべき作業についての理解を共有することは不可欠です。簡単なスケッチを共有するだけでも，いくつかの仮定を明らかにすることができます。関係者の数が多い場合は，特にこれが大切です。シナリオが複雑な場合，あるいはエンドユーザにも見て欲しい場合は，BalsamiqやAxureといったツールを使って，ワイヤフレームやモックアップを組み上げるのがよいでしょう — それほど忠実なものである必要はなく，視覚的なレイアウトが確認できれば十分です。その画面でどのようなことが起こるのか，次に何をするのか，それによってどのようなアウトプットを期待するのか，ユーザの理解を直接聞くことができます。ワイヤフレームよりもよいのは，実際にクリック可能なプロトタイプを作ることです。これも同じように，高い忠実性は必要はありません。インタラクションと遷移を示すことさえできれば，ユーザや内部関係者が画面間のフローを意識しやすくなります。エンドツーエンドの操作がどのようなものになるのか，理解を得られるでしょう。
本番のコードでプロトタイプをするべきか(フィードバックに対する修正を素早く設計に反映できる反面，最初のプロトタイプ立ち上げには時間がかかります)，あるいはSketchやInVisonのような使い捨てのプロトタイプツールでよいから，新しい設計を早く立ち上げてクリック可能にするべきか，という点については，しばしば議論の的になっています。ですが，正しい答はないと私は思います。チームが利用可能なリソースや，所持しているスキルセットによるでしょう。重要なのは何であれ，何かを見せること，そして早くフィードバックを得ることなのです。
InfoQ: ユーザインターフェースを設計する上で，これは言っておきたい，というアドバイスは他にありますか？
Atherton: 設計に対して何らかのフィードバックがあるというのは，何もないよりも望ましいことは間違いありません。話をするユーザがひとりだけであっても，あなたがそれまでやってきたこととは違う，あるいはそれ以上のことを，少なくともひとつは学べるはずです。時間が掛かる訳でも，費用が掛かる訳でもありません — 実際，ユーザと６時間を過ごすコストと，その６時間を使わないことによる潜在的ビジネスコストを比較すれば，考えるまでもないことです。