見出し画像

企業のミッションとバリューからデザインフィロソフィーを作る

🎄 SaaS Designer Advent Calendar 2023 8日目の記事です 🎄

こんにちは、今日はShippioのプロダクトデザイナーとして、私たちShippioのプロダクトデザイナーのDesign Philosophyをまとめた話を書きます。
Shippioには企業としてミッションとAnchors(いわゆるバリューに該当するもの)があるのですが、これらを元に、プロダクトデザイナーの行動指針と、作るべきものの指針を考えました。

ちなみに現在Shippioにはプロダクト(Webアプリケーション)のデザイナーしかいないので、ブランディング・広告等コミュニケーションデザインの領域は特に考慮していません。


ShippioのDesign Philosophyとは

Design Philosophyは、どんなものを作るかを表す「What to Design」と、どのように作るかを示す「How to Design」の2つから成り立っています。
Shippioの企業のミッションとして「理想の物流体験を社会に実装する」があり、そのための行動指針として5つのAnchorsがあるのですが、それらとDesign Philosophyの関係は以下のようになっています。

企業のミッションとAncors(バリュー)と、Design Philosophyの関係

「Moonshot」は目標の高さを表し、他の4つはアプローチを示しているので、Moonshotを具体化したものとしてWhat to Designの項目があり、その他4つをデザイナー的行動に分解したものとしてHow to Designがあります。

ちなみにAnchorsは最近見直されました。興味のある方はこちらの記事をご覧ください。


What to Design

What to Designは、私たちの作るものがどんなものであるべきかをまとめたものです。いろいろ出していたら数が多く、いろいろな粒度のものがあったので、「原則」「ベストプラクティス」に分類しています。

What to Designの構造

数が多くて一見複雑に見えるのですが、自分たちがどんなことができ得るか、どんなことを考慮した方がいいか、考えたことを残しておく必要があると思ったので、あまり数を減らすようなことはしていません。
Design Philosophyは他のデザイン系のドキュメントと合わせて参照したいと思ったので、Figmaでまとめていて、以下のようになっています。

What to Designについてまとめたページの一部


How to Design

How to Designはデザイナーとしての行動指針をまとめたもので、Anchorsの「Moonshot」以外の4つをデザイナーが行うべき活動に分解したものです。こちらも挙げていったらそれなりの数になったので、いくつかのカテゴリを作っています。その中にさらに具体的な行動のリストがあります。

How to Designの構造

こちらも細々といろいろ書いてあるのですが、あまり数を減らすことはせずに考えたことを残しています。

How to Deisngをまとめたページの一部


Design Philosophyができるまで

Design Philosophyは、プロダクトデザイナー全員でアイデア出しやディスカッションをしてまとめました。1時間のミーティングをほぼ隔週で8回行い、約2ヶ月程度かかりました。
Design Philosophyを作ろうと考えたきっかけは、作るものが増えていき、人を増やそうとしていく中で、自分たちがどんなものを目指したいかがまとまっておらず、各デザイナーのなんとなくのイメージに任されていたからです。これから事業や組織をスケールさせるために、チームとしての考えを持っておく必要があると思いました。

また、どんなものをチームの考えとしてまとめておくべきか考え、いろいろな企業のデザイン原則を調べました。その結果、企業によって、マインドセットやアプローチなどHowをデザイン原則としている場合と、どのようなものを作るかというWhatを定めている場合があることがわかりました。
自分たちはどちらもあまり議論したことがなかったので、今はどちらも必要だと考え、両方について検討していくことにしました。

流れ

おおまかに以下の2段階を経ています。

  • What to Design と How to Design のアイデア出し、分類

  • 疑問点や詳細に考えた方が良さそうな点についてディスカッション

アイデア出し

What と How の両方について定めていこうと決めた後は、まずプロダクトデザイナー全員でそれぞれについて当てはまると思うもの、やっていきたいと思うものについて挙げていきました。
Miroを使って、WhatとHowぞれぞれについて、15~20分程度の時間でひたすら書いていくというのをやりました。What to Designについては、「仕事のやり方が変わる」といったとても抽象的なものから「注釈を少なくする」のような具体的なものもいろいろ出ましたが、この時点では特に何も決めずに、思いつくものを挙げました。

How to Designについては、Anchors の標語をデザイナーの活動として具体化するとどうなるかを書いていきました。例えば、「Do-Mannnaka:正々堂々・真正面からIndustrial Transformationを実現しよう。面倒でも・険しくても、正しく誇りに思える道を進もう。業界の積重ねにリスペクトを持ちながら、Moonshotの実現にこだわろう。」をデザイナーとしての行動に翻訳するとどうなるか?といったことです。こちらは、一つの標語について複数人がそれぞれの解釈で書くので、一見相反するような内容が出ることもありましたが、この時点では気にせずに進めました。

What to Designの分類

4つのAnchorsを元にした How to Design の方は、最初から分類されているので問題ありませんでしたが、「Moonshot」を元にしたWhatの方はいろいろなものが含まれていたので整理が必要でした。
まず、おおまかにアイデアをいくつかのカテゴリに分けました。ここで、

  • ユーザーが本来やりたい仕事に集中できる

  • すぐに見つけられる

  • 試行錯誤できる

  • 安心して使える

  • 様々な人が様々な状況で使える

といった抽象的なキーワードを決めました。

また、What to Design の中にはとても具体的なアイデアも含まれていました。例えば、「つねにパーマネントリンクがある」はユーザーにとって自由な使い方をするために大切です。でもケースバイケースでもあり、かなり仕様的な話なので、こういったものは Best Practiceとして区別しました。「絶対にそうしなければいけない」というよりは、「これをすると、結果的にこういう原則を達成しやすいのでおすすめ」的な位置付けです。

What to Designについて議論した時のMiro

疑問点についてディスカッション

一通り挙げた後、全員で書かれたものを見返して、「よくわからない」「曖昧なのでもう少し詳細にしたい」といった箇所に付箋をつけていきました。

例えば、What to Designでは「安心して使える」というキーワードがありましたが、「そもそも安心できないってどういう状況?」といった疑問が挙がり、詳細に考えていきました。

「安心して使えないとは」について色々書き出したMiro

How to Designについては、「One Team」というAnchorに対して「だれもがデザイナー」という案があり、「どういう意味…?」というコメントがつきましたが、

  • ソリューションの中で、デザイナーは情報設計やUIを担当しているが、セールスやCSやオペレーションチームも課題に対しての構造変容はみんなやってる

  • いろんな部分でのデザインはみんなやっていて、それの集合体がone team

  • 他のロールがお互いに影響し合っている

というような意味であるという話があり、ユーザーに価値を届けているのは自分たちだけではないということを全員で合意することができました。

「だれもがデザイナー」の意味を書き出したMiro

こういった作業を経て、プロダクトデザインのDesign Philosophyがまとまりました。デザイナー同士でどんなことを考えているか、どんな価値観を持っているかがよく理解できたのも良かったと思います。


これから

Design Philosophyはまだ作られてから日が浅いので、そこまできちんと活用できていないのですが、以下のようなことを考えています。

  • ソリューションやスペックのレビューに利用する

  • やりたいと思いつつあまりできていないことを強化する

  • 新しいメンバーが来たら、考えてもらったり一緒に議論したりする

  • 見直す

特に、今後新しいメンバーが入ってきた時、Design Philosophyについて改めて一緒に議論するのはとても大切だと思っています。今回Design Philosophyをまとめる活動をしたことで、まとめられた結果そのものよりも、その過程の議論の方が大切だったと感じているからです。
やりたいと思いつつあまりできていないことを強化するという点についても、まず現在できていないことが可視化されたのがとてもよかったと思っています。例えば、

  • How to designとして「社内、チーム内、イニシャルリリースなど、できるだけ早い段階で検証する」を挙げているが、現在デザイン段階での検証があまりきちんとできていない

  • What to designとして「色々なユーザーが色々な状況で使える」を挙げているが、Keyboardでの操作もあまりできない

などです。
今回作ったDesign Philosophyを元に、プロダクトとプロセスの両方を良くしていければと思っています。


ところで、似たような領域の人と色々話してみたいな〜と思ってYoutrustでカジュアル面談を作ろうとしたら、会社側の事情がありできませんでした。
もしこの記事の内容や、Shippioなどについて聞いてみたいと思う方がいたら、TwitterXでDMをください…
https://twitter.com/singularity8888


この記事が気に入ったらサポートをしてみませんか?