システム開発とメディア運営のコンサルティング

アプリUI研究室

ウェブ制作

001アプリのUI設計の前にまずは「軸となる対象」を探そう

このエントリーをはてなブックマークに追加
      
どもども。株式会社ノイズの池永です。
当社は、もともとマーケティングコンサルティングをメインにした会社だったのですが、顧客要望にあわせて業態を変えていたら

  • 要件定義
  • UI/UX設計
  • DB設計
  • プロジェクトマネジメント
  • 実装
...と、システム開発における上記業務が50%以上を占めるようになっておりました。

最近では、

「顧客から要件定義があがってこなくて何も進まない」

とお困りの開発会社さんや、その逆で

「システム開発をしてもらいたいのだけど、どうやって頼んだらよいかわからない」

というシステム開発会社に発注する企業の双方からご相談をいただいており、いわゆる「上流工程」の業務が増えてきている...というわけです。


さて、前置きが長くなってしまいましたが、UIですよ。UI。

ご存知「UserInterface」の略称ですが、アプリなどのソフトウェアにおいては、UIがアプリの人気を左右する...と言っても過言ではなく、逆に設計をミスるとクソアプリ化不可避...という恐ろしいシロモノ(最重要タスク)ですよね?

そんなシロモノなのに?!PC向けサービスを主戦場としていたディレクターやプロデューサーなんかは

『言うてもアプリなんて色々いじっとるし。ウェブとかわらんでしょ』

とナメてかかるわけです。
その結果、クソアプリが出来上がる...と、まぁ、言うまでもなく4年前くらいのワタシです。

というわけで、本連載では私が作った架空の課題をもとに、アプリのUIについて「こうしたらうまくいった」という最適解をお届けできれば...と思っております。


とにかくメニューを並べたがる病(やまい)

いきなりですが、架空事例いきましょう。
保育園の先生向けに園児を管理するアプリを開発するとします。

ざっくり要件

  • 園児のステータスを見たい(出欠/体温/注意事項)
  • 園児の生活状況に記録をつけたい
  • 体温の推移をみたい
超ざっくり要件として、上記要望がクライアント(保育園)からあったとします。

さて、どうしましょうw

大方の場合、

  • 園児を探せるようにする
  • 体温をつけられるようにする
  • 記録をつけられるようにする
...といった、「アクション」ベースで機能を思考しがちです。
その結果どうなるか?というと、わかりやすくするため画面構成を書いてみました。

【構成書】

このUIの最大の問題点はなんでしょうか?


・園児を探すところが起点になっている


これです。

一体、園児は何人いるんですか。
大きい保育園の年長さんだと1クラス20人くらいでしょうか。

20人分毎回検索して「太郎くんは出席」「洋子ちゃんは欠席」...なんて1人ずつアクションをするとかどう見ても死亡フラグです。
こんなもん納品してみなさい...

先生『ごめんなさいねぇ。やっぱり紙で管理したほうがはやくて。やっぱりアプリは慣れないわ』

と言われてジ・エンドです。
まぁ、先生が直接担当者になるということはないとは思いますが...


要件漏れてないすか?

じゃあ、どうすべきか...と悩ましいわけですが、実はこれ「要件漏れてました。すんません」パターンだったりします。
このアプリを使うのは保育園の先生です。
先生は担当のクラスを持っています。

...となると、クラス単位で「一覧」で園児の様子が見れたほうが都合がよいわけです。

最初の要件

  • 園児のステータスを見たい

修正後の要件

  • 園児のステータスを「一覧」で見たい
と華麗に変更が入ることになります。


軸を決めよ!

今回、このアプリの軸となる対象は何でしょうか?

いわずもがな「園児」です。
先生はあくまでもその「園児」を管理して情報を見る側なので主役ではありませんね。

実は、アプリUIの設計においてはじめのキモとなるのは、【軸となる対象】を明確にすることです。
そして、この【対象】というのは実はそれほど多くなく

  • モノ
  • 時間(時期)


...この程度だったりします。

じゃあ、軸となる対象が「人」の場合UI上どう表現すればよいのでしょうか。

【構成書】

氏名を一覧で並べた画面を用意する。たったこれだけです。


ボタンは付けるな。死ぬぞ(アプリが)

あとは、肉付けをしていきましょう。

  • 園児のステータスを「一覧で」見たい(出欠/体温/注意事項)


この部分...はこんな感じで実現してみます。

【構成書】

一覧で出欠状況を見れて、体温も見れて...と。

では、

  • 体温をつけられるようにする
  • 記録をつけられるようにする
この要件はどのように実現しましょうか。

【構成書】

こんな感じでボタンをつけますか。

でも、これって体温と記録以外の「アクション」要件が増えた場合どうするんでしょ?
ボタンをどんどん増やしていきますか?
てか、同じ情報のボタンを1園児の行に並べていくの...やばくないすか?

そうなんです。
「アクション」が今後増えることを想定したUIにしておかないといけないわけです。

【構成書】

というわけで、こんな感じで、氏名行をタップすると「アクションをリスト表示したダイアログ」を開く仕様にします。
これなら、アクションが増えてもダイアログをスクロールすればよいだけなので拡張性が高いですね。

...ただ、これでは実はまだ不十分。
『出欠とか1園児ずつ登録したくないんだけど』という意見が出てくるわけです。

...と、今回はここまで。次回に続きます。

© NOIZZ Inc

 
このエントリーをはてなブックマークに追加
   

著者情報

イケナガヒサシ

池永尚史

株式会社ノイズ代表取締役。システム開発の上流工程が得意領域。

執筆陣一覧

池永尚史

関連記事