そのプロダクトのデザイン原則、いつ作る?今でしょ!
こんにちは!デザインチーム所属のnagaiです。
今回は、弊チームが自社プロダクトのデザイン原則を考案した流れについて、どう取り組んできたかご紹介していきます。
これからプロダクトにおいてデザイン原則を作成しようと考えている方の参考になればと思います!
デザイン原則の必要性
まず、デザイン原則とは何か? これについては以前執筆した記事(ワイガヤ方式を活用してデザイン原則を考える)で簡単に紹介しているので、よければぜひご覧ください。
デザイン原則とは?
上記記事でも述べましたが、そのプロダクトにおける共通の価値観や思想を示す指針となるものがデザイン原則です。
デザイン原則はプロダクトを作成するために使う道具であるため、「プロダクトを新しく作ることになったから、そのためにまずはデザイン原則を作ろう」というのが自然な流れと言えます。
プロダクト構想時の理想像を具体的に世界観として起こし、道標となるものがデザイン原則なので、最初にきちんと作っておけばモノ作りの過程でもブレずに進んでいくことができます。
途中からデザイン原則を作る意義
ただ、弊デザインチームが立ち上がった時には、プロダクトがすでにサービスとして完成していました。これは、プロダクト開発が始まってある程度の年数が経った段階でリソースに余裕ができUIUX整備の需要が高まったという背景があるためなのですが、これまでいわば無法地帯で機能開発が進んでいたため、根本となるプロダクトの理想像から現状どれくらいブレていないか確認する必要がありました。
…無法地帯というのは言い過ぎました!笑
ある程度のルールはあったものの、きちんと精査・管理されていなかったというのが正しいです。最初のエンジニアが作成したボタンのサイズやカラーを後続がそのまま受け継いでいるという形でした。少数精鋭ゆえUIUX検討にまで手をまわすリソースがないというのは、実は“あるある”な状況かもしれません。
プロダクト作成に回す手を止めてまでデザインのルールを1から検討することは、開発スピードの速いチームであるほど一見時間の無駄のように感じるでしょうか。
しかし、先ほどもお伝えしたように、デザイン原則はただのルールブックではなくプロダクトの思想を揺らがせないための指針なのですから、大きなプロダクトであればあるほど必要不可欠になっていくと言えます。
いつからでも遅くない!
じゃあいつ作るか?
\◯◯◯◯◯!/
ありがとうございます。その通りですね!
というわけで、私たちはプロダクトがある程度成熟した段階からデザイン原則作りを始めました。
デザイン原則、作っていこう
1. 仮原則を立てる
弊プロダクト「Liny」は、LINE公式アカウントでのメッセージ配信・顧客管理・アカウント運用をサポートするサービスです。
まず、仮で4つの原則を立てました。
ブランドとプロダクトの理想に沿う価値観をチーム内で洗い出し、言語化してみた段階です。
この時大事にしたいと考えていた理想のプロダクト像は、それぞれ
- たくさんの顧客に対し、ミスなく配信できる
- 煩雑な機能に対し、ハードルを感じさせない
- 機能を跨いだ複雑な使い方をする際にも迷わずに使いこなせる
- コミュニケーションツールであるため、一方通行ではなく双方向でのやりとりをつつがなく行える
といったものでした。
2. 仮原則を具体的な意見で叩く
続いて、プロダクトの理想像がズレていないかを確認するため、チーム外の様々な部署の社員にこの仮原則を叩いてもらう時間を設けました。
この時、先ほど挙げた記事(ワイガヤ方式を活用してデザイン原則を考える)で紹介しているワイガヤという方法をとっています。
参加者にはこの仮原則を議論の軸にしつつ、自分の思うプロダクトの理想像とそこに足りていない現状の課題点について“ワイガヤ”してもらいました。
「今の開発方針」といった重さのものから、「この画面のこの色が違和感だ」といった細かくて具体的な不満、そして「もっと明るくて爽やかなデザインの方が使いたくなる」「他社のこの製品は安心感を覚える」というざっくりした意見など、様々な粒度の意見が集まりました。
3. 出た意見を分析
もらった意見を種類の近いものごとに集めてみると、興味深い結果になりました。
- あんしんして使える
- なめらかな / まよわない操作を追求しよう
この2つは、それぞれの必要性を根拠づけるような多くのエピソードが集まっていました。
製品の安全性や誠実性を求める顧客層が厚いことや、自分用にカスタマイズした使い方をするユーザーの多さ、使いづらさを感じる一番の問題点がなめらかな操作性に欠ける部分だった、など…
一方で、
- したしみやすい存在でいよう
- 友だちとのやり取りが主目的
この2つは、プロダクトの理想像と少しズレがあること分かりました。
「したしみやすい存在でいよう」は、「煩雑な機能に対し、ハードルを感じさせない」という価値観のもとに生まれた言葉でしたが、「近しい」「あたたかみのある」等の意味も含んでしまい、使い慣れたユーザーからすると重要な価値観ではないという違和感が大きく出ました。ゆるキャラのような心の距離の近さを誰にでも感じてもらいたいわけではなく、あくまでも使い始めたばかりのユーザーに機能を理解しやすいと感じてもらうことが目的だったからです。
「友だちとのやり取りが主目的」は、ワイガヤ参加者の指摘により、効率化をはかる一面も持つプロダクトの指針として掲げるには矛盾が生じていたと分かった上、他3つの原則と同じ粒度ではないと判断しました。
4. 軌道修正
ここでチームに持ち帰り、軌道修正を図ります。
「なめらかな / まよわない」と「したしみやすい(ハードルを下げる)」は、総じてユーザーの操作を助け、寄り添う存在でいるという言葉に表現されるのではないか?という意見が出ました。
しかし、枠が大きすぎてぼやけすぎるという問題に加え、「ユーザーにこう感じて欲しい」「こういう態度で開発にあたるべき」と原則の目線が違うという指摘が出ました。
また、「したしみやすい存在でいよう」を考えた際に出たユーザーの習熟度別で体験して欲しい価値観が違うという問題を解決するため、今度はこの「よりそう存在でいよう」を、対象ユーザーを分けて具体的にし、「あんしんして使える」と同じ目線にすることになりました。
5. 何度も練って、確定させる
ユーザー目線での価値観に揃え、最終的にまとまった案がこちらです。
「たくさんの顧客に対し、ミスなく配信できる」という、全ユーザーに体験して欲しい価値は、あんしんして使えるという原則に。
「煩雑な機能に対し、ハードルを感じさせない」という、初心者に体験して欲しい価値は、てがかりを見つけられるという原則に。
「機能を跨いだ複雑な使い方をする際にも迷わずに使いこなせる」という、ハードユーザーに体験して欲しい価値は、なめらかに使えるという原則に。
当初の理想像をブラッシュアップし、分かりやすい言葉にまとめることができつつあります。
作成できてからが大事
ここまで弊チームの作業過程を紹介させていただきました。
デザイン原則は作りっぱなしにするのではなく、開発ルートに載せて全体での共通思想にしないと意味がありません。
この原則をもとに、バリデーションやボタン規則など細かいルール作りをして全体で共有できて初めて意味のある指針になり得ます。
プロダクトに対してすぐに目に見える変化が生まれる作業ではない分、道のりは険しいですが、デザイン原則のあるプロダクトとそうでないプロダクトでは数年後の姿が変わってくると言えるのではないでしょうか。
弊チームもまだ細かい事例パターンの作成段階にありますが、まとまり次第また過程をシェアしていけたらと思います!
Discussion