NikoNikoLog 開発の記録 (7) - "アプリとしての自然な動きを研究せよ!" UI/UX設計は注意深く観察するところからはじまった
前回の記事で軽く触れた UI/UX 設計の話。前回、以下のように書いていました。
ただ実際にアプリと同じレベルのユーザー体験を実現しようと思うと、そもそもの普段使っているアプリの「自然な動き」の部分(普段は誰も意識していない動きや操作性の部分)がどのように設計、実装されているのかを注意深く観察して、それをひとつひとつウェブの技術で置き換えて実装していってやる・・・っていう、結構途方もない作業があったりもしました。
この辺りの話を今回は少しばかり掘り下げて書いて行こうかと思います。
UI/UX におけるアニメーションの話
まず最初に書いておきたいことがあります。UI/UX デザインにおいてのアニメーション(≠ ウェブデザインにおけるアニメーション)とは、「動いていると楽しそうに見えるから」などといった単純かつ安易な理由で採用すべきではないと考えています。
ではなぜアニメーションが必要な場面があるのでしょうか?
答えは結構簡単です。アニメーション自体が情報のひとつ(視覚的情報を伴ったユーザー体験)になることができるからです。
ちゃんと考えられた UI/UX ではユーザーが 気持ち悪い違和感 を覚えるような不自然なアニメーション効果がかかることはまずありません。むしろユーザーのアクション(画面操作)に対してごくごく自然に、そしてアクションとアニメーションに連続性があるように設計する場合がほとんどです。これが UI/UX におけるアニメーション効果採用時の鉄則です。
アプリとして自然な動きを追求することからはじめた UI/UX 設計
この連載の第1回目の記事でこんなことを書いています。
現在のNikoNikoLogのモバイルウェブ版は所詮ウェブブラウザの中で動いているサービスで、ユーザー体験も一般的なウェブサイトの操作に近いものであり、スマートフォンアプリのような操作性、ユーザー体験は得られないものでした。
画面操作によって次に表示される画面が、どのように画面内に出現すべきかには大きな注意を払って設計しました。実際にはもっと細かくパターンがあるのですが、大まかなパターンで言うと画面表示時のアニメーション処理は、以下のようなものを組み合わせています。
- アニメーション処理なし
- 画面下部から画面上部に向かって画面が表示され、閉じるときは画面下部に向かって消えていく
- 画面右側から左側に向かって画面が表示され、閉じるときは画面右側に向かって消えていく
まず画面最下部の「タブバー」と呼ばれる領域のアイコンがタップされた時の画面切り替えは、アニメーション処理をかけていません。これは iPhone でも Android でも大体同じような動きを採用している場合が多く、普段からスマートフォンに慣れ親しんだ動きでユーザーには違和感のない動き、共通言語のようなものです。
タイムラインとカレンダーの画面右下にある「+」ボタンをタップして投稿用の画面が表示されるときは、投稿用の画面は画面下から上に向かって表示されるようにしました。端的に言うなら、これはこのアクションが単一のものであることを意味していますが、同時に画面に対して入力を求めるような場面の一部の場合を除く多くでこの動きを採用しています。逆にこの動きは、画面に対して入力が求められる場面でない場合はほぼ採用していません。
カレンダーで各曜日をタップしたときに曜日の詳細が表示されるときは、右側から左側に向かって・・・のアニメーションを採用しました。これはカレンダーの月→日の流れは大きな連続性があること、そして曜日の詳細ではユーザーに対して入力が求められることがないことから採用しました。
それ以外の例もまだまだ・・・
上記のアニメーションのパターンには上げませんでしたが、例えばカレンダー画面では右スワイプや左スワイプで表示している月を切り替えられる+それに応じた左右の動きを採用していますし、各曜日をタップした時の曜日詳細でも前後の日への切り替えのために同じ動きを採用しています。
ここでも大きな注意を払い設計、開発した点がいくつもあります。
それは、例えばゆっくりと横スワイプ動作がされている場合は完全には前後の画面に切り替えずに、前後の画面と現在の画面がスワイプ動作に合わせてスクロールされている状態で表示することや、ちょっとだけ横スワイプされただけなら画面の切り替えはキャンセルされること。これらはスマートフォンの中での動きとしては最近のユーザーの間ではごくごく自然な動きでしょう。
また、この右 or 左のスワイプで画面が切り替わる際のアニメーションも、おそらくここで書かなければ気づかれないレベルで注意を払っています。
例えば完全に画面が表示されていない状態から、画面が完全に表示されるまでのアニメーション時間を100とした場合、ゆっくりなスワイプ操作によって画面が半分まで出ている状態なら、その状態で指を離したとき画面が完全に表示されるまでのアニメーションは50の時間で行われるように・・・などのことです。
これらの小さな注意や配慮を積み重ねることは大変な忍耐力などのコストを必要とします。しかしこれらを無視せずに注意深く取り組むことによって、確実にユーザー体験は向上するのです。
次回・・・
次回の記事のネタ自体は未定なのですが、書こうと思っていることはまだまだいっぱいありまして。例えば10年ほど前にリリースされた弊社の初期の iPhone 用アプリである NikoNikoLog から今回のリリースに至るまでにどんな歴史があったかなどなど・・・とりあえず、ここでの執筆は続けます。
次回の記事にもぜひお付き合いください。
関連記事
- NikoNikoLog 開発の記録 (10) - リリース後に各方面からレビューもらってます。そして過去も未来も自由自在になりました。
- NikoNikoLog 開発の記録 (9) - iPhone/iPad版が App Store でリリースされました
- NikoNikoLog 開発の記録 (8) - パブリックベータ・・・ではなく、ついにアップデートがリリースされちゃいました。
- NikoNikoLog 開発の記録 (7) - "アプリとしての自然な動きを研究せよ!" UI/UX設計は注意深く観察するところからはじまった
- NikoNikoLog 開発の記録 (6) - 実は秋にリリースされる iOS 13 から追加されるダークモードにも対応しています
- NikoNikoLog 開発の記録 (5) - ホーム画面に追加して使うとアプリじゃないのにアプリ(っぽく)なります。お知らせ?重大発表?
- NikoNikoLog 開発の記録 (4) - ニコニコカレンダー、初登場から10年の時を経て遂に生まれ変わる 【 開発中の画面を初公開!】
- NikoNikoLog 開発の記録 (3) - TAppKit が生まれ、その開発がはじまった
- NikoNikoLog 開発の記録 (2) - CoffeeScript or JavaScript と CSS でフロントエンド用のフレームワークを作ることになった
- NikoNikoLog 開発の記録 (1) - "スマートフォンからもっとリッチに使いたい!" からはじまった