RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのエンジニアブログ

「とりあえず動く」を目指した個人開発アプリが想像以上に使いづらかった話

はじめに

こんにちは、MasaKuです。

プライベートの時間を利用して、ニュース記事などで見つけた面白そうな技術を使ってみたり、「こんなのあったら便利かも?」と思ったものを作ったりしています。

そこで、最近流行のゲームである、対戦相手を攻撃して画面外にふっとばすゲームの対戦記録を残せたら便利じゃないかな?と思い、簡単なWebアプリを作ってみました。

とりあえず動く」を目標に作成していたため、使い心地などは一切考慮せずに作っていましたが、そもそも簡単なアプリなので、そこまで工夫できるポイントもないかと思っていました。
しかし、既存アプリの調査をしてみるとちょっとした工夫でユーザの操作を楽にできることに気づいたので、自分の反省のためにも記載していきたいと思います。

アプリ概要

まず、今回作成しようと思ったWebアプリで実現したかったことは以下です。

  • twitterのOAuthによるユーザ登録とログイン機能
  • 使用キャラクターの利用回数の記録
  • 使用キャラクターの勝率の表示

対戦情報をより詳細に記録できるようにしたかったのですが、ひとまずの目標は対戦回数と勝率が出せたらいいかと思い、このような形になりました。
また、上記程度であれば、実装イメージも湧きやすかったというのもあります。(個人開発のモチベーション維持には実は大事)

作成したWebアプリの画面は以下のようになりました。

f:id:MasaKu:20190122125133p:plain
トップページ

データベースに入力値を登録するだけの簡単なフォームですが、必要な要件はクリアしています。

使いづらい点

上記機能がすべて利用可能な既存アプリと比較して、今回作成したWebアプリの使いにくい点について、特に気になったポイントをご紹介したいと思います。

無駄な送信ボタン

私の作成したWebアプリでは、以下の操作が必要です。

  1. 使用したキャラクターをプルダウンから選択
  2. 勝敗をプルダウンから選択
  3. 送信ボタンを押下する

上記のうち必要が無い操作だと気づいたのは「3. 送信ボタンを押下する」です。

通常、送信ボタンを押す前にフォームに必要な情報が全て正しく入力できているかをユーザに確認させる必要かあります。

しかし、今回のWebアプリのような簡単な入力画面では必ずしも確認するフェーズは必要ではないのではないかと思いました。

入力間違いが許されないような画面については、送信前に確認させる意味合いも込めて、送信ボタンを押させる必要があるかと思います。
しかし、今回のような場合は少ない操作で登録できて、後から簡単に修正できるようにするのも良いかと思いました。

つまり、この操作は以下のように修正することができます。

  1. 使用したキャラクターをプルダウンから選択
  2. 勝敗ボタンを押下

f:id:MasaKu:20190122125444p:plain
送信ボタンを削除

確認ダイアログが何度も表示される画面などと似たケースにはまっていたのかもしれません。

キャラクターの選択操作

私の作成したWebアプリで使用したキャラクターを選択する場合は、プルダウンから選択する必要があります。
そのため、日本語化されたキャラクター名を探して、該当項目を選択しなければいけません。
しかし、既存アプリの場合は、キャラクターのサムネイルを選択するという方式になっていました。

f:id:MasaKu:20190120175053p:plain
キャラクターの選択方法

対象ユーザはゲームを遊んでいる人なので、キャラクターの名前と、キャラクターのサムネイルではどちらの方が馴染み深いかは言うまでもありません。
キャラクターの名前を忘れてしまうことがあっても、キャラクターそのものを識別できなくなることはほとんど無いでしょう。

選択肢がある入力フォームではプルダウンが採用されるという固定概念ができてしまっていたと感じました。

まとめ

今回は、以下の二点について勉強になりました。

  • 必要がない操作の削減
  • 探しやすい選択項目の表示方法

Webデザインにおける認知負荷では以下に気をつけなければならないようです。

  • 操作負荷 … マウスやキーボードといった機器の操作
  • 視覚負荷 … 目の前にみえる情報に気を止めたり、気付いたりすること
  • 知覚負荷 … 考えたり、記憶したり、スキーマと関連付けさせること

今回の場合は、操作負荷と視覚負荷を高めてしまった形になるかと思いました。

普段の開発業務では、モックや詳細設計書の画面イメージを元に開発を行います。
そのため、使いやすい画面とはどういう作りになっているか、ということについて、あまり意識していませんでした。

開発に携わるものとして、デザイン上のアンチパターンについてはしっかりと認識しておかなければならないと思いました。

参考サイト

builder.japan.zdnet.com

Copyright © RAKUS Co., Ltd. All rights reserved.