この記事は食べログアドベントカレンダー2021の7日目の記事です

12/7 担当、デザイナーの @tanuki___tk です。
2021年はアプリのUI設計を行う機会が多く、日々スマホ画面と睨めっこしています。
その中で発見した「実装後の画面確認フローについての気づき」を記事にします。今回は事前に要件やUIデザインを詰めてから開発を行う案件を前提に話を進めていきます。

実装後の画面確認

主な案件はざっくり上記のフローで進行しており、
「実装後の画面確認」はWeb・アプリ問わずほとんどの案件で発生する工程です。
エンジニア実装対応後、

　・要件、仕様に沿っているか？
　・デザインは指示通りか？
　・機能バグやデザインが崩れている箇所はないか？

などの確認を行い、バグがあればエンジニアに連携し修正方針を相談して対応して頂きます。
修正対応後....バグもない、要件通り、デザイン通り！
「デザイナーの画面確認はOKです！」と言いたいところですが...

ちょっとまって！
バグがなくて、要件通り.....それだけでいいの？

実装後の画面確認は、初めて「使う」側に回り検証できる絶好のタイミングです！

その実装した画面は.....

　・本当に何の「違和感」もなかったのでしょうか？
　・目的にあった使い心地になっているのでしょうか？

ここで 「ん？」 と何か少しでも引っかかる箇所があれば、それはリリース後、ユーザーが使うタイミングでも同じように感じる可能性があります。

自分自身、これまで意識していなくとも挙動に関する確認（アニメーションの速度等）はしていました。
しかし、複雑な仕様や細かい画面遷移などが発生する案件の場合、全ての画面を確認するだけでも時間がかかります。またバグが多い場合は、その発見や修正することだけに意識が集中してしまい「違和感」に気がつきにくくなる経験がありました。
なので改めて、意識して確認することが大切だと痛感しました。

実際にその機能や画面を「使う」「体験する」という意識

企画、エンジニア、デザイナー。皆、事前に数値の調査、シナリオ作成、プロトの検証等沢山のことを考えては協議し、要件やデザインを決めています。
私自身もあらゆるケースを想定して淀みなく目的を達成できるようなUIを目指して挙動の検討などしています。

しかし、それはあくまで机上の空論でシナリオやデザインプロトタイプによる検証だけでは、実際に使用した感覚までを賄えるものではありません。（実際に開発しながら要件を詰めるケースは除きます。）特に、アニメーションの速度やタップ領域などは数値だけで測れるものではなく、使った感覚がとても大切です。

なので、画面確認の工程では、

　①仕様、要件にあってるか？
　②デザイン崩れてないか？
　
③違和感を抱く箇所はないか？目的にあった使い心地になっているのか？

①②だけでなく ③に 意識を向けることでもう一段階プロダクトを研磨できると考えました。

事前に考えた要件やデザインを信じすぎていると....
実装画面確認する → 要件や仕様通り！＝ これが今できる最高　
という思考に陥り、その先へ進める道を自ら閉ざしてしまうことになりかねません。③の視点を持つことは、今一度自分達が考えた要件やデザインについて「本当にベストなのか」「もっとよくできないか」俯瞰して考える機会になります。

実際に見つけた「ん？」な事例

画面確認時に発見した 「ん？」＝違和感 の事例を紹介します。
※案件の中で自分自身や関係者からの声を一部抜粋し、わかりやすく改変しています。

●Aさんの証言
「自然と画像をタップしてしまったんですが、押しても何も反応しなかったんです。」

遷移すると感じて画像をタップしたけど、実際はボタンにしか遷移設定がないので何も反応がない。
「●●ができそうと感じたのに、できない」＝「思ってたんと違う」というケースは画像やボタンに限らずよくあります。事例の場合は、ボタンを目立たせるか、画像にも遷移設定をすることで「ん？」が解消できます。

●Bさんの証言
「なんか、圧が強くないですか？」

一度表示されたメッセージが、再度違う画面でも同じ内容表示されて少し鬱陶しく感じる。
表示される回数で煩わしさを感じるケースです。この事例の場合は、聞く回数を減らすかBの聞き方を変えることで「ん？」を解消できます。
何を聞かれているか瞬時に理解できなかったり、読み飛ばされてしまう場合もあるので言葉の選び方や長さも重要です。

自然とやってしまう行動や、なんとなく感じた鬱陶しさは、言葉にできない事も多く原因がわからないという場合もあります。違和感を見つけた後は「その違和感がどうして起きているのか」を考え掘り下げていき解決方法を探っていきます。

「ん？」を見つけるためには

違和感を見つけるために、画面確認時には以下を実行するようになりました。

　・まず確認観点に「使い心地」という項目を入れる
　・画面単体ではなく、その前後の行動含めてユーザーと同じ行動をして確認する
　・少しでも違和感があれば見逃さない

特に、3番目の「違和感を見逃さない」ことが一番大切だと考えています。
違和感はあっても使えてしまうので、意識していないと違和感を抱いていること自体に気がつかない可能性があるからです。
また、ユーザーと同じような行動をとることは、バグ対応時の優先順位付けにも使えます。
ユーザーの行動が複数パターン考えられる場合はそれも踏まえて確認しています。

研磨の時間を取るためにできること

ブラッシュアップできるポイントを見つけるだけでも価値がありますが、せっかくならリリースする前に直したい。でもそれには時間が必要です。

そもそも要件・デザインと実装が異なる場合、その対応で工数がとられリリース日までに時間が無くなるため、まずは事前に関係者で認識合わせを行い齟齬や疑問等を無くした上で開発する等、スムーズに開発を進めるためのコミュニケーションが時間を作るためには大切だと考えています。

　＜理想の流れ＞
　1.仕様やデザインについて関係者で認識の齟齬を無くす
　2.画面確認ではバグだけでなく、「使い心地」に意識を向けて「違和感」を見つける
　3.バグの修正とともに、ブラッシュアップできそうな箇所を調整する
　4.事前に決まっていた要件やデザインよりも、良い状態 でリリースできる

「ん？」＝違和感 　は積み重なることで、使いづらさに繋がります。
小石が落ちていても歩けますが、無ければもっと歩きやすい。違和感をなくしていくことは、その小石を一つずつ拾って、より歩きやすい道を作る様なものと考えています。

それはどんな立場であっても

「実装後の画面確認」する人達全員がユーザーと近い目線で「使う」ことが可能だと考えています。
使用する端末の大きさや機種、利き手や姿勢、視力、アプリの使用頻度...など環境や使う人によって「使った感覚」は異なるため、「目的にあった使い心地になっているのか？違和感を抱く箇所はないか？」の観点でもし何か発見があればどんな小さいことでも教えていただけると、とても助かります。

検討時に何度もデザインを見たデザイナーより、別職種の方のがよりユーザーの視点に近く「違和感」を発見できる可能性が高いと考えています。実際、企画職の方から使い心地の違和感について意見を頂くことも多く改善のヒントになっています。
※デザイナーの場合は一度頭を打ってデザインしたことを忘れ、初めて触った人の気持ちになり検証することをオススメします。

さいごに

ユーザーと同じような行動をとって検証することや、違和感を見逃さない事...当たり前だと感じる人もいるかもしれません。しかし、バグの発見等に意識が集中してしまい「使い心地」の検証が疎かになってしまう経験があったので自戒のためにも記事にしたかった次第です。

UIに関して忌憚のない意見をくれる企画担当者や、実装上厳しい箇所も目的にあった代替案を意見してくれるエンジニアにいつも助けられています。

リリースしてから改善を繰り返すことも大切だと思いますが、それ以前にまずはリリース前に関係者全員で協力してより良い状態を作っていきたいです。

明日（12/8）は @otoyodaさんの「SEOの話」です。お楽しみに！