けしからんUIを解消していく１～ユーザーの行動フローに合わない注文タブレット～
・本記事は団体や営利目的での発表ではなく、個人の意見です。
あくまで、世間全体の意見ではないことを念頭にお読みください。
・自分自身が「こうした方が良いよね」と主観的な意見を提示しています。「これが正解である」という提示ではありません。
・一部感情的な表現がありますが、特定の団体へ中傷目的で書いている記事ではありませんので、ご了承ください。
世の中にはけしからんUIが溢れている
あなたはPC、スマートフォンを触っているときに、このような経験はありませんか？
スマートフォンのリストビューをスワイプしていたら、意図せず広告へタップして遷移されてしまう
記事を読んでいくと急にポップアップが出る
今まで行ったデータ入力などの作業が、何かしらのエラーが出た場合、今までの作業データが消えてもう一度入力を要求される。
以上は使う側がイライラさせられる＝「けしからんUI」の、ほんの一部であります。
では、けしからんUIの特徴とは何でしょうか？
けしからんUIの特徴とは？
自分が今まで出くわした「けしからんUI」では以下のような特徴がありました。
・ユーザーの行動フローに合致しない、意図しない振る舞いをする
・情報が多すぎて、アクションが起こしづらい
・ユーザーに余計な負担をかけさせる
etc…
上記の特徴に対して「気にしないよ！」という方が多数だと思います。
が、少なくとも自分は「こうすればもっと良くなるよね！」と思うことが多々あるのです。
そこで、今回は
・けしからんUIの実例
・なぜ存在するのか？
・その対処法
という３つの点を通して「こうすればもっと良くなるよね！」という自分なりの考え方を提示していこうと思います！
今回は第１弾として「ユーザーの行動フローに合致しないUI」をテーマに書いていこうと思います。
ユーザーの行動フローに合致しない注文タブレット
自分が経験した例を挙げてみます。
とある、食べ放題を売りとしているお店へ行った時です。そのお店で店員さんの案内で席に着き、注文はタブレットで頼む方式だと説明を受けました。
そこで、自分は以下のような行動をとりました。
タブレットで「セットメニュー」=>「Aセット」を注文
Aセットは４つのメニューが出てくる。注文した４つのセットメニューのうち、３つは出てきたが残りの１つが出てこなかった。
残りの1つはデザートという事もあり、「最後にタブレットで注文するものかな？」と思い食べ始めた。
出された物を食べ終わり、最後のメニューを持ってこさせようとタブレットを見てみると、単品注文用のメニュー表しかない。
タブレットから注文しようと探そうとするが、それらしき項目がないので混乱する。
店員さんを呼んでどのように注文すればよいか聞くと、その人はユーザー（自分）が操作していたタブレットを取り、デザートの注文をした。
さて、ここまでのフローを見て、あなたはどのように思いましたか？
少なくとも自分は「なぜ、店員さんを呼ばなければならなかったのだろうか・・・？」「店員さんにとって、面倒な作業を起こしてしまったなぁ…」
「ユーザーの行動フローに合致しない注文タブレットだなぁ」
と思いました。
なぜ「ユーザーの行動フローに合致しない注文タブレット」が存在するのか？
考えられる原因としては以下との通りです。
・要件定義が甘かった、またはUIに反映されていない
・UIテスト不足
・パッケージの利用により柔軟な選択が作成できない
以上の原因にフォーカスを当てて解決方法を提示していきたいと思います。
前提として既存のアプリがあった、かつカスタマージャーニー等の顧客調査は完了していると仮定して、話を進めていきます。
要件定義が甘かった、またはUIに反映されていない
既存のUI画面の改修の前に、要件定義を進めるのが普通だと思います。
ですが、その部分に抜けがあったと考えました。
対処法：上記の枠の設計図に加えて、ペルソナの修正、ユーザーストーリーの見直し、ユースケースも作成できれば後々のUIテストの項目の漏れもなくなるだろうなと感じました。
また、システム開発はウォーターフォールで行うことが多いでしょう。
その場合、テスト漏れなどがあり手直しが発生=>炎上と恐れがあります。
それを防ぐために、「アジャイル式プロジェクトにおける反復的デザイン」という概念を取り入れてほしいと感じました。
プロトタイピングの反復作成などの手間もありますが
UIテストの漏れが発生して炎上という事を防ぎやすいです。
UIテストでのプロトタイピング作成は「Figma」推しです！
・高度なアニメーションの設定
・スライド、遷移等のUIテストがPC、スマホでできる
・Web上でのPJメンバーのやり取りが容易
UIテスト不足
もし、前提の要件定義ができたとしてもUIテストに漏れがあると、今回のケースのようなUXの悪化につながります。
対処法：テスト漏れをなくすためには、ユーザーが予想される操作を、あらかじめテスト項目として入れておきましょう。
上記で述べたユースケースを基にテスト項目を作成すれば漏れがなくなる可能性が高いと思います。
※OSSによる自動化テストができるならSeleniumなどを使用します。
Webブラウザならば、メソッドチェーンが書けるのでNightwatch.jsがおススメです！
DOMチェックやバックエンドAPIテストを含むなどシステム全体ならばJestが良いと思います。
また、運用開発のケースでもTDD（テスト駆動開発）を取り入れるのもよいかもしれません。（自分はTDDを経験してないのでここでは省きます…）
パッケージの利用により柔軟な選択が作成できない
個人的に高い確率でこれだろうというのが、上記のケースだと思います。今回の場合だと、POSレジシステムのパッケージを使用しているケースが多数であると思います。
パッケージシステムとは、あらかじめ枠組みのシステムをベンダーが作成して、それを多数の会社へ提供していくシステムの事です。パッケージシステムは、そのシステムで出来る枠組み内の機能で、会社や店舗ごとにカスタムできます。
今回の場合だと「肉」「魚」のような大きな枠組みや、その中のメニューを追加・削除・更新したりすることが行えます。
また、在庫管理、会計システム、売上管理などのバックエンドシステムの情報項目もフロントエンドへ連動できます。
１からシステムを作る場合と比べて大きくコストが下がります。
しかし、枠組み以上のことができないので、柔軟なUIが作成できません。
今回のパッケージの場合だと、フロント、バックエンド両方ともに密結合につながっているシステムが多いと考えられます。
POSレジシステムのHPを見てみますと、フロントとバックエンドシステムの一元化を売りとしているところが多いです。
なので、そのようなことが起こっているのだろう。
解決方法：パッケージをやめてフルスクラッチを行いましょう…と言いたいですが現実的ではないでしょう。
現状のPOSレジシステムのバックエンド（在庫、会計システム、タブレットへ表示するメニュー情報）情報を、JSON形式のWebAPIを提供できるようにシステム変更ができれば、フロントとのシステム関係が疎結合になり柔軟なUIが作成できると思いますが…どうなんでしょうか？
まとめ
今回は「ユーザーの行動フローに合致しない注文タブレット」について記事を書きました。いかがだったでしょうか。
個人的にはパッケージを導入するならばシステム設計の自由が減り、UI設計がしにくいアプリになりやすいことを念頭に入れていくという事を頭に入れておくべきだと思いました。
（もちろん、リソース面での相談も必要です）
予告
次回は以下のどれかにしようかと思っています。
キーワードと添えて提示したので、気になったら是非見てほしいです！
・意図しない振る舞いをするUI
・メンタルモデルに合致していないUI
・マテリアルデザイン、ヒューマンインターフェイスなどのユーザー対象のメンタルモデルが共通化されているデザインシステムの仕様
・ユーザーに余計な負担をかけさせるUI
・タスクベースデザイン
・ユーザーの共通認識が示されているマテリアルデザイン、ヒューマンインターフェイスの利用
・オブジェクト中心のデザインであるOOUIへの変化
・情報が多すぎて、アクションが起こしづらいUI
・デザインの4大原則
・必要な情報を抜き出すためとは？
おまけ（9/1現在転職活動中）
9/1現在、転職活動中です。
業務アプリ開発から、フロントエンド開発に関わるお仕事へ転向したいのですが、それでもいいよ！という会社様を探しています。
詳しい経歴は以下のGitHubにて載せています。
一緒に「けしからんUI」を良くしていきませんか？
お待ちしています！
この記事が気に入ったらサポートをしてみませんか？