「UIデザインの心構️え」ではなく 「ソフトウェア開発の心構えをUIデザインで意識する」
ソフトウェア開発の思想はUIデザイナーでも共感できる
『UNIXという考え方―その設計思想と哲学』を読みました。
日本語版は2001年に刊行とのことでそこそこ古い本ですが、はてブで検索してみると最近でもおすすめ書籍として頻繁に紹介される有名な本のようですね。
内容としては、UNIXにおける様々な実例を引用しながら「ソフトウェア開発かくあるべき」という思想・哲学を教えてくれる本です。
一応、自分はWeb開発はMacで行っていますし、卒論でROSと遊んだ際にはUbuntuを動かしたりなんかもしたことはありますが、バリバリロジックは書けませんし、UIデザインが人並みにできるだけなので、ソフトウェア開発者を名乗ることはできません。
その上、UNIX系列以外のOSとCUIで真面目に対話したことはないので、UNIX以外のOSは知らないに等しいです(昔Windowsで無理やりWeb開発してたこともあるけど、その時はド素人だったので環境構築も全部頼りきり…その節はすみませんでした 🐢)。
すなわち、①UNIXを触ることはあっても本質的に理解はしていない ②UNIX以外を知らないのでUNIXと比較できない という、この本を読むにあたっては悲しい2条件を持ち合わせています。
なので、「この書籍の言うことは普段から思っていたことに一致しているし納得感はあるけど、①②のせいで語られる根拠まで深く腹落ちはできない」という感想になりました(いい本だとは思います。薄くてすぐ読めるのでみんな買おう！)。
しかし、無いものは無いので、深く腹落ちできないことを嘆いても仕方ありません。むしろ強調したいのは「普段から思っていたことに一致しているし納得感はある」という部分です。なぜこのように自分は感じたのでしょうか。
それは、曲がりなりにもUIデザイナーとして複数のプロダクトの開発に携わり、失敗し、学んできた経験があるからだと思います。そうした試行の中で「UIデザインかくあるべき」といった個人的な思想も一定の規模には育っているのです。
そして、大事なのは、その個人的なUIデザインに関する思想がこの書籍で語られるソフトウェア開発の思想と合致すると感じる部分が大きかったことです。
なぜ共感できたのか？
「そりゃあインターネット界隈で語られるUIデザインというのはソフトウェアのユーザーインターフェースのデザインなんだから、ソフトウェア開発の思想と合致するのは当然だろう」と思うかもしれません。
結論それはおっしゃる通りで、しかもこのブログの要旨でもあります。
ただ、それが本当に普遍的に認識されているかというとNoだと自分は思うので、一つエピソードを書きます。
UIデザインの敗北
最近あるツイートを見かけました。曰く、
大手toCサービスのヘルプページでチャットボットが採用されている。結局『対話している感』がユーザーにとって重要(= デザインの良/悪を決める)なのであればUIデザイナーがヘルプページを丁寧に(OOUIに従って)デザインすることに価値はなく、これはUIデザインの敗北なのでは？
といった趣旨のものでした(意訳)。
toCサービスにおけるヘルプページの特異性(例えば、操作の習熟を促す必要がなく、その場限りの解決だけ提供できればいいという特性)や、対話型インターフェースのCons(例えば、速度においてクリック型UIに劣るといった点)が考慮されていないのでそもそもこの内容には疑問を感じたのですが、それは一旦置いておきます。
ここで考えたいのは「UIデザインの敗北なのでは？」という「問いかけ」です。
「命題Aはtrueなのでは？」という「問いかけ」を行うとき、その主体は「今まで一般的にそうは考えられていなかったが、僕はAがtrueだと考えている」という意図を持っているはずです。
僕はここに大きな違和感を覚えました。なぜなら、僕だったらこの問いかけに対して「UIデザインは最初から敗北している」と答えるからです。言い換えると、問いかけが成立するような命題じゃないと考えているからです。
文章の対応関係を明確にするために「UIデザインは敗北している」なんて強い言葉を使ってしまいましたが、正確には自分が言いたいのは「UIデザインによって何か本質的なパラダイムシフトが起きる = 勝利する」ということはあり得ない、という話です。
“Interface is not King”
ちょっと前にTHE GUILDの深津さんの一連のツイートがバズっていましたよね。非常に端的でわかりやすい比喩だと思います。
2ツイート目の3枚の画像を言語化すると
- コンテンツGood ×インターフェースGood = 体験Good
- コンテンツGood ×インターフェースBad = 体験Bad
- コンテンツBad ×インターフェースBad = 体験Bad
という関係性が見えてくると思います。コンテンツとインターフェース、どちらかだけでもBadであれば全体の体験はBadになってしまうということですね。
つまり、コンテンツとインターフェースはどちらも大事です。
ところがこの2つは同列ではないと自分は考えます。コンテンツの品質が向上すればそれに比例して体験も向上しますが、コンテンツが変わらずインターフェースばかり向上しても、体験はそれには比例しないと思うわけです。
その理由は、あくまでインターフェースは「コンテンツとユーザーのインタラクションを阻害しないこと」が理想状態だからです。
インターフェースはコンテンツを台無しにすることはあっても、コンテンツをそのポテンシャル以上に引き上げることはないのです。あくまで、コンテンツのポテンシャルを100%引き出すことが理想状態です。
上記の例になぞらえると、鍋料理を食するの体験の上限を決めるのは食材や調理方法であって、箸の使いやすさではないよね、というのは経験則的に理解できると思います。
さらに別の言い方をすると、“Content is King” ということです。すなわち “Interface is not King” です(後者は造語です)。
UIデザインがソフトウェアとしての本質的な差を埋めることはない
さて、「インターフェースがいかに優れていても、コンテンツとしてのポテンシャルの差をひっくり返すことはない」という話をしました。
本題に戻って、これをソフトウェアとそのUIの関係性として考えると「UIデザインがいかに優れていても、ソフトウェアとしての本質的な差を埋めることはない」と言えるのではないでしょうか。
最初の例に戻ると、静的なヘルプページとチャットボットは、ソフトウェアとしてあまりにも本質的な差がありすぎます。そして、その本質的な差をUIデザインが埋める(= UIデザインが勝利する)ということはあり得ないので、件の問いかけはそもそも成立しない(= 敗北という概念は存在しない)んじゃないか？ということを言いたいのでした。
(改めて強調しますが、チャットボットはソフトウェアとして静的ページよりリッチなのは間違いないものの、Pros/Consそれぞれあり常に静的なページより優っているとは限りません。)
余談: 謙虚さは失わないようにしたいもの
(ソフトウェアを競争力の源泉とするビジネスにおける)デザインの重要性が日本でも声高に叫ばれるようになって久しいです。
もちろんデザインは大事です。それは自分自身がデザイナーとしてわかっているつもりです。ただ、「デザインこそが世界を変える」みたいな過激・傲慢な物言いは避けたいものです。少なくとも我々の領域においては、デザインとエンジニアリングのコラボレーションこそが本質的な価値を生むのです。
なので、上記のようなあからさまに傲慢な物言いでなくとも、エンジニアリングの存在を無視してデザインの観点だけで価値がどうこう、という議論をしてしまうのも同様の傲慢さを秘めているのではないかと思うわけです。
議論を進めやすくするためにエンジニアリングとデザインの話に閉じていますが、本当は全部大事です。セールス、BizDev、コーポレート、ファイナンス、HR、カスタマーサクセス、PR、マーケティング…挙げればキリがないですが、そうやってお互いの職種に敬意を払えるような人と一緒に働きたいですね。
UIデザインはソフトウェア開発の一部
だいぶ脇道に逸れてしまいました。元々は自分が『UNIXという考え方』を読んで、
個人的なUIデザインに関する思想がこの書籍で語られるソフトウェア開発の思想と合致すると感じる部分が大きかった
と、感じることができたのはなぜか？という話をしたいのでしたね。
結論として、ここまで触れてきたようにUIデザインは「ソフトウェアのポテンシャルを最大限引き出すためのもの」でした。すなわちここには明確な従属関係が存在し、UIデザインはソフトウェア開発の一部なのです。
なるほど、UIデザインがソフトウェア開発のためのさまざまな要素の部分集合なのであれば、その思想が一致することはなんら不思議なことではないと言えそうです。自分は、自分自身が得た納得感をこのように解釈しました。
具体的にはどのような合致が見られるのか？
じゃあその合致具合は具体的にはどんなもんなのよ、というのを解説していこうと思います。ここまでの内容だとポエムしかないなので、多少は具体的な内容に落とし込もうという取り組みです。
書籍の内容を引用しつつそれはUIデザイナーの思想としてはこのように翻訳できるよね、ということをまとめていけば、この書籍の内容から帰納される「UIデザイナーの心構え」となるのではないでしょうか。
もちろん、ここでいうUIデザイナーというのはソフトウェア開発に従属する役割です。
書籍の内容を完璧に一対一対応で落とし込むことは難しそうですが、理想としては「UIデザイナーの心構え」を作ることを目標に以下の話を進めていきましょう。
前提: 『UNIXという考え方』の構成
この本は9つの「定理」を紹介するという構成になっています。この定理が、自分がソフトウェア開発の思想と呼んでいるものですが、それは以下の9つです。
- スモール・イズ・ビューティフル
- 一つのプログラムには一つのことをうまくやらせる
- できるだけ早く試作をする
- 効率より移植性
- 数値データはASCIIフラットファイルに保存する
- ソフトウェアの梃子(てこ)を有効に活用する
- シェルスクリプトを使うことで梃子の効果と移植性を高める
- 過度の対話的インタフェースを避ける
- すべてのプログラムをフィルタにする
それぞれ見ていきましょう。
1. スモール・イズ・ビューティフル
1–1. 書籍の内容
何かしらの処理を実行するプログラムを書きたい時に、一つの巨大なプログラムを書くのではなく、小さな複数のプログラムを組み合わせて実装しよう。そうすると保守性の高さ、軽量化、他ツールとの連携のしやすさといった恩恵が得られる。
1–2. UIデザイナーの心構え
Component設計に関して同様の考えを反映できそうです。多少面倒であっても、アイコンレベルの要素からしっかりと(Figma等で)Component設計を行うと、実装の方針もそれに従って立てやすく、デザインデータの保守性等さまざまなメリットが得られるでしょう。
2. 一つのプログラムには一つのことをうまくやらせる
2–1. 書籍の内容
多機能主義の誘惑に負けないようにしよう。余計なクリエイティビティがシステムを肥大化させてしまう。「何を達成したいか」を本質的に理解していれば余計な機能は足さずに、シンプルに保てるはずだ(1. とは補い合う関係にある)。
2–2. UIデザイナーの心構え
いわゆる単一責任の原則ですね。
ゼロイチフェーズにおいてはMVPの要件を決定する時に意識すると良いでしょう。「何を達成したいか」を本質的に理解していれば極小のMVPを作れるはず。
また、Componentや画面のデザインにおいても同様の思想が反映できそうです。ひとつひとつのComponentや画面で達成したいことが明快になっていれば、それは高いユーザビリティを実現するでしょう。
同一のアイコンや、同一の色が複数の役割を持っていたら開発者にとってもユーザーにとってもフレンドリーでないことは言わずもがなですね。
3. できるだけ早く試作をする
3–1. 書籍の内容
多くの人が考える「正しい設計思想」とは反するが、完璧な設計や仕様を作る前にまず試作をしよう。大至急だ。
いち早く試作をリリースすることは、チーム内の目標を具体化するinternalな効果がある。そして何より少数のユーザーからのフィードバックをいち早く得て、作り込んでリリースした後に数百万のユーザーからそっぽを向かれて作り直しになるリスクを減らすことができる。
正しい設計は1通りしかないが、間違った設計は数百通りもある。より速い段階から誤りを取り除く為に試作をしよう。
3–2. UIデザイナーの心構え
これはデザイナーにとって特に大事な概念だと思います。そもそもなぜ多くのUIデザインにおいて「まずカンプを作る」ということから入るのか、なぜいきなり実装しないのかというと、それは素早い試作のためですよね。
基本的にコードを書くより、GUIでパーツを作成し、ロジックは紙芝居形式で誤魔化したものを作る方が早いのです。そのためにプロトタイピングツールも充実した世の中になっています、生かさない手はありません。
UIデザイナーの仕事とは、いち早く製品のプロトタイプとしてのデザインカンプを作成し、しかもそれは「実装担当のエンジニアに対して提示する正解」なのではなく、「チーム内の目標を具体的に共有し、設計の誤りをいち早く見つけるためのもの」という考え方を持つことが大事ではないでしょうか。
4. 効率より移植性
4–1. 書籍の内容
速度を重視するあまり、ハードウェアに最適化されたコードを書かないようにしよう。どうせ次の四半期に現れるハードウェアは速度が向上しているのだから、「今存在するハードウェアで最速で動くソフトウェア」ではなく、「次世代のより速いハードウェアに最小工数で移植できるソフトウェア」を書こう。
4–2. UIデザイナーの心構え
ハードウェアの速度の進化の話をしているので、これはそのまま転用することは難しそうです。
ただ、デザインデータに関しても相似系のことは言えそうです。何か新しく登場したデザイン/プロトタイピングツールがあったとして、そのツールがすぐに廃れてしまう可能性もあります。
そこに自社のデータを移植不可能な形で置いてしまったとすると、短期的にはそのツールによるメリットがあったとしても、長期的にはがんじがらめになって大きなデメリットを生むかもしれません。
まあ、FigmaはSketchデータのimport機能を備えていましたし、そういった機能の提供はSaaSあるあるですし、デファクトスタンダードなツールの数年スパンでしか起こらないのでめちゃくちゃ気にはしなくていいかもしれません。
ただ、新しいツールの組織での採用は少し慎重なくらいがいいでしょう。そのツールが流行しなければimport機能も提供されないでしょうし
5. 数値データはASCIIフラットファイルに保存する
5–1. 書籍の内容
数値データを、バイナリファイルではなく、共通の交換形式であり、簡単に読み編集できるASCII文字のファイルに保存し、移植性を高めよう。
5–2. UIデザイナーの心構え
4と似た移植性重視の話なので、これに関してはもうあまり言えることはないのです 😢
6. ソフトウェアの梃子(てこ)を有効に活用する
6–1. 書籍の内容
良いプログラマは良いコードを書く。偉大なプログラマは良いコードを借りてくる。独自技術症候群に陥らず、車輪の再発明を避けよう。
また、自分が書くコードは最大限他者が活用できるものにしよう。
6–2. UIデザイナーの心構え
車輪の再発明をしない、というのはスッと受け入れられる概念ですね。この時代、大規模なデザインシステムですら多数世の中に公開されています。独自に考えるのではなく、まずは巨人の肩に乗っていきたいものです。
7. シェルスクリプトを使うことで梃子の効果と移植性を高める
7–1. 書籍の内容
シェルスクリプトの梃子の効果は偉大だ。C言語で書く誘惑に負けないようにしよう。
7–2. UIデザイナーの心構え
これは6の概念をシェルスクリプト個別の話題で拡張したトピックなので、特に書くことはありません。
8. 過度の対話的インタフェースを避ける
8–1. 書籍の内容
独自のプロトコルを定義し、ユーザーと対話するようなリッチなインターフェースを実装しないようにしよう。
プログラムの実行においてボトルネックになるのは人間の応答スピードであるので、UNIXは不可逆なアクションの場合しかユーザーに確認を求めないことで最大速度で稼働する。
また、そのような対話的なソフトウェアは以下のようなデメリットもある。
- 巨大なソフトウェアとなって保守性が落ちる
- 他のプログラムと結合しづらく、梃子の効果を発揮しない
- スケーラビリティに欠ける
8–2. UIデザイナーの心構え
これは別で一本記事をかけそうなくらいに重要な要素だと考えています。
UIデザイナーは常に「これでユーザーに通じるだろうか」という恐怖と闘っている職業です。最終的にプロトタイピングやデータを通じて検証すべきですが、常にそのような時間のかかる検証を行うわけにはいきません。
そこで過度に説明的なUIを作ってしまうことはかなりありがちな行為であると自分は思います。しかしそこで勇気を持って説明的にはならず、ユーザーの学習に期待すべきというスタンスを持つことが大事だと自分は考えます。
極端な例ですが、あなたがiPhoneでTwitterアプリを開きたいときに対話型UIの極致であるSiriにそれをお願いするでしょうか？もし、その行為が初めてのことで、ユーザーがアプリのアイコンを見つけるのが困難な場合はSiriに軍配が上がるかもしれません。
ですが、2回目以降はどうでしょう。絶対に、ユーザー自身に操作させる方が早いはずです。そしてツイ廃でなくとも、Twitterアプリを開くという行為はこの後幾度となく繰り返される行為でしょう。
すなわちトータルで考えたとき、「ユーザーに説明する」ではなく「ユーザーが学習できるようにする」ことで得られる複利が大きいということは常に意識すべきことでしょう。
これはヤコブ・ニールセンを参照しても言われていることですし、OOUIが正義とされている理由の一つでもあるはずです。
(記事冒頭の話に少し戻りますが、ヘルプページに訪問する回数は最低限にしたいので、そういう場合はチャットボットが有効かもしれませんね。)
9. すべてのプログラムをフィルタにする
9–1. 書籍の内容
コンピュータの出現以来、書かれてきた全てのプログラムはフィルタである。すなわち、その本質は何かしらのinputを受け取って何かしらのoutputを返すI/O関係にあるということだ。
UNIXではstdin, stdoutの標準入出力チャネルが存在するので、適切に利用しよう。これらはどこからでもデータを受け取れるし、どこに対してもデータを出力できるので、自由度の低いインターフェイスにならなくて済む。また、帯域外のデータはstderrで出力し、きちんと区別しよう。
9–2. 書籍の内容
これも大事な考え方です。皆さんがUIをデザインする対象はソフトウェアであるわけですが、じゃあソフトウェアとは何かというと、I/Oを行うものだという話です。
そこで、inputのためのインターフェースはなるべく自由でなければいけません。例えば、CSVによるデータ入力しか許可されていないとか、決まった順番でのみフォームを入力しなければいけないだとか、そういった不自由は避けなければいけでしょう。
outputも再利用性の高い形であることが大事でしょう。例えば自分のinputに応じて何が変化したのか不明瞭であるとか、outputがPDFでしか返されずコピペしたいのにできないとか、そういった不自由を避けたいものです。
そして最後に、帯域外のデータは「エラー」として明確に区別して返すことです。これはただ、エラーを返せばいいというわけではなく、そもそも帯域外のデータを入力させないという努力も大事だと思います(一見、上記のinputの不自由を避ける話と矛盾しそうですがそうではありません)。
何か帯域外のデータが入力された場合にサーバーに送信する前にクライアント側でバリデーションしエラーを表示するとか、ラジオボタン・チェックボックスを用いて帯域外のデータが生まれないようにするだとか、そうした細かい努力で(ユーザーが自由なまま)システムの中で迷わないようにしましょう。
終わりに
ある知識を別の切り口から見つめ直すというのは、より深い理解のために有効なことだと思います。「これ進研ゼミで見たやつだ！」はテストの点が取れるから大事なのではなく、その瞬間に真に知識が定着するから大事だと思うんですよね。
なので、この記事で書かれていることが体系的に役に立つかというと怪しいですが、知識の咀嚼に役立つ内容だと思います。体系的な話はHIGとかデザイン専門の書籍とかその辺りの役割です。
最後に弊社の宣伝。そろそろプロダクトのセキュリティ考えないとな〜と思ってる方のために「セキュリティ診断の料金を自分で計算できる」資料をDLできるようにしているので、ぜひチェックしてください💰
今のところ明確な求人は表示してないですが、常に人手には困っているので、サイバーセキュリティ事業をデザインの力で支えたいというデザイナーの方もお待ちしてます！話を聞きたいだけでも大丈夫なので、ぜひTwitter @toyojuni までDMください🙌
