IAレイヤーでデザインの会話ができる組織は、うまくいく。説。

インハウスで新しいプロダクトや事業を作っていくうえで、広い意味でデザインの力が問われていることはもはや疑う余地がないなと思う昨今。

デザイナーだけでなくノンデザイナーさんも一緒になって、良いプロダクトを生み出していける組織になっていくためには何が必要なんだろうとよく悩んでいます。


最近の僕は、「みんながプロダクトの作り手として、プロダクトの提供価値を高めるためのディスカッションに参加できればいいんだろう」と思うようになりました。そして、「そのディスカッションでは何について話せばいいんだろう?」と考えるようになりました。

実際のデザインを作ったりコードを書くという専門的な仕事よりも上流の工程で、プロダクトの価値そのものについて議論できるような、そして組織内の共通言語によって会話が成立するようなレイヤーがないかと考えたところ、僕的にはそれがInformation Architecture(IA)なのかなと。


 *  *  *

そんなことを思ったので、早速僕は、社内のメンバーたちに向けてプロダクト作りの話とInformation Architectureの話をしました。けっこうみんな頷きながら聞いてくれて反応が良かったので、資料を公開したいと思います。

Design Talk#2 Information Architecture 1/2 - Speaker Deck


今回のLT内容は前半で、後半ではより具体的な例やクイズを入れながらイメージを掴んでもらおうと思っています。


話した内容はリンク先の資料にあるので置いといて、話し終わった後に社員さんたちから上がった質疑応答も、良い質問ばかりだったので一部載せておきます。


Q1. ワイヤーフレームってもしかして・・?

あるPMさんは、この話を聞いて、まっさきにワイヤーフレーム(WF)のことを思い出したそうです。

Web制作の現場とかだと、とりあえずWFを作ることから始まる組織も多いかと思うのですが、そもそもWFの役割って何だろう?とか、何故デザイナーに仕事渡すときにWFをディレクターが書くの?とか、悩んだり相談を受けることが多いかと思います。

「WFはIAの認識を揃えるための議論のたたき台であって、ビジュアルデザインの素案ではない」

というのが僕の主張ですが、このあたりはWFについての誤解がいろんな悲劇を生んでいるケースをよく聞くので、後日記事にまとめたいと思います。


Q2. IAのPriorityってわかるもの?どう決めてる?

情報を客観的に整理するところは、ある程度言語化が得意な人なら全然イケて、一般的な感覚値が求められるところは類似サービスを調べたり、調査データから統計値を引っ張ってきたり、ユーザヒアリングで当たりをつけたりします。

IAは客観的に整理するだけじゃなくて、「自分のサービスがどうありたいか & どのように伝えたいか」に合わせてPriorityを付けたり、情報を再構成したりします。この「自分のサービスとしてはどういうIAがいいのか」を考えるのが難しいです。

僕の場合は、他人にサービス説明を繰り返す中でIAをブラッシュアップしていくという手段をよく採用します。他人に僕のサービスを説明するときに言葉遣いや説明の順番などを変えながら喋ってみて、「1番説明要素が少なくて伝わりやすい説明」を見つけるんです。それが見つかったら、冷静にIAに落とし込んでみる。そのIAはメンタルモデルとして優秀だったり、Onboardingのデザインに直結したりします。

少し別シーンの例ですが、プレゼンテーション資料を作るときも、いきなりスライド作るんじゃなくてまずはアウトラインを作ってわかりやすいか確認したりブラッシュアップしてから、スライドに仕上げるじゃないですか。あれと同じような感覚かもしれません。

また、「変更に強いIAなのか」「たいした根拠もないのに大胆な意思決定をしすぎていないか」というところも常に気を配っています。ここをミスると明らかな仮説外れが発見された後でも方向転換しづらくなって自分の首を絞めるので。


Q3. IA決めたけど画面に入りきらなかったら?

これはとても良い質問で、端的に言うと「UIデザイン上の都合でIAを修正するという判断はアリなのか」ということなのですが、僕の結論はアリで、むしろナシとしてしまうのは悲劇を生むと思っています。

UIデザインには画面サイズの制約もあるし、OS標準の制約もあります。IA整理できたつもりでも、UIデザインしてモバイル画面で見てみると情報過多だから情報の粒度を変えないといけないとか、もう1つ上位概念を追加して説明した後に次の画面で具体例を伝えないとアクションがイメージできないみたいなことがいくらでも出てきます。

「客観的に情報を整理すればいい」わけではなく、「伝わりやすさを考慮して整理する」必要があって、その伝わりやすさに少なからずOSやデバイス、閲覧環境(室内・屋外・シラフ・酔ってる)、VDアイディアが思いつくかといった要因が絡むので、「UIデザインをしていたらIAにフィードバックが返る」ということはザラです。

例えば「何かの一覧画面」ってよくあると思うんですが、この画面にどんなIAを採用するかは、いろんな情報やステータスをわかりやすく表現できるVD工夫を思いつくかどうかで変わります。全然思いつかなければIA側で極力情報を減らすしかないし、アイディアが思いつけばカラーやサイズ、マーク等を使って、スペースを使わずに表現の幅を広げることができます。


以上、質問紹介でした。


 *  *  *

やっぱりノンデザイナーさんへの発信は大切

「なんでデザインLT始めたんですか?」と聞かれることもあるんですが、それはノンデザイナーさんへの発信をとても重要視しているからです。

僕個人のデザインスキルを上げることももちろん大事ですが、組織・チームで結果を出すことを考えたら、いま時間を使うべきなのはこっちだな と思いました。


プロダクト開発にはいろんな職種のメンバーが関わります。それぞれが専門性を持っているからチームができて、各メンバーの専門性をプロダクトに結集できるかどうかが鍵になります。

プロダクトとして、デザインとして、大きな意思決定をするときにはいろんな職種とコミュニケーションをとって進めていきます。思い切ったことをするためには、ノンデザイナーさんとのコラボレーションが不可欠です。

「みんながデザインを理解すればいい」みたいな方向性もなくはないと思いますが、そんな環境は稀だと思いますし、何よりチームとしてのダイバーシティが小さくなってしまうことで、チームの最大パフォーマンスやあらゆる変化への柔軟性は低下するんじゃないかなと思います(感覚的な理由ですいません)。


自分がプロのデザイナーとしてチーム内で役割を持っている以上、自分以外がデザインに明るくないことは、当たり前だと思うんです。逆に、デザイン能力がまだ読み書き能力や基本PCスキルみたいにコモディティ化していないからこそ、自分の役割が成立している。

だとすると、「チームメンバーが自分以外デザインに明るくなかったとしても、良いデザインのプロダクトがチームとしてアウトプットできること」がとても大事で、それを実現するために必要な仕事すべてを期待されているし、それを果たさないといけないなと思っています。


とりあえず僕は、社内でデザイン系の話をノンデザイナーさん向けに喋り倒す会を始めてみることにしました。隔週で1回20〜30分、僕がテーマを決めてLTをする。

まだ始まったばかりの会ですが、今後も続けていきます。

第1回LT資料はこちら - Speaker Deck
※スライドで使われている動画(アニメーションgif)2本は、ファイル形式の関係で動きません


最後に

まあ、それにしても隔週で20分喋り倒すのはさすがに追い込みすぎた感があってですね...

ネタ切れ待った無しなので、いろいろ募集しています。

・こんなネタを扱ってほしい
  ※実際に使ったスライドは公開します
・こんなことで困っているなう
・自分が1回喋ってもあげてもいいよ
・デザイナーとして入社して分担してあげるよ


次回は Information Architecture 2/2 を喋ったらまた投稿します。

それでは。

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

note.user.nickname || note.user.urlname

最後まで読んでいただき、ありがとうございます。 またタイミング見て記事を書くので良かったら見にきてください。

ありがとうございます!
21

ikutani41

PM & UI/UX Designer. Freelance (Ex-AnyPay, Inc.) UI/UX Designの話とPM・組織の話を定期的に書きます。 Slides here: https://speakerdeck.com/ikutani41

#デザイン 記事まとめ

デザイン系の記事を収集してまとめるマガジン。ハッシュタグ #デザイン のついた記事などをチェックしています。広告プロモーションがメインのものは、基本的にはNGの方向で運用します。
2つ のマガジンに含まれています

コメント1件

「Information Architecture 2/2」も喋ったので続編の記事を投稿しました。
https://note.mu/ikutani41/n/nf6bb53eb13c9
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。