5月は新規プロダクト開発でsketchを使ってワイヤー作成してみたり、ユーザーインタビューの準備をしたり、新しい仕事に取り組んだ月でした。
というか、入社してから常に新しい事に挑戦しないといけない環境でずっとワタワタしてます。大変だけど楽しい。
5月にやったこと
1. 社内ツール運用
新規開発に時間を使うため、社内ツールに関してはエラー対応が中心で新バージョンのリリース回数は減りました。
だからこそ、ユーザーから要望を受けた時は早めに対応する、リリース時にはリリースノートを毎回書いてslackで共有することで「まだ進化してますよ!」ということを社内にアピールしていこうと思います。
リリースされて約3ヶ月。運用もきちんとされ、データも集まってきました。新規プロダクトではこの社内ツールから引きたいデータもあるので、社内ツール含め既存プロダクトの運用が正常に行われることは今後マストです。
まだ使いづらい点もあるかもしれませんが、このツールがあることが社内でも当たり前になってきたことがとても嬉しい!!
2. toBの新プロダクト開発
4月から始まった新規プロダクト開発。
先月はペルソナ作成や仮説立てで終わり、GWはワイヤーフレーム作成の続きから始まりました。
sketchおもしろい
ワイヤフレーム作成のために会社でsketchのアカウントを貰いました(やったー!)
デザイナーさんに教えてもらいつつ雰囲気で触っている部分も多いのですが、シンボルを作るのが楽しくて、どんどんシンボル化しながらヘッダーなど作ってみました。
シンボルの中にシンボルを入れ子に出来るので、一部だけ変えてAパターン、Bパターンのような差分も表現できるのが特に便利。
abstractを使えばgitみたいに状態管理が出来るのも初めて知りました。
使えるツール増えるの嬉しい〜
どの情報を見せるのか?どう見せるのか?
IA(情報設計)の本も読んでみたのですが、実際にやってみると本当に難しい...
GW前にペルソナ、ジャーニーマップを作成して、ユーザーの課題と解決策(課題を解決できる情報)の仮説を立てていたので、課題を解決するための情報を画面に置いていくことにしました。
この段階でさっそく「情報をどう区切るか?」という問題が出てきます。
情報の種類、使われる時間軸などいくつかの基準で考えましたが、今回は半年以上の長期間に渡って使用することを前提としたプロダクトであること、時期によって使われる情報をハッキリと分けられないことから、「情報の種類」で分けてみました。
ただ、その分け方だと1画面に情報が多めになるので、1画面中では上→下の時間軸で情報を並べています。
時々デザイナーさんにチェックしてもらい、指摘もバンバン貰います。
近接、整列、反復、アクセントの4原則は意識して作ってたのですが、情報のまとまりの弱さ、情報と導線になるボタンの繋がりの弱さを特に指摘されました。
アドバイスに従って少しボタンの位置を変えたり、カードを使うだけで情報の意味そのものが変わるのが分かり｢デザイナーすごっ!｣と感じました。
同じデータ(文字、数字)でも、どれだけ伝えたい情報を正確に伝え、かつユーザーに期待する行動を促せるかはワイヤーフレームの段階で大きく変わってきます。
また、ある程度ワイヤーが形になった時点で、他のステークホルダー(営業チーム)に意見を求めて、情報の追加や絞り込みを行いました。
今回のプロダクトはBtoBなので顧客と関わるセールスの意見は外せません。仮説の時点で普段のコミュニケーションの内容に基づいて必要な情報を絞り込めたのはとても良かったです。
会社にいないことも多いセールスチームとの情報共有や巻き込み方は難しいと感じますが、このタイミングで何度も関わってもらえたのは、プロダクトの質の向上とチームメンバーとしての意識を強めてもらう両方の点で意味があったと思う。
ユーザーインタビュー準備
今回のプロダクトはBtoBの部分で使われるため、ここでもセールスチームの協力を得てユーザーインタビューの機会をいただきました。
社内でもユーザーインタビューは初めてになるので本を読んだりデザイナーからアドバイスを貰いながら質問を考えています。
また、インタビューの目的は課題と解決策の仮説検証なので、質問内容を考えつつ、その回答からどのように仮説を検証すべきかもこの段階で一緒に決めました。
メモはこんな感じ
仮説
ユーザーは○○事業において◯◯という課題を感じている
質問内容
今年度の◯◯事業の中で、困ったり面倒だと感じた体験を教えて下さい。
その際、誰がどのような手順で対応していますか？
など
仮説検証の方法
ユーザーが面倒に感じた体験の中に◯◯が含まれるか?
こんな感じで、検証したい仮説1つずつに対して質問と検証方法をセットにしたメモを作っています。
一般的なセールストークとは異なり、
- 誘導になる発言をしない(「〜だと思いませんか?」など)
- オープンクエスチョンを増やしてユーザーの発言を増やす
- ユーザーの意見、予想(未来)よりも、事実と体験した感情(過去)を重視する
など気を付けるポイントもあるので、アポや当日のアイスブレイクはセールス担当の方にお願いしますが、質問は主に私が行います。
1件だけインタビューに行ってきたのですが、思うことが色々あったので、この辺りは来月またしっかり書きたい。
Nuxt.js
今回のプロダクトはNuxt.jsで作る予定なので、時間を見つけては触っています。
Fluxの考え方は掴めたのですが、まだサンプルになるようなアプリしか作っていないのでmiddlewareも含めたもう少し大きなものを作ってみます。
また、参考用に社内でもう一つNuxtで進んでいるプロダクトがあるので少しコードも読んでみました。レベル差が大きくてまだ全然把握できていないのですが、TypeScriptの書き方や設定周りは今回ぶつかるだろう部分なので参考になるプロダクトがあるのはありがたい...。
前回の開発はベース部分はすべて別の人が作っていたので何も考えずにコードを書き始められましたが、今回は設定周りや細かい部分(lintどうしようとか)を考えないといけないので、そこもちょっと不安。
まとめ
先月に引き続き、ユーザーインタビューなど新しいタイプの仕事がどんどん増えています。
挑戦できるチャンスだ!と頭ではポジティブに捉えつつも、ストレスや不安は溜まっていくので、そこの発散を自分でコントロールする必要がありそうです。特に最近は仕事で感情的になってしまうこともあって反省。
また、今回は様々なメンバーが関わるプロダクトだからこそ、常にビジネス面・開発面など広い視点から見て、調整をしていかないといけません。
例えば初回のユーザーインタビューの後、同席していたセールス担当に「インタビューとはいえ、相手の仕事の内容など基本的な質問をされると、相手に『それくらい社内共有しておけ』と思われそうで不安」だと言われる事がありました。
ユーザーインタビューだから相手の言葉で伝えてもらうことに意味がある、というのはあくまで開発側の意見で、顧客の元に通って信頼関係を築いてきたセールス側の立場や意見もとても大切です。
事前に「基本的な質問をするかもしれませんが、〇〇様のお言葉でご回答をいただくことで分かる点もあるのでご了承ください」と伝えるだけで、相手や同席するセールスの気持ちも大きく変わっただろうな、と反省した点でした。
調整を行いつつ仕事を進めるには、相手の物事の考え方や判断基準を知る必要があり、そのためには他チームの仕事内容も更に知っていく必要がありそうです。
マネジメントってめちゃめちゃ難しい!!