プロジェクトに対してUIデザイナーとしてのアプローチ
「プロダクトUIデザイナーも上流工程から入っていきましょ」と言う声はよく耳にしますが、小さく流動的な組織の場合、再現性ある確立されたフローもないのにどうやって...と悩むデザイナーも多いと思います。私も進行形でその悩みを抱えています。
このnoteでは、一つのプロジェクトを例に挙げ、デザイナー目線でのアプローチやプロセスへの介入についてメモ代わりに記しています。
はじめに
プロセスへの「介入」と言っている理由
半年前までデザイナーとエンジニアがそれぞれ別部署にいた
開発部内で30名ほどのエンジニアに対してデザイナーは2名
これらが現在の組織の状況であり、結果としてデザイナーの関わり方というものが未だ開発フローの中で確立できていません。
これは、ぼーっとしていると指示された画面をXDで作るだけと言う関わり方になってしまうと言う危険性があります。
開発フローの見直しも必要であり改修にも努めていますが、フローの見直しを待っている間にも課題は出てきますし、プロジェクトは動きますので、エンジニア中心で運用されている開発フローの中には、デザイナー自ら積極的に介入していくことが必要だと考えたので、介入という言葉を使いました。
noteを読むにあたって：プロジェクトの背景
プロジェクトの背景を説明すると、とても長くなってしまいそう＆今回の記事の主旨とは異なるので99%ほど割愛します。
記事を読むにあたって知ってほしいのが、弊社のプロダクト（Carely健康管理クラウド）では、要配慮個人情報を多数扱っていると言うことです。
例えば健康診断結果やストレスチェックの回答は、絶対に「特定の人以外に」「個人と紐づいた状態で」「本人の許可なく」見られてはいけないと言った制約があります。この制約が正しく機能し、運用できる状態であることは必要不可欠です。
そのようなプロダクトなので、ユーザーアカウントごとにアクセスできるデータの制限（権限）があります。今回の例に挙げたプロジェクトは、その権限の作成にまつわるプロジェクトです。
フローとプロセスへの介入
プロジェクト発足前の話し合い
とある課題についてPMMとリードエンジニアとミーティング
※この段階ではデザイナーとしてアサインされたと言うよりは、ヒョイと声がかかったと言う方がニュアンスとして近い。PMMが紙に描きながら現状の起きている課題やあるべき姿を説明
◆デザイナーのアプローチ
理解できた部分で「こんなUIならできるんじゃないか」と言う２ページ分のイメージが浮かんできたので、とりあえずそこの説明ができるような資料を作ってみます、と言って自分でボールを持つ。
自分のアイデアを伝え共有
先の２人（PMM・リードエンジニア）との共通認識を持つために、自分が資料を用意してこれで合っていますか？という確認をしてPOへの提案を固めます。
画面遷移の例やUI、適切な文言を探す
SaaSでの類似サービス/Pinterest/Dribble/ITリテラシーが低い人も使うサービスなどを参考に
人事へのヒアリング：よく使ったり使いやすいと感じるサービスから馴染みのあるUIや文章を調べる
他社SaaSのヘルプページやお客様用のガイドを見る
ページでできることや見えることを箇条書きで羅列
ワイヤーフレームを作成するのに必要になる資料を用意
PMM・リードエンジニアに共有しフィードバックをもらいながら提案を固めていく
◆デザイナーのアプローチ
仕様は複雑な場合も、わからないままデザインしたらユーザーさんが使えるわけが絶対にない...という気持ちで質問・レビューは沢山しよう
PO承認＆基本設計
３人で共通認識を持てたので、次のステップとしてPOの承認を得ていきます。
画面に何をおくべきか、画面遷移図はどうあるかを考える（OOUIを意識）
設計中に気づいた要件定義への補足を追記していく
画面遷移図とプロトタイプをPMMとリードエンジニアに共有
細かいUIの話に焦点が当たらないようにラフに作っていく
この時にヒントや参考にしているUIのインタラクションも見せる（自分で作成したものではなく、参考にしたサービスの画面のURLで見せる）
POにプロジェクトとしての発足承認を得る
◆デザイナーのアプローチ
慣れや感覚で作成していると思われるデザインにも、裏付ける理由があって手が動いているはずです。デザインの説明をうまく言語化できない時はアイスリーデザインさんの記事がとても役に立ちます。
詳細設計
画面遷移図とUIカンプを見比べ改修していきながらUIカンプを制作する
既存の画面やコンポーネントとの整合性を意識して制作
他のデザイナーに、既に似たようなデザインのコンポーネントや作成中のPJがないかを聞く
プロトタイプを用意し、初見の人からレビューを受けブラッシュアップ
このPJにまだ関わっていないデザイナー/QAEに
実際のユーザーに近い社内の人事や保健師に
有志のエンジニア（PjMやPdMに興味がある）に
実装担当のエンジニアにも見せ、難易度や工数についても懸念がないか相談
◆デザイナーのアプローチ
とにかく質問やフィードバックをもらう。質問に対して答えられるか。また、理論や理屈があって作成したデザインであっても、複数の人から同じ質問があれば、そこは「わかりにくい」ところである可能性が高いです。
詳細設計と併行して進めること
要配慮個人情報など扱うため法務にもチェック依頼
CSに説明し、お知らせ案内についてのデザインの相談をされる場合もあるので、作成する
実装
担当のエンジニアと細かいインタラクションやデザインシステムとの絡みを相談しつつ実装してもらう
◆デザイナーのアプローチ
冒頭で述べたようにエンジニア中心の組織でデザイナーが少ない＆元々部署が分かれていました。エンジニアはデザインでも文言でもエンジニア同士で相談しがちです。中には「デザイナー忙しそうだから…」と遠慮してしまい、疑問を抱えながらも手戻りが発生しないように進めてしまうエンジニアもいるかもしれません。
自分から聞きにいかないとそういった困りごとに気づけません。
また、開発コストや保守の複雑性などはデザイナーでは分かりませんから、そういった問題がありそうな場合は早めにキャッチできれば、別のアイデアが提案できないか考えることもできます。
大事にしていること
大事だと思っているのは「ひとりでデザインしない」「ユーザーの立場になってみて」の２つです。
ひとりでデザインしない
プロジェクト発足前から設計段階でも実装段階でも、たくさんの人からのレビューや質問を貰いにいきます。手戻りは必ず発生します。その手戻りを少なくするためには早い段階から少しずつデザインのフィードバックをもらい、みんなでデザインしていきましょう。
ユーザーの立場になってみて
ユーザーはどういった使い方をするだろうか。実際のユースケースを考える。受け取った要望やフィードバックに対しても「それってユーザーにとってはどうなんだろう？」と言うことを気に留めておきます。そもそものユーザーの課題は何か？に常に立ち返ります。
まとめ
あくまで一人のデザイナーが介入する方法はこんな感じだったと言う一例です。恥ずかしい話ですが、再現性のある開発フローの確立はできておらず、これからです。
うちはこう言うプロセスで取り組んでいるよ！と言う話も聞きたく、採用目的以外でもカジュアルにお話できると嬉しいので、デザイナーのお話会などにも呼んでいただけると嬉しいです。お気軽にtwitter(X)でのDMでも構いません。
お察しの良い方はこの記事を読んで、人足りているのか？と感じているかと思います。おっしゃる通りでございまして、一緒に開発部で働ける仲間を募集しております。