papanda デジタルプロダクトで備えるべきことを構想する際、UI(ユーザーインターフェース)からとりかかる考え方がある。仮にUIファーストと呼ぼう。クライアントとのプロダクトづくりの際に、UIファーストが求められる場合がある。
クライアント自身のエンジニアリング(モノづくり)経験が薄いと、UIファーストで進めようという意思を感じることが多い。何をつくろうとしているのか、何をつくっているのかを理解するのにUI=形態は目に見えて分かりやすい。
おそらくベンダー主導の開発プロジェクトを多く経験してきた方も、この「わかりやすさ」を手がかりにしようとすることが多いのではないか。むしろUIファーストなやり方はベンダー側の提案から始まったのかもしれない。UIファーストは、一見共通理解を得やすいように思える。
先日、久しぶりにこのUIファーストなモノづくりに直面した。あまりにも自然な始め方でかつ、ずいぶん昔にそのあり方は捨てていたため「ああUIファーストを求めているのだ」と気づいたのは、クライアントとのミーティングが進行して、その最中であった。
UIから考えないとしたら、何から考えるのか？ 長らくその説明の仕方に苦慮してきたが数年前に「代謝建築論」という書籍に出会ってから、説明がやりやすくなった。
物事を構想するにあたっては方向性と段階がある。すなわち、か(本質的段階)→かた(実体論的段階)→かたち(現象的段階)である。「か」は思考や原理、コンセプトを意味する。「かた」はその実現手段である。理解、原則、技術、機能といったところ。「かたち」は、触れるための境界、形態をあらわす。
この、か、かた、かたちは、課題→機能→形態と読み替えることができる。課題の解決のために機能がある。その機能を使えるようにするための形態(UI)がある。これらを考える順番は、機能からでも、形態からでもない、課題からである。これを課題ファーストと呼ぼう。
か→かた→かたちの順番が守られていないと、何のために必要なのか分からない機能、何を表現したいのか、何をユーザーにしてもらいたいのか分からないUIを、積み上げていってしまう可能性がある。かたち(形態)から検討をはじめると、か(課題)まで辿り着けない議論になることが多い。かたちの充実さを確認して、満足してしまう。
また、かたちだけで意思決定していると、選択肢を図らずとも絞ってしまっている可能性がある。例えば、UI上のある要素を表現するのに、ややこしそうな集計が必要になりそうと見えることでも、機能(データ構造)でみると大した問題ではないということがある。かたちだけで判断していると、見た目の困難さから選択を排除してまうことがありえる。
課題→機能→形態という構造は、マクロな構想でも、ミクロな構想でも使う。プロダクト全体の構想(マクロ)も、どういう課題をどのような手段(機能)で解決し、どのデバイスで使えるようにするのか(形態)と練る。ある機能について(ミクロ)も、どのユーザーストーリー・要求を、どのような機能で充足し、どう伝える、使えるようにするのか(形態)と検討する。
課題→機能→形態の順は、構築のための流れである。形態にしてみることで、構築段階では気づけなかったことが様々見えてくることがある。この認知は、形態→機能→課題というフィードバックの流れをつくる。そして、またそれを踏まえて課題→機能→形態という流れをたどる。プロダクトづくりはこの流れを行きつ戻りつしながら進める。
Photo on Visualhunt
