327
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

updated at

【OOUI】設計を改善したらユーザー(オカン)が使ってくれるアプリになった話

​​▼この記事では、前回の記事で紹介した自作アプリを題材にしています。
前回の記事を先に読んでもらえると、この記事の内容がより理解しやすくなると思います!
【初アプリ】未経験がFlutterで肉牛繁殖農家のためのアプリを作ってみた

こんにちは、Takuです。
先日、Flutterで肉牛生育記録管理アプリ「Memow」をリリースしました。​

このアプリのユーザーである自分のオカンオトンは、特にこちらからレクチャーせずとも問題なく使いこなしています。
基本的にオカンがデータを入力し、オトンは共有データを閲覧するという使い方をしているようです。

それまでアナログ管理をしていたオカンオトンがすんなりこのアプリを使用できていることについて、前回の記事を読んでいただいた方から「驚いた」という反応を多くいただきました。

ユーザー(オカンオトン)がこのアプリを使えている理由を自分なりに分析すると、

①対象ユーザーを極限(オカンオトン)まで絞り
②対象ユーザーからニーズを徹底的に聞き取り
③ユーザーの課題解決をしつつもアプリの機能を最小限とし
④OOUIに基づくデザイン設計を意識した


この4点がその理由だと考えています。
特に、④の当初のOOUIデザイン設計はダメダメでしたが、設計の改善を行うことでユーザーが使ってくれるアプリになったと思っています。
今回の記事ではどのようにこのアプリの設計を改善していったのかを紹介していきます。

OOUIとは


そもそも「OOUI」とは何でしょうか?

「Okan Oton に適した User Interface」

「Object-Oriented User Interface」

ですね。

しかし自分はOOUIというもの自体知らずにアプリの制作を着手したため、「Memow」の初期デザインでは「なんだかよくわからんなぁ」とオカンに一蹴されました。

そこで、使いやすいUIとは何なのか、オカンが「使いやすい」と言っている他のアプリを中心にひたすら調べていったところ、「Memow」のデザイン設計には問題があることに気づきました。

そこで存在を知ったのがOOUIです。

自分は主にこちらの書籍でOOUIデザイン設計を体系的に学びました。

「オブジェクト指向UIデザイン」

「オブジェクト指向UIデザイン」技術評論社
(ソシオメディア株式会社 上野学 藤井幸多 著 上野学 監修)

以降は実際のデザインのビフォーアフターを見ながらどう改善していったかを説明します。

デザイン(ビフォー)


まずは、「Memow」の改善前のデザインを見てみましょう。

旧デザイン.jpg

【ポイント】

  • ボトムナビゲーションバーは「ホーム」「メニュー」「設定」の3つ
  • 「ホーム」には親牛と子牛が混合した一覧を表示
  • 「メニュー」には牛の登録や牛の行動の記録といったアプリ内でできる全ての機能を配置

【問題点】

①親牛と子牛で要件や動作が異なるのに、「牛」という同一オブジェクトという認識で設計している(「ホーム」画面)
②操作の起点となるオブジェクトを定めていなかったため、全ての機能を「メニュー」に突っ込んでいたる

ユーザーの行動を十分把握していなかったため、メインオブジェクトを何に設定するかあまり意識しておらず、結果としてユーザーの導線にそぐわない構造となってしまっていたのです。

デザイン(アフター)


続いて改善後のデザインです。

新デザイン.png

【ポイント】

  • ボトムナビゲーションバーは「ホーム」「親牛」「子牛」の3つ、つまり 「親牛」と「子牛」をメインオブジェクトに設定
  • メニュー内に配置していた項目は「親牛」「子牛」それぞれの詳細情報内に配置、つまり「親牛」「子牛」の「サブオブジェクト」に設定
  • 上記変更により「メニュー」が不要になったためボトムナビゲーションバーから削除

【改善点】

①親牛と子牛は要件や動作が異なり、同一オブジェクトには適さないため、それぞれをメインオブジェクトに定めた
②親牛や子牛の状態の記録・編集は、それぞれのサブオブジェクトとなるため、「メニュー」を廃止した

最も大きな改善点としては「親牛」と「子牛」を別オブジェクトに分けたことです。

そして、その詳細情報の中で、妊娠・出産といった牛の行動の記録ができるデザインにしました。
このため、メニューというタブが不要になりタブバーから消えています。
​​
改善前のデザインでは、「メインオブジェクトを何にするか」を特に意識せず構成していたことで、使い勝手の良くないデザインになっていたのだと思います。

ユーザーであるオカンがアプリを使用するシチュエーションを深堀りして、メインオブジェクトを見直したことで、改善につなげることができ、オカンにも使えるアプリになったのです。

メインオブジェクトの決め方


では、そのメインオブジェクトはどう決めればいいのでしょうか?ここでは、自分のアプリを例にどのようにメインオブジェクトを定義し直したかという手順を紹介します。

@tetsukick さんの下記記事を参考にさせていただき実践しました。
デザインに心がないエンジニアがOOUIの手法を使ってデザインをし直してみた

ご自身で開発されているアプリを例にデザインし直した経緯が書かれていたので非常に参考になりました。

①オブジェクトの抽出

まずは、アプリ内でユーザーが行う行動を、一つ一つ洗い出しました。

概念.png

例えば、
ある親牛妊娠経過日数確認する
ある子牛生育日数確認する
のような感じです。

②ユーザーがアプリで「何を」「どうする」のか整理

次に、ユーザーが実際にアプリ内で実行する行動を名詞と動詞に分けて整理しました。
OOUIでは、名詞を手がかりにオブジェクトを抽出していきます。

何を.png

上の図では、青色が名詞(オブジェクト)、赤色が動詞となっています。

このように整理することで、オブジェクトとユーザーのタスクがわかりやすく区別できますね。

③ビューの定義と設定

そして、ここまで整理した情報を元にビューを定義していきました。

ビュー.png

ユーザーの行動を整理した結果、行動の起点となるオブジェクトは「親牛」「子牛」であり、その中に「コレクションビュー(一覧)」「シングルビュー(詳細情報)」があるべきということがわかりました。

まとめ


今回の記事では自分のアプリを例に

  • メインオブジェクトの設定を誤るとアプリの設計、デザインすべてに影響を及ぼす
  • メインオブジェクトの設定はアプリを使用するシチュエーションをしっかり把握することが大事
  • ユーザーにとって学習効率が悪いアプリとなっている場合、OOUI設計を見直すことで解決の糸口が見つかることも という自分なりの気づきを書きました。

「Memow」の改善前デザインをオカンに使ってもらえなかったのは、「メインオブジェクトの設定を誤っていた」ことがデザインや設計を悪くした根本的な原因だと考えています。

また、当初「メインオブジェクトの設定を誤っていた」原因は、「ユーザー(オカンオトン)が実際にどのようにアプリを使うか」を把握できていなかったためです。

ユーザーにとって学習効率が悪いアプリとなっている(使ってもらえない、使い方がわからない)場合、OOUI設計を見直すことで解決の糸口が見つかるかもしれません。

そのためにも、まずはユーザーがアプリを使用するシチュエーションをとことん突き詰めて、整理してみることが大切と思います。

今回シェアした内容は、あくまで「自分のアプリの場合」ですが、OOUIの設計を見直したことによりUXが向上した例として参考にしていただければと思います。

※この記事の内容については7月22日にMobile Actに登壇した際にもお話しさせていただきました!
スライドと動画のアーカイブは下記になります。
【スライド】オカンとオトンから学んだOOUIデザイン設計
【動画アーカイブ】Mobile Act ONLINE #1
(自分のLTは1:07:00くらいからです)

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
327
Help us understand the problem. What are the problem?