使いにくいUIデザインを作ってみた（特急券予約アプリ編）
以前に番外編として公開した記事が社内外で好評だったため、不定期でシリーズ化していきたいと思います。
今回のテーマは特急券予約アプリです。
⚠️デザイン課題を放置するリスクをお伝えするために、診断の様子を再現した架空のストーリーです。企業名、人物名、サービス名などもすべて架空です。特定の団体、人物、モノ、コトを批判する意図はありません。
概要
前提条件は下記の通りです。前回と同様に「患者と主治医」という構図でHighlight診断の様子を再現していきます。
患者：大手SIerに勤務する高橋 健太さん
診断対象：虚無鉄道の特急券予約アプリ「Voidy」
アプリ形式：レスポンシブ対応Webアプリ
スクリーンショット：トップと購入内容確認の2画面
課題：ユーザーに不評でクライアントからの圧力が強まっている
悩み：社内にデザイナーがいないため突破口が見いだせない
ペルソナ
「技術の力で解決できない問題はない」と信じる筋金入りの理系男子。プロジェクトマネジメントに長けているが、UIデザインの知識には少々不安を抱える。
基本情報
名前：高橋 健太
ニックネーム：システム侍
年齢：36歳
職業：大手SIerのプロジェクトマネージャー
居住地：東京都内
経歴
2000年代初頭に工学部を卒業
大手SIerに就職し、システム開発の現場で数々のプロジェクトを指揮
近年、鉄道会社から業務委託された特急券予約アプリの開発プロジェクトを担当
性格・特徴
論理的で分析好きな性格
「プログラムの力で何でも解決できる」と考えている
新しい技術を学ぶことには前向きだが、デザイン分野については自信が持てず、少し後ろ向き
スキルセット
プロジェクト管理やシステム設計に強み
C++やJava、Pythonといったプログラミング言語に精通
UI/UXに関する知識は浅く、デザイナーがいないためプログラマーたちによる「見た目もコードで」アプローチを採用
価値観・信念
「ユーザーは機能が多い方が喜ぶ」と信じている
コードの美しさや効率性にこだわりを持つ
UIデザインは二の次、システムの安定性と機能性が最優先と考える
課題・悩み
使いにくいUIでユーザーからの不満が相次ぎ、クライアントからの圧力が強まっている
デザイナーが不在のため、どこから改善すべきか分からず悩んでいる
UI/UXの知識が乏しく、どうユーザー目線でデザインするべきか分からない
目標
短期間でUIの使いやすさを向上させ、クライアントの期待に応えること
ユーザーのフィードバックを活かして改善策を見出すこと
プログラマー主体のチームでも、使いやすいUIを作れるような仕組みを構築すること
Highlight診断
早速診断をスタートします。高橋 健太さんを「システム侍」と記します。
■ 自己紹介
主治医：高橋さんはじめまして。今日はよろしくお願いします。まず簡単に自己紹介から始めましょう。
私はプログラマーとしてキャリアをスタートしていて、基幹システムから社内システムまで、さまざまな開発プロジェクトに長年従事してきました。その過程で、使いやすくするためにさまざまな法則があることを知り、UI/UXデザイナーへ転身しました。SIerさんのデザインパートナーとして一緒に仕事することが多いので、高橋さんの立ち位置とお悩み、お察しできると思います。高橋さんも自己紹介をお願いします。
システム侍：今日はよろしくお願いいたします。大学の工学部でシステムエンジニアリングを学びました。新卒からいまのSIerに入社して、エンジニアとしてキャリアを積んできました。いまはPMO/PMとして、上流工程からプロジェクトに参画し、ヒアリングから要件定義や非機能要件定義に深く関わり、基本設計や詳細設計もカバーしています。その成果を元に社内のプログラマーやパートナーを指揮する役割がいまのメインの立ち位置です。
大手さんの仕事は、特に非機能要件が厳しいことが多く、細心の注意を払いながら舵取りをしています。開発スタイルはウォーターフォールが基本で、アジャイルの経験はほとんどありません。
主治医：ありがとうございます。SIerさんと一緒に仕事する中で、高橋さんのようなポジションの方の苦悩を見てきましたし、現在進行形でも見ています。大手さんがリスクに敏感なのは宿命といえると思いますが、非機能要件は私も「いまからそれは心配し過ぎじゃないか」と感じることが多々ありますね（笑）。
システム侍：そうなんですよ（笑）。初期リリースの段階で「そこまで？」と疑問を持つことは正直あるのですが、アジャイルではないので簡単に後続リリースができません。それを見据えて「初期でやるか、後でやるか」という選択を迫られるので、最初のリリースまでは本当に苦労が多いです。
主治医：私も過去に経験があるので、いろいろ共感できます。今日はデザイン改善の突破口を見つけたいという目的ですね。私のスキルセットは先ほどお話しした通りですので、技術制約や裏事情などお話できる範囲内でしていただいて全然大丈夫です。フランクにお話しできたらと思います。早速診断をスタートしましょう。
■ アカウントの概念
主治医：今日は2画面お持ちいただきました。順次、チェックしていきますが、まっさきに気になったのがアカウントの概念についてです。ログインしなくても使えるのは、どういう意図があるのか説明をお願いします。
システム侍：Voidyは、誰でも乗りたいときに購入できる特急券予約アプリなんです。ですので、アカウントを持っていない人でも使えるようにこのような仕様になっています。
主治医：なるほど。ログインせずに購入する場合は、支払方法なども毎回入力ということになりますか？
システム侍：はい、そうなりますね。
主治医：ありがとうございます。理解しました。良く使う人であればアカウントを作成するでしょうし、時々の利用であれば毎回入力ということですね。どちらのニーズにも対応し、かつ後者の場合はシステム上、前回の状態を永続的に保持しておくことは難しいので、そのような仕様が落としどころになるなと思いました。
以上を踏まえての小さな課題ですが、現在のログイン状態がやや伝わりにくいと思います。ラベルが動的に変更されるようですが、あわせてアイコンも変わると伝わり度は上がりますね。
システム侍：そこは私もそう思っていました。この程度の変更であれば工数インパクトは低いので、次回のリリースで改善したいと思います。
主治医：それと、ラベルは省略できる可能性があります。ご存知の通り、スマホの縦向きUIは使える横幅が限られているので、もしアイコンだけで十分に伝わると推察されるならば、ラベルは省けるはずです。ログアウトはメニュー内に収めるパターンもありますね。A/Bテストなどを行って省けないかどうか検討してみてください。
また、もしアイコンだけにする場合、昨今のアクセシビリティ対応の観点からスクリーンリーダーのための代替テキストの提供を忘れないようにしてくださいね。
あと、時々の利用であってもアカウント登録するベネフィットは大きいはずです。次の予約が確実に楽になりますよね。マーケ観点でもお得情報などをユーザーに配信できるタッチポイントができることになります。
アカウント登録をうながす導線を設れば、アプリの利用率だけでなく、ユーザーを獲得できる確率も上がり、結果として物理的な特急券が削減されるでしょう。これは環境負荷の低減やコスト削減にもつながる可能性がありますし、昨今、特に大手さんが取り組んでいるDX推進につながっていくはずです。
クライアントから要求が無くても、そういうことを提案すると、御社の評価がますます高まると思いますよ。ぜひチャレンジしてみてください。
■ 予約フォーム
主治医：次にトップ画面の予約フォームに行きましょう。必要最小限のフィールドに抑えられていますね。このフォームについて説明をお願いします。
システム侍：設計段階で、現在時刻から検索したい人と、日時を指定して検索したい人の2パターンがあると想定しました。上部のラジオボタンで二者択一にしているのはそういう意図です。路線がいくつかあるため路線名を選択すると、乗車駅・降車駅のリストが動的に構築される仕様です。往復で予約したいニーズがあることにも配慮して発着を入れ替えられるようにもしています。
主治医：素晴らしいです。完璧ですね。しかし、いくつか課題があります。どこか分かりますか？
システム侍：いえ……ちょっと想像つかないですね。
主治医：3つあります。
まず1つ目は、各フィールドに付与されている「必須」ラベルです。全フィールドが必須のフォームで、それぞれに「必須」とわざわざ記すのかどうか、という話です。
これは一貫性に関する話で、アプリ全体のフォームを一通り俯瞰して眺めてどうするか決めていきますが、必須項目に「必須」と記す全体方針だと、ログイン画面のIDとパスワードでも同じことが起こりますよね。すべて入力必須なのに「必須」と表示するのは冗長ではないかと。
昨今では「必須」を省き、任意のフィールドのほうに「任意」と記すトレンドもあります。今回は2画面しか見ていないので、アプリ全体を見渡してどちらの方針が適切か見直すことをおすすめします。
なお、この方針を決定する際には、アクセシビリティの観点も考慮することが重要です。スクリーンリーダーユーザーにとって、必須項目の識別が容易であることの確認も忘れないように検討してみてください。
システム侍：必須項目は「必須」と表記することが一般的だと考えていたので、一貫性のことはまったく考えていませんでした。アクセシビリティの話も界隈で耳にしています。ちょっと見直してみる余地がありそうですね。
主治医：2つ目は、「路線名から選択」ボタンです。この選択により乗車駅・降車駅のリストが動的に変わるということですよね。いまのレイアウトだと、ボタンサイズが小さく、右寄せにされているので、乗車駅を選ぶためのオプショナルなアクションに見えます。
システム侍：あっ、路線名はあくまでもフィルタリングなので、路線名を指定しない場合は、全路線の駅名がリストアップされる仕様になっています。
主治医：なるほど、でしたら路線名の選択はオプショナルなアクションという意味で整合が取れますね。駅名の数はどれくらいありますか？
システム侍：特急が停まる駅は限られますので、最大30駅くらいだったかと記憶しています。
主治医：それくらいの量なら、路線名でフィルタリングするよりも、30駅から選んだほうが早いかもしれませんよ。ユーザーテストをやってみて欲しいですが、おそらくユーザーは乗車駅の選択ボックスを最初に触るはずで、30駅ならフィルタリングしないと推察されます。この選択ボックスだけで目的を達成できるなら、「路線名から選択」ボタンは、ほとんど使われない機能になりますね。
ちなみに、このアプリはレスポンシブ対応のWebアプリというお話でしたよね？
システム侍：はい、そうです。PHPフレームワークLaravelで開発しています。基本スマホファーストで、PCはその拡大版のようなレイアウトになるようにしています。
主治医：であれば、オープンソースのライブラリをそのまま組み込めますね。一例ですが、SELECT2を使えば、フィルタリング付きの選択ボックスが簡単に実装できます。このライブラリのいいところは、ユーザーが使い慣れている選択ボックスの挙動とほぼ同じなのに、便利な機能が付加されていることです。ユーザーの学習コストが低いんです。初見からほぼ使いこなせます。機能を落とさずにボタンを減らせるのは、UI/UXデザイン観点から見て大きなメリットになります。
システム侍：オープンソースはセキュリティや信頼性が担保できないため、自前で実装するのが当社の基本スタンスなんです。こういうUIを自前で実装するとなると、工数がかかってしまうのが悩みどころです。
主治医：御社のオープンソースに対するスタンスを決める権利は私にはありませんが、先ほどLaravelを使っているとお話しされていましたよね？
システム侍：あっ……Laravelもオープンソースになりますね。
主治医：ですよね。そうなると、御社の基本スタンスの「基本」とは何でしょうか、という話になります。自前実装は車輪の再発明と同じですよ。Laravelと同等のフレームワークを自前で実装するなんて現実的ではないですよね？
システム侍：うーん……そこは社内でも曖昧ということになってしまいますね（苦笑）。
主治医：いろいろお察しします（笑）。生成AIのような技術がいきなり出てくるのが我々の世界ですよね。おそらく自前実装だけで作られたシステムなんて世の中に存在しません。御社のどなたがその基準を決めているのか分かりませんが、こういう矛盾を突いてみてください。納得してもらえれば、そこにかかるコストを本来費やしたい箇所に持っていけるはずです。
システム侍：当社の方針とは言え、そこに異議を唱えるものがこれまでいませんでした。確かに矛盾があることはご指摘通りです。これを契機に課題として上げてみようと思います。
主治医：3つ目は、「発着入替」です。この機能は、先ほど高橋さんから説明があったように、往復で予約する人にとって有益な機能だと思います。しかし、ボタンの位置が不自然です。
乗車駅と降車駅を入れ替えるわけですよね。これら2フィールドの間に配置するのが自然です。雑ですが、こんな感じに。
上下矢印のアイコンをボタン内の文字の左側に置くと、ユーザーがこの機能の意味を素早く理解する手助けになります。「操作結果が反映される場所に近接させよ」というのは、UI/UXデザインにおける「近接性の原則」に合致するものなんです。
システム侍：このボタンを押し間違える、というフィードバックが多い理由が分かりました。先ほどのお話通り「路線名から選択」ボタンを無くせるとしたら、こういうイメージにできますね。これはやってみたいと思います。
■ 購入内容確認
主治医：次の画面に行きましょう。いろいろな情報が表示されていますね。説明をお願いします。
システム侍：この画面は、アカウント登録をしている人が閲覧できる購入履歴となるものです。詳細の確認や領収書の表示などができるようになっています。
Voidyの特急券は駅の券売機でも購入できますが、このアプリを使って購入した場合、物理的な券がありません。この画面を特急券購入の根拠として駅員に提示する運用ルールになっているんです。そういった一連の確認操作が可能な画面になっています。
主治医：詳しく説明いただき、ありがとうございます。少し情報過多に感じられますが、レイアウトを整えればある程度は解決できそうです。
チャレンジしてみて欲しいのは、本当にこれらすべての情報を表示する必要があるかどうかの確認ですね。例えば購入額や決済方法は、駅員に見せるという場面では必須とは思えません。いま一度クライアントとすり合わせてみてください。表示項目を削ることができれば、より見通しを良くできますので。
その上で2点確認させてください。
まず1つ目は「購入済」と「発車済」のタグです。先ほど「駅員に提示する」というお話がありましたが、購入済はともかく「発車済」の表示が必要なのか、という疑問です。特急は既に発車しているわけですよね。駅員に見せる場面が思い浮かばないですが。
システム侍：うーん、そう突っ込まれると反論が厳しいですね（苦笑）。発車済であることが駅員にとってすぐに分かるようにしたい、という意図でした。
主治医：当事者になると運用側・利用側の両面から設計しないといけないので難しい場面だとは思います。ただ、ユーザー目線で考えてみてください。発車済の履歴をユーザーが表示する頻度はどれくらいあるでしょうか。ユーザー目線で想像してみると、発車済の乗車券はもう役目を終えています。後で領収書の清算などをする場面で閲覧できれば十分だと思います。
履歴ということなので、自分が購入したすべての券が表示されるのですよね。とすると、ユーザーは駅員に見せるときに、「発車済」を脳内で除外しながら自分がこれから乗車する特急券をこの画面の中から探さないといけないはずです。
先ほど情報過多のお話しをしましたが、この作業はユーザーの認知負荷が相当に高いですよ。「認知負荷が高い」、というのは脳が情報量の多さに圧倒されて、正常な判断が難しくなる状態のことを指します。毎日使う人がいるとすると、このストレスの蓄積は私から見て見過ごすことができない問題です。
システム侍：システムとして、すべての履歴を表示する必要があるという仕様に固まっていたので、実装としては設計に忠実です。ただユーザー目線で見てどうか、と問われたら先生のおっしゃる通りなのかもしれません。
主治医：様々な事情で、どうしてもすべての履歴を表示する必要があるとしたら、「過去の乗車履歴」のような新しいセクションを設けて、発車済の履歴をそこに移動させると、視認性を高めることができます。
システム侍：そうですね、そのようにすればクライアントも納得しそうです。検討してみます。
主治医：2つ目は内訳です。初期状態で折りたたまれている状態ですね。意図を教えてください
システム侍：先ほど先生からも指摘いただきましたが、我々も情報が多すぎるとは認識していました。何を削れるか、という観点で駅員に見せる必要のない項目をエクスパンダー内に収めて、デフォルトでは折りたたまれて見えない状態にするという仕様に落ち着けたんです。
主治医：その発想は、先ほどと同様に駅員視点での発想ですね。ユーザー視点で見てみてください。自分がどの席に座ればいいのか、その重要な情報がデフォルトで隠されていることになります。
この仕様だと、ユーザーは特急に乗車するために、
駅員に購入履歴を見せる
内訳を展開する
号車と座席を確認する
という3ステップを経て、初めて自分が乗る座席の情報にたどり着けることになりますね。どう思いますか？
システム侍：面倒ですね……。
主治医：でしょう（笑）。先ほど運用ルールの話をしました。この場面は端的にいうと駅員の負担が軽く、ユーザーの負担が重いといえるはずです。
雑ですが、例えばこういう表示が可能だと思います。
ポイントが4つあります。
区間と時間を分割
日付と時間を隣接
乗車口を追加
右端のシェブロンで詳細が見れることを示唆
「3」ですが、さっきちょっと調べたところ、Voidyは行きと帰りで先頭車両が変わりますね。ということは、最適な乗車口が変わると思います。このように乗車口が表示されると、ユーザーは待つ位置を間違える心配をすることなく安心して待てるはずです。乗客がスムーズに乗車できることは、時間通りに運行するという観点で、運用面でも大きなベネフィットになるはずです。
いかがでしょうか？
システム侍：確かに。項目が増えているのにユーザーは理解しやすくなっているということですね。こういう発想はありませんでした。
主治医：基本的に、表示項目は少ないほうが良いですが、ユーザーにとって有益であれば、むしろ追加表示したほうがUXは向上します。そして並び順ですね。単に並べるだけでは不十分です。ユーザーが乗車する場面を想像しながら、ユーザーが知りたいであろう順に優先度をつけて並べるのが重要です。上から下へ、あるいは左から右へですね。
システム侍：我々にとって馴染みのない発想でしたが、要は自分が乗るときのことを想像してみることが大切だと理解しました。考えてみたいと思います。
主治医：鉄道というのは、国民の生活を支える重要なインフラですが、乗客がいなければ経営が成り立たなくなることは、コロナ渦で見てきましたよね。昨今の働き方改革などを鑑みると、両者の負担が対等であることが望ましいと言えますが、経営視点で見たら、やはりユーザーの利便性を最優先に設計すべきではないでしょうか。
アプリの使い勝手が悪くてユーザーが離れていく末路はサービスの終焉です。しかし、鉄道ほどの大きなインフラは代替手段がほぼありません。だから使い勝手が悪くてもユーザーは使い続けるはずです。
そこに慢心しているとは思いませんが、そのしわ寄せが誰に行っているのか。ユーザーなんですよ。ここを良く鑑みて、より良いシステムを目指していってください。
システム侍：我々は良くも悪くも顧客の望むものを、望む通りにシステムに落とし込むのが仕事で、それが安定して稼働すること、堅牢であることを最優先にシステムを作り上げていきます。
今日のお話を聞いて、ユーザー目線で設計を進めていかないと、最終的にはクライアントの利益向上につながらないという気付きを得ました。この話を社内に展開し、ユーザー目線でシステム設計を考えられるようマインドを改革していきたいと思います。
主治医：高橋さんのチームならきっとできるはずです。また悩みが出たら相談に来てくださいね。
まとめ
今回は架空とはいえ、現実のHighlight診断に近い様子を再現してみました。
これは私の個人的な見解なのですが、「使えればいい」という考え方が広がっている背景には、複雑な要因があるように思います。SIerの方々も、そしてクライアントの皆さまも、それぞれの立場で最善を尽くされていると思うのですが、時として、より良いユーザー体験を追求する機会を見逃してしまうことがあるのではないでしょうか。これは、業界全体で考えていく必要のある課題だと思います。
「使えればいい」。それは一つの正解なのでしょう。しかし、DX推進という文脈に当てはめて考えると、DX にはさまざまな「X（UX、EX、CX、BXなど）」が包含されています。この「X」、すなわち体験が好循環しない限りDXは成立しない、というのが私たちの考えです。だからこそ、その体験循環の起点になるアプリのUI/UXにもっと目を向けて欲しいと願っています。
今回は鉄道という国民生活に欠かせない巨大インフラをテーマにしましたが、これが競合ひしめく業界向けのアプリであれば、「使えればいい」発想は通用しないでしょう。なぜなら、ユーザーの心を鷲掴みするアプリがどんどん世に出てくるからです。
次回のテーマは決まっていません。もしこれを取り上げて欲しいなど要望がありましたら、気軽にコメントください！（記事化するお約束はできませんが🙏）
お問い合わせはこちらから（ヒアリングからお見積りまで無料です）。
この記事が気に入ったらサポートをしてみませんか？