ユーザーストーリーを使って、デザインの意図をしっかり伝えよう！
伝え方編：プロダクトデザイナーの視点
こんにちは、VMware Tanzu Labs でプロダクトデザイナーをしているErikaです。
今回はデザイナーの目線から、チーム内でストーリーを使ってどんなコミュニケーションをとっているか？の伝え方編を紹介します🙋♀️
ユーザーストーリーをご存じの方の中には、エンジニアのためのもの、エンジニアが活用するもの、というイメージを持っている方もいるかもしれません。でもデザイナーの私も毎日何かしらの形でストーリーと関わっています！
この記事はTanzu Labsのプロダクトマネージャー、デザイナー、エンジニアそれぞれの視点からユーザーストーリーについてまとめた3部作の一部です。
実装前の認識合わせ
私たちは、週に1回IPM（イテレーションプランニングミーティング）という会議を行います。この会議では、ストーリー１つ１つについて、チームで下記のことを行います。
- なにをどんな目的で開発するかの確認
- 実装内容の認識を合わせる
- ストーリーにポイントをつける
デザイナーとして、この3つの中でも特にメリットを感じるのは「実装内容の認識合わせ」をする過程です。これが実装着手前にあることで、「イメージと違う😭」という悲しい理由による修正の回数を抑えることができます。私個人の経験ですが、Tanzu Labs以前の開発現場では、何度もデザイン修正を依頼しなければならず、時間に追われてみんなピリピリ、、ということがありました。ストーリーを使った開発に慣れてからは、そんなストレスが減ったな〜と思います。
具体的にイメージができるように、とあるアプリにログイン機能を実装する、という想定で下記のような画面を作ってみました。よくあるフローですが、デザイナーの想定や意図はどのくらい伝わるでしょうか？
もし余裕があればここで少し時間をとって、どんな動きでどこまで実装するかを想像してみてください💭
ストーリーを作成する
デザインとインタラクションのイメージができたら、ユーザーストーリーを書き、デザインの要素とインタラクションの流れを言語化します。ストーリーの区切り方はチームによって変わるのですが、今回は、①静的にスタイルを当てるストーリーと②アニメーションなどの動きを作るストーリーの２つに分けました。ぜひ、先ほど想像した動きと比べてどうだったか？も振り返りながら読んでみてください！
※機能はスタイル無しで既に実装されている想定です。また、下記はPivotal Trackerというツール上で作成したストーリーのスクリーンショットです。
ストーリーには、「何故そのデザインが必要なのか？」のWhyと「何が満たされたら受け入れられるのか？」のAcceptance Criteriaが含まれます。
Acceptance Criteriaでは受け入れテストをするときの確認範囲を定義し、実際の色味やデザインはFigmaで見つけられるようにコンポート名を示します。
また、②のストーリーは「ニュッ」とか「シュッ」とか、とてもざっくりした書き方になっています。これでいいの!?と思うかもしれませんが、足りない部分はIPMで会話をすることで補うので、「ここの部分をアニメーションで動かして欲しい!!」という意図が伝わればOKなのです。
IPMで相談をする
IPMでは、私が画面共有をしてまずはストーリーを読み上げます。その時にFigmaのデザインやプロトタイプがあれば、それも一緒に共有します。ここは、デザイン意図をしっかり伝えるチャンスです✊
例えばウェブアプリだったら上記のようなデザインストーリーに対して、、
テキストインプットのフォーカスはブラウザのデフォルトもあるけど、色の指定は大事ですか？
といったコメントが出たりします。インプットボックスの色指定であればサクッとやりましょう！という結論になることが多いですが、モノによってはストーリーの指定範囲から外すことになるケースもあります。それは、その時その時に何を優先するべきか？によって決められます。例えば、ブランディングを整えることが大切なタイミングであればデザインに時間をかけますし、早くリリースすることが必要な場合であれば一旦はブラウザデでフォルトのデザインを使うことで素早く終わらせる、というケースもあります。
この判断をするとき、ストーリーの中に「実現すること」に加えて「なぜそれが必要なのか(why)」が含まれていることが大切です。それがあるからこそ、目的を達成するための手段については柔軟になることができます。気になることがあれば、その都度相談しながら前に進みます。
それ以外にも、デザイン中に考慮できている質問やコメントが出ることもあれば、言われて初めて気がつくものもあります。必要があればその場で一緒にストーリーを修正したり、IPMの後にデザインを直したり追加することもあります。
このすり合わせがあることで、実装を開始してから「なんだ〜、本当はもっと簡単でよかったんだ！」や「いや、もっとしっかり作って欲しかったんだけど・・・」という悲しいすれ違いを予防することができます！
（でもこれって大変・・・じゃない？）
こんなプロセスをクライアントのデザイナーに初めて紹介すると「結構な手間ですね。。」といった反応をもらうこともあります。
ストーリーを使っていない状態からストーリーを書く状態に変化なると、余計なステップが増えたように感じますよね、、！確かにストーリーを書くことには、慣れも必要ですし難しいなと思うときもあります。
でも私は、ストーリーを書くことにはデザインのスキルアップにも繋がると思っています。ストーリーを書くことは、ユーザー目線でインタラクションの流れを考えて言語化する訓練になるからです。私は、グラフィックデザイン畑の出身なのですが、ストーリーを書くことを通じてユーザーの体験や画面の変化を、以前よりも時間軸をもって具体的に考えられるようになったと感じています。
ということで、最初はとっつきにくくても、きっとユーザージャーニー作成やインタラクションデザインの作成もレベルアップするはずです🌈
以上、ユーザーストーリーの伝え方編でした！
今回紹介した流れを全て取り入れるのは難しいかもしれませんが、部分的にでも参考になる部分があれば嬉しいです🙂
