試行錯誤の過程をもっと公開しよう! — デザインプロセスの5つの事例

Source

デザイナーのポートフォリオを見ると、美しく洗練されていて隙がないものが多い。しかし、それは注がれた努力の一部であって、最終的な決断の結果しか見ることができない。

実際には、進行中のプロジェクトの多くは乱雑で整頓されていない状態だ。そこには人目には晒されることのない、中途半端なリサーチや議論の痕跡が残っている。一見何でもないように見えるデザインにも、完成版に至るまでに様々な試行錯誤があるはずなのだ。

この様な作業の大半は、残念ながらPCのごみ箱行きか、日の目を見ずに終わってしまう。しかし、そういったリアルなデザインのプロセスこそ、もっと人に見てもらうべきだ。それらは自分の思考過程を説明するものであり、完成版を評価するときの判断材料となるからだ。(就職の面接の場であっても、そのプロセスを見せることで、採用者の目に留まりやすくなる。結果より過程の方が時には価値があるのだ。)

これは私たちがデザインの決断の記事で考えてきたことだ。それを基に最近のBasecampでの試行錯誤した5つの事例をご紹介しよう。

1. ボタンの表示・非表示

些細なことが大きな波紋を呼ぶことがある。コメントのアーカイブを行う際に、「アーカイブ」のボタンを常に表示しておくのか、あるいは「アーカイブ」ボタンを表示するための「まとめてアーカイブ」ボタンを用意するのか議論になった。

アーカイブは頻繁に使用する機能ではないため、目立たせる必要はあるのか考えた。キーボードのショートカットのボタンに隠し、隠れたボタンにすることも検討した。最終的にはボタンを表示しても問題ないという意見に落ち着いた。結果として、ディスカッションのページを邪魔することもなく、見やすく、使いやすくすることに成功した。

2. 単一キーワードリンク

複数のファイルのダウンロードには、デザイン作業はそれほどなかったが、テキストの決定に思いのほか時間が費やされ、リリース後にも変更を加えてしまうほどであった。

download-link

3. レアケースの修正

Basecampのように大きなプロダクトに携わるとあらゆる場面でレアケースの発生に遭遇する。私たちは、to doリストの項目の移動 をする機能を追加するとき、移動先がなかった場合にどうなるのか考える必要があった。ほとんどの人が遭遇しない状況ではあるが、遭遇する人にとっては問題になる。

moving-a-todo

4. 添付ファイルの表示方法

大きな挑戦となったのが、to do項目にファイルを添付することだ。ファイルのサムネイルをto do項目の横に表示するのか決める必要があった。to do項目にはすでに多くの要素があったため悩んだ。サムネイルの大きさを変更して試すことにした。

議論の末、大きいサムネイルは煩わしく、小さいサムネイルは使いにくいとの結論になった。そのため、サムネイルではなく、クリップアイコンを採用することにした。
1697-to-dos-paperclip

5. 基本的な文法

英文法に沿った文にするのか、ソフトウェアの条件に一致する言い回しをプログラミングするのかは常に迷うところだ。そのため、1 to-dos added successfully(1 to-dos の追加に成功)のように、単数形と複数形のような単純な誤りが見られる場合がある。この様な間違いを解消することは芸術的とも言える。文章にしたいことと、条件式を使うことなくコードで可能にすることとの葛藤が常にある。既存のプロジェクトをベースにプロジェクトのテンプレートを作成する際に、to do項目をまとめて移動できるオプションを追加した。基本的な英文法を損なうことなく、プログラミングできる分かりやすい言い回しにたどり着くまで時間を費やした。

1701-grammar


以上が最近手を焼いた事例のほんの一部だ。きっと皆さんにも披露できる試行錯誤の作業過程があるのではないだろうか。