ストレスを感じるUI

webページやアプリを使用していると「このUI使いにくいな~」とストレスを感じることがあります。UIの設計ミスからくるストレスは大きなものから小さなものまでありますが、小さいものに関してはネタとして小さいので記事にする人は少ないです。

今回の記事では、そんなちょっとしたストレスを生むUIについて紹介したいと思います。
小さく細かな事に関してご紹介いたしますが、こういった事を直すか直さないでUIの良し悪しが変わってきますので是非チェックしてみてください。

1.見た目と動作にズレのあるインジケーター

職場のPCでファイルを検索していたときのことです、検索に時間がかかっており、待っている間が仕事をサボっているように見えたらどうしよう…と一人でソワソワしながらインジケーターが満タンになるのを心待ちにしていました。

メーターが終盤に差しかかり、そろそろ終わる!と思いました。

しかし…
ゲージは終点だと思っていたところを超えて進みはじめました…。

終わると思っていたのに突然「実は終わっていませんでした」という現実を突きつけられたため、この後の待ち時間はさらに長く感じました。

このように、見た目と実際の動作や状態がかみ合っていない状態はUIではNGです。オレンジ色のガムを噛んだときにマスカットの味がしたらモヤモヤしますよね。

2.間違った記号の使い方

このようなメニューがありました。各項目に+マークがついています。

その中からカテゴリ一覧を押すと…

このように追加の小カテゴリが開くのかと思ったのですが…
実際は”別のページへ遷移しただけ”でこのメニューに使用している+の記号には何かを付け加えるという意味はありませんでした。この場合は+ではなく矢印が最も直感的で適切です。

“記号”の持つ意味はとても強いです。
矢印は矢印です。プラスはプラスです。(だんだん何を言っているのかわからなくなってきましたが…)利用頻度が高く意味が周知されている記号はよほどひねった見せ方をしない限り別の意味を付け加えることはできないですし、付け加えるべきではありません。
記号は薬のようなものです、決まった症状に決められた効果しか発揮しません。風邪薬を肌に塗っても意味はありませんし、湿布を口に入れても何の意味もありません。

3.動作に一貫性の無いボタン

とあるページを見ていたときに下記のような連続するボタン(ポイント①~③)がありました。
ポイント①ボタンとポイント③ボタンは押下するとポップアップが表示され、②ボタンはページ内の別の箇所へジャンプ(ページ内リンク)という構成になっていました。

①をタップした場合ポップアップが表示されるため、ユーザーは②を押した場合も同じようにポップアップが表示されると予想します、しかし②を押すと予想に反し同一ページ内のどこかに飛ばされます。
こうなってくるといよいよ③のボタンは何が起きるかわからなくなってきますよね。このような状態はユーザーにストレスを与えます。
ユーザーはサービスを利用する事で無意識に利用方法を学習していくため、起きるアクションは全て統一するべきです。アプリケーション単位でのルック&フィールを意識できていないためこのような作りになったのだと思います。

また、②を押してページ内のどこかへ飛んだユーザーはポイント③を押そうとして再び③を探します。この時点でユーザの目的は読むから探すへ変わるため本来目的が変わってしまい結果的に動作をとめた事になります。

4.動作の妨げになる表示

あるOSではスマートフォンの音量を変更した時、画面の中央に音量表示が大きく現れることがあります。(2018年9月現在)
動画を見ているときでも容赦なくこの表示が出てくるので、音量変更のたび視聴の邪魔をされます。また、ブラウザ使用中でも、ゲーム中でもこの表示は画面中央に大きく現れるためとてもストレスを感じます。この見せ方は音量調節を頻繁に行うユーザーにとっては頭が痛くなる見せ方です。

ここまで大胆に表示しなくても十分伝わるのに…せめて表示位置の設定をさせてもらえれば…。と思ってしまいます。
解決法はシンプルです。画面の上下左右または四隅に表示するだけです。


今回は細かくて地味ですがストレスを感じるUI を紹介しました。このような細かいストレスでもちりも積もれば…ですので、改めてサービスを見直してみてはいかがでしょうか!

お読みいただきありがとうございました!
(はら)

実は似ている?UIと映画の没入感

こんにちは!
今回のテーマは「実は似ている?UIと映画の没入感」です。

私は映画が好きなのですが、好きな理由の1つに「没入感」があります。
映画を見る中で、没入感を演出する為の考え方が映画とUI設計で似ているなと思ったのでまとめてみました。


UIと映画の没入感とは

没入感とは何かと言うと、「すっかり熱中して、その世界に入り込んでいるという感じ、浸っている・没入しているという感覚などを意味する語。(Weblio辞書)」です。
映画やゲームなどで、創造力と技術が織りなす映像や音楽、ワクワクするシナリオ、魅力的なデザインに夢中になった経験があるのではないでしょうか?その体験が没入感です。

映画などに集中する様を形容する場合に使われることが多いですが、UI/UXやVRの世界でも同じ意味で用いられている言葉です。
UI/UXに没入感?と思った方は、スマホアプリを見てみると想像しやすいかもしれません。
ゲーム系でもツール系でも、それぞれのアプリの目的に合ったUI/UX設計がされていると、ユーザーはストレスなくサービスを利用することが出来ます。
ユーザーが迷わないと言う事は、集中して目的を達成出来ると言うことですので、そのサービスに没入出来ていると考えられます。
これがUI/UXで使われている没入感です。


どこが似ているの?

UIと映画の没入感について、一体どこが似ているのかと言うお話ですが、ポイントは2つあります。

1つ目のポイントは、どちらもユーザー(観客)に体験を提供している点。そしてその体験がユーザーにとって良いモノであればこそ好まれる点にあります。
この良いユーザー体験こそが没入感へと繋がっていきます。

良いユーザー体験とはどのような事なのか、ザックリ言うと「ストレスなく目的を達成できた」と言うことです。
UIで言えば、分かりやすい動線、デザインを用いたUI設計を行う事で、ユーザーは何にも邪魔されることなく目的を達成する事が出来ます。
映画で言えば、整合性の取れたストーリーや適切な環境があって初めて、ユーザーは映画を見ると言う目的を達成する事が出来ます。

2つ目のポイントは、UIも映画も基本が大事だと言う事です。
1つ目のポイントとも関わってきますが、分かりやすさや見やすさなどそもそもの部分が出来ていなければ、ユーザーに混乱や不快感を感じさせてしまいます。
混乱や不快感はユーザーにストレスを与え集中力を削いでしまいますので、没入感からは程遠くなってしまいます。
その為、完成度を高めたり作り手の事情を盛り込む前に、基本が押さえられているかしっかり注意する必要があります。


ポイント1:ユーザー体験の良し悪し

UIと映画のユーザー体験について、もう少し掘り下げてみたいと思います。

UIの場合

サイトを訪れるユーザーは「アレが見たい」「コレが買いたい」と何か目的があってその場を訪れています。
例えばサイトを訪れてすぐのファーストビューで、目当ての物を見たり購入することが出来るようにします。すると、ユーザーは一切のストレスなく目的が達成できますので、良い体験が出来たことになります。
上記は極端な例ですが、UIはこう言った観点からサービスを構築する様々な要素や導線を考慮して設計を行います。

目的を達成する為に必要な工程など避けて通れない部分が最適化されていないと、それはユーザーにとって大きなストレスになります。これは離脱や継続率の低下に繋がってしまいます。
分かり辛いUIもそうですが、宣伝用のモーダルウィンドウや過剰な広告表示もその1つです。

映画の場合

映画を見に来た観客の目的は、そのまんまですが「映画が見たい」です。(特に、映画館に足を運んで見る人はこの思いが強い傾向があります。)
最後まで集中して映画を見ることが出来れば、それは良い体験が出来た事になります。
映画に集中する為には、辻褄のあったシナリオや役者の演技に違和感がないことなど映画の内容はもちろん、映画の見せ方などの環境も大きく影響します。

UIと同じく、「映画を見る」と言う目的を達成する上で避けて通れない部分が最適化されていないと、それはユーザーにとって大きなストレスになります。
よく話題になるのが、吹替え版やアニメ映画でプロの声優以外を起用してしまうケースです。これはユーザー体験を無視した作り手側の都合の押し付けなので非常に悪手です。
声優以外の他業種の人間が声を当てる場合、残念ながらほとんど棒読みか違和感のある演技になっています。
「声」も大事な映画の一部ですので、これが適切でないと強い苦痛を感じ、映画に集中出来なくなってしまいます。

また、映画館であれば一緒の空間で見る他の観客にも影響されますよね。
上映中に何度も喋る人、妙なタイミングで大声で笑う人、咀嚼音、椅子を蹴ってくる人、ひじ掛けの争奪戦。これらも没入感を阻害する大きな原因の1つです。
多くの映画館では上映前に最低限のマナーなど禁止事項をアナウンスしています。
完全に防ぐことは難しいですがある程度の抑止にはなりますので、没入感を演出する為の対策として大切な事です。


ポイント2:UIと映画の基本

UIにも映画にも、わかりやすさや見やすさなど表現の基本があります。

UIの場合

ユーザーが目的を達成する際に迷わないようにしてあげるのがUIの基本です。
優先度の高い要素から配置する、遷移する要素は明確にする、ユーザーが目的を達成する為に不要な要素は消したり隠したりするなど、様々な方法があります。
こうすることでサービスを訪れたユーザーは何をすれば自分の目的が達成できるのか直感的に理解する事が出来ます。
誰が見ても分かる、と言うのは難しいことなのですが、一般に浸透している表現であれば多くの人が理解して自然にアクションを起こせます。
ハンバーガーメニューなどがそうです。見た目だけでは正直何が出来るのか分かりませんが、周知されている形と意味なので迷わず使うことが出来ます。
独自の設定やアクションを組み込んでしまうと、ユーザーが混乱してしまう可能性がありデメリットになってしまいます。

映画の場合

映画の基本ですが、映画作品としての完成度とは少し違うお話になります。私が気になったのは字幕の表現です。
映画の字幕と聞くと、多くの人が映像の下部に白色で小さく表示されている文字を想像すると思います。これが一般に周知されている字幕の基本です。
地名の説明や異なる言語を表現する際に左右に表示される場合もありますが、通常セリフは一貫して下部に表示されます。
海外のあるミュージカル映画を見ていた時、歌うシーンで字幕が上部に表示されたことがありました。しかも一貫性がなく、画面の上下でランダムに表示されたので非常に見辛かったです。
歌うシーンの演出としてそのアクションになっていたようで、これは良くないケースかと思います。
UIと同じく、独自のアクションを組み込んだ為に観客が混乱し、映画に集中出来なくなってしまいました。

オリジナリティも大事ですが、まずは基本を押さえることでユーザー(観客)の没入感に繋がります。


おわりに

いかがでしたでしょうか?
UIと映画と言う異なる分野でしたが、没入感と言う観点から見ると意外と似ているのではないでしょうか?
改めて考えてみると、ユーザーの目的をストレスなく達成させる為には基礎が大事である、と言う共通点がある事が分かりました。
作り手側の都合で完成度を高めるのではなく、ユーザーの目的に沿った作り込みを行うことで没入感を感じてもらう事が出来ます。
良いサービス作りを行う為に、ぜひ意識してみて下さいね。

それではまた!デジマースのコンでした。

パンくずリストとは~改めて考えてみる~

突然ですが、パンくずリスト(話し合いの場ではパンくずと略して言うときもありますね)と聞いたときに何を思い浮かべますか?
知らない人からしてみれば、食べ物のパンのくずを連想する方もいると思います。
ある意味間違いではないのですが、今回ここでは食べれない“パンくず”とはどんなものか改めて調べてみました!

*。゜・。ここでは全部を理解せずとも、デザイナーでなくとも
何となく分かるをベースに書いております。・。゜*

1.パンくずリストとは

まず最初に、パンくずリストとはインターネットのWEBサイトにて、ユーザーがWEBページのどの位置にいるかを視覚的に分かりやすいように、サイトTOP(上階層)から階層をたどった順にリスト化し、リンクを設置したリストのことを指します。
基本的には該当するページの上部に置かれることが多く見られます。

2.何故「パンくずリスト」と呼ばれるの?

童話「ヘンゼルとグレーテル」でヘンゼルとグレーテルが道に迷わない様にするために、通ってきた道にパンくずを置いて行ったエピソードに由来しているようです。
WEBサイトでも同様にユーザーがサイト内で迷子にならない様にするための道しるべとして、表示することからパンくずリストと呼ばれているのでしょう。

前置きのところで「知らない人からしてみれば、食べ物のパンのくずを連想する方もいると思います。ある意味間違いではないのですが~」と書きましたが、その理由がこちらでした。
呼び名、由来を知るまでは私も不思議で仕方ありませんでした。

3.パンくずの種類

パンくずリストはパンくずリスト。1つしかないと思っていたのですが、実はいくつか種類がありました。
ここでは使用頻度が割と高いとされる位置型と属性型を中心に書いていきます。

■位置型(ロケーションベース)

これが一番なじみ深いのではないでしょうか。
因みに上部にある「1.パンくずリストとは」の部分で紹介したものはこちらになります。
そのページがWEBサイト内のどの階層の位置かを示すもの。静的であり、最終的に辿り着くまでの経路が違っても同じページであればリストも同一なものになります。
ページ階層が多く必要とされるWEBサイトで使われることが多く、利便性も良いです。

例)商品購入サイト等

もう少しわかりやすく書くとこんな感じになります。

パンくずリストを見るとこのユーザーは、TOPからカテゴリ、雑貨、キャンドルと経緯を含め自分がどこにいるか一目瞭然です!
また、違う商品を見たいと思った場合パンくずリストの「カテゴリ」をクリック(タップ)するだけで戻れます。

簡単に移動出来て便利です。
ユーザーメリットも!

★ユーザーが自分のいる地点を把握できるため迷子にならない。
★自分の現時点の場所がどんなカテゴリに分類されているかがすぐにわかる。
★パンくずリストはリンクになっているため、来た道をすぐに戻ることが可能。

このような、パンくずリストですが皆様がご存知のアマゾンでも適用されています。適用されているのはPC版になり、欲しい商品のページを開いてロゴの下を見てみるとひっそりと商品の邪魔にならない様にパンくずリストが表示されています。
ですが、スマートフォンやアプリ版のページにはパンくずリストが見当たりませんでした。
この場合、ふと考えつくのが「スマートフォンなどの小さな画面では、パンくずリストを設置することで限られた訴求領域を使ってしまう」「パンくずリストが大きく表示されることはそうそうないと考えるとテキストリンクが小さくタップし辛い可能性がある」「ファーストビューに(ここでは)商品を優先している」等でした。

本来はユーザーへWEBサイト内のナビゲーションとして働くパンくずリストが本領を発揮できずに中途半端になってしまってはもったいないですもんね。

また、必ずしもスマートフォンには向いていないということではございません!適用しているWEBサイトも沢山あります。
サイトの方向性やサイトのデザインレイアウトなどに少なからず左右されるのではないでしょうか。

■属性型(属性ベース)

そのページがどんなカテゴリー、属性で分類されているかを示し、自分のいる位置を表示する位置型とは異なりページコンテンツの※メタデータが表示されます。
また、ユーザーの操作によって都度変化し、フィルターの役割を担うため複数の選択肢を選んで表示されるWEBサイトの傾向に向いています。

※メタデータ…データ本体そのものではなく、そのデータ本体に関する情報を記したデータ。
例えば画像に付属する、更新日などを指す。

例えばアマゾンのPC版では商品一覧ページに行くとロゴ下左側に選択した商品の種類に特化したフィルタ機能があり、価格帯など自由に項目を選択できるところがあると思います。

属性型と位置型がかけ合わさってより分かりやすい表現に。

さらに追加で検索フィルターをかけてみますと……


余談ですが「価格1500-5000円」を追加すると上部のパンくずは以下のようになります。

「ホーム&キッチン:家具:
リビングルーム家具:ピンクまたはブルー:1500-5000円

自分で選んだ項目について、居場所がすぐ反映されるととても分かりやすいですね。

■履歴型(パスベース)

そのページにどのような経路で辿り着いたのかを示します。動的であり、同じページでも辿り着くまでの経路が異なればリストも異なります。いわゆる自分が閲覧してきたページを表示するものだそう。
また、ブラウザの戻る(←)ボタン、履歴機能と同じ役割なため、最近では機能が重複してしまうため、見かけることが少ないようです。ユーザーへのナビゲーション機能として考えた際、利便性は良くなさそうです。

4.最後に

パンくずリストは使いようによってはとても分かりやすい位置情報です。
人間、自分の居場所が分かるほど安心なことはございません(と言い切ります!)
例えばリアルでも初めて旅行に来た土地で迷子になるなんてちょっと恐ろしいですよね。
もしも行くところどころに駅前にあるような地図や看板があれば、安心です。

ユーザーにストレスを与えることなくサイト巡りを楽しんでもらい、なおかつ運営側もページをしっかり把握することができたらより良いサービス向上につながる可能性もあるかもしれません。

次回もデザイナーでなくとも何となく分かるをベースにお伝えしていければと思います。それでは、またお会いしましょう!
wrote:スガ

ハンバーガーメニューについて考えてみる

今回はハンバーガーメニューについて考えてみたいと思います。
なんて美味しそうな内容なんでしょう!お腹がすいてきました!
…と言いたいところではございますがジャンクフードのではございません笑

WEBサイト、アプリを使用していればほとんどの方が三本線のこのマーク「≡」を見たことがあるのではないでしょうか。
今回はスマホを使用している際の「≡」について考えていきたいと思います。

*。゜・。ここでは全部を理解せずとも、デザイナーでなくとも
何となく分かるをベースに書いております。・。゜*

最初に

ハンバーガーメニュー又はハンバーガ―アイコン(以下ここではハンバーガーメニュー)とは主に複数のメニュー等を表示させる目的でスマートフォンのアプリなどで広く使用されています。
横線三本が並んだ記号「≡」がハンバーガ―っぽく見えることからそう呼ばれているようですが、日本ではあまりなじみがないかもしれません。
私なんかもメニューアイコン等と呼んでしまいます。

特徴としてはWEBサイト、アプリの上部の左右どちらかに存在することがほとんどです。
WEBサイト、アプリによっては以下のように表現するところもあり、必ずこれではないといけないというわけではなさそうです。


ハンバーガーメニュー

知っていれば、慣れてしまえば「≡」マークがハンバーガーメニューというメニューアイコンであると理解し自然に使用することが出来ます。
ハンバーガーメニューに馴染みのないユーザー、はたまたスマートフォンに慣れていないユーザー等にとっては大きなはじめの一歩となってしまいそうです。

たまたま押して「これはメニューが入っているのか」と気づくことはあるかもしれませんが、思っている以上にハードルは高く感じてしまいます。
ですがそんな中、今現在ではハンバーガーメニューの認知も上がっているのは確か。様々なところで見かけたりしますよね。
もし見たことがない、どれかわからない場合はキャリアのTOPを見て頂くと上部の方にあるかと思います。

↓一度は目を通している可能性が高いところですね

メリット、デメリット

ユーザー目線、デザイナー目線で見たときのメリット、デメリットを少し考えてみました。

《 ユ ー ザ ー 目 線 》

メリット

・どのWEBサイトやアプリでも表現方法はほぼ似通っているので、一度覚えてしまえばどこでも感覚的に使用することが出来る。
・上部に常設されていることや、上部を引き出すと出てくる事が多いため必要時に瞬時に使用しやすい。

デメリット

・初見だとメニューアイコンと認識するのに時間がかかる。
・ハンバーガーメニューの中身によっては余計に迷子になる可能性がある。
・開いてみるまで(タップ)中身が分からない。

《 デ ザ イ ナ ー 目 線 》

メリット

・ハンバーガーメニューを取り入れることで、小さなスマートフォン
の画面領域からUIデザイン領域を多く確保することが出来る。
・コンテンツ内容が多い際に使用するととても便利。

例えば一例ですが…

デメリット

・ハンバーガーメニューに頼りすぎてしまうことがある。
→目で見える部分のUIデザイン面を重視しすぎて、ハンバーガーメニューの中にたくさんのコンテンツを入れてしまい、結局はハンバーガーメニューの中でコンテンツを探させてしまう。
・使い方によっては味気ない中身のないデザインに陥ることも…

サイトを運営する側はサイトの傾向をしっかり把握したうえでハンバーガーメニューを使用することがユーザーを困惑させない一歩であると思います。

買い物が出来るサイトであれば、「カート」はほぼ必須といえます。
もしもハンバーガーメニューの中に入っていたら、仮にほとんどの人が気づくと考えたとしても、わざわざメニューを開くのは面倒くさいと感じさせてしまう可能性があります。
この場合、サイトの傾向である買い物をスムーズにしてもらうためにTOPにわかりやすく表示されていた方がユーザーには親切です。

「ログイン」「ログアウト」をさせるサイトでは基本的にはTOPに置かれるものが多く見受けられますが、SNSなどで常にログイン状態のままにしておくことが多いものは「ログアウト」がハンバーガーメニューの中に入っていることもあります。

最近の傾向では

ハンバーガーメニューを三本線で表さないところも多くみられます。
縦型の三点リーダーや二本線のもの、またメニューをタップした際にナビゲーションの意味合いとしてメニューマークが×マークに変化するもの等々、動くものも増えています。

AndroidとIOSで各々の傾向があると思いますが、WEBのシステム領域などで扱われるハンバーガーメニューで主に三本線以外のものがみられる印象があります。

またハンバーガーメニューなど、日に日にユーザーの感覚的な扱いに任せてしまっている点が垣間見えるため、いかに自然に扱ってもらえるかUI面での見せ方が今以上に大事になってくるのではないでしょうか。
便利なのに、扱えなければもったいないですからね。

まとめ8
  • 「≡」はハンバーガーメニューという
    (アイコンなどとも呼ばれたりします)

  • ハンバーガーメニューのほどんどはWEBサイトやアプリの上部に置かれる

  • 初見さんには分かりづらい表現である

  • タップするまで中身は分からない

  • 一度理解すれば感覚的に使用できる

  • ハンバーガーメニューに頼りすぎるデザインだと、ハンバーガーメニュー内でコンテンツを探す手間が出てくる
    (迷子になることも)

  • ハンバーガーメニューをうまく使うことで、UIデザイン領域を多く確保出来るため、見せ方の幅が広がる

  • サイトの傾向を把握したうえでの使用が望ましい

最後に

このハンバーガーメニュー。賛否両論が挙げられているのをよく見かけます。使いづらい、時代遅れ、便利等々…
自己見解ですが使い方によっては様まだまだ多くの可能性を秘めていると考えています。
便利なハンバーガーメニューですがサイトのUIとの匙加減が大事ですね。

次回もデザイナーでなくとも何となく分かるをベースにお伝えしていければと思います。
それでは、またお会いしましょう!

タブとセグメンテッドコントロールの違いとユーザビリティー

モバイルwebページは画面が小さいため、フィーチャーフォン時代からUI部品の「タブ」を使い、ページ内の一部に部分的な表示切替を行い多くの情報を載せてきました。

今回は、そんな「タブ」と、機能の近い「セグメンテッドコントロール(Segmented Control)」の違いを紹介し、
後半にはタブ表現のバリエーションとユーザビリティーにふれ、最後にコピペして使えるソースを紹介します。


タブとは

ページ内の一部を部分的な表示切替を行うことで、優先度の低い情報も限られたスペースで表示できる便利な機能です。

ポイントとして

  • タブの数は3~4つ程度 ※各項目名の文字数の関係で。
  • デフォルトは一番左側がアクティブ状態にする
  • 優先度の高い項目を一番左に配置 ※閉じられたタブ(特に右端)は開かれることが少ない
  • 扱う情報をカテゴリ/ジャンルで切り替える(コンテンツ向き)
  • タブ毎の情報が重複しない

以上の注意が必要です。
置かれる情報は「題名」の子要素(並列なもの)を表示切替することが望ましいです。

例.



セグメンテッドコントロール
(Segmented Control)とは

iOSでは標準的なUIコンポーネントです。

「タブ」に似ていますが、テーマ全体に対してセグメントを分けて表示する機能です。

ポイントとして、

  • 項目数は3~4つ程度が望ましい ※2つだけの場合はどちらがアクティブかわかりづらい
  • デフォルトはタブと同じく一番左側がアクティブ状態にする
  • 一つのデータをセグメントにより分けて表示(情報/データ 向き)
  • 各セグメント間の情報は分け方により重複する

以上の注意が必要です。

置かれる情報は「主情報」の内容をセグメントにより表示切替することが望ましいです。

例.



タブとセグメンテッドコントロールそれぞれついて説明しましたが、
ポイントを踏まえて適切に使い分けていきましょう。


バリエーションの紹介

最後にタブのバリエーションを紹介します。

見比べると分かりますが、UI部品のデザインによって利用者はそれが「タブ」なのか「セグメンテッドコントロール」なのか、その他似た表現の「グローバルメニュー」なのか判断が難しいため、
デザインについてはユーザビリティーを考慮する必要があります。

「流行表現」にはそういった問題が付いてくるため、
見慣れた「定番表現」の方が利用者にとっては瞬間的にわかりやすいのではないでしょうか。

参考程度に定番表現タブのソースを掲載します。

定番タブのソースコード
(動かせます↓)

<div id="tabcontrol"><a class ="tab1"  href="#tabpage1" >HTML</a><a class ="tab1"  href="#tabpage2" >CSS</a><a class ="tab1"  href="#tabpage3" >JavaScript</a></div>

<div id="tabbody">
	<div id="tabpage1">タブ1内容</div>
	<div id="tabpage2">タブ2内容タブ2内容</div>
	<div id="tabpage3">タブ3内容タブ3内容タブ3内容</div>
	</div>	

@charset "utf-8";
/* CSS Document */

body {
	font-family: "メイリオ",Meiryo,"ヒラギノ角ゴ Pro W3",Hiragino Kaku Gothic Pro,"MS Pゴシック",sans-serif;
}

	/* ▼タブ(カスタマイズ中) */

#tabcontrol {
	width: 100%;
	height: auto;
	border: 0.0px solid #FF0004;
	margin: 0px 0% 0% 0%;/* インラインブロック化 */
	border-width: 0px 0px 0px 0px;    /* 下以外の枠線を引く */
	position: relative;               /* JavaScriptでz-indexを調整するために必要 */
	overflow: hidden;
}

a.tab1 {
	width: 31.3%;
	border-top:solid 2px #656766;
	border-bottom:solid 1px #656766;
	border-left:solid 2px #656766;
	border-right:solid 2px #656766;
	font-size: 15px; font-size: 1.5rem;
	text-align:center;
	text-decoration: none ;/*リンク文字の下線を取る*/
	margin: 0% 0% 0% 0.8%;
	padding: 7px 0  7px 0;           /* 内側の余白 */
	border-radius: 0.75em 0.75em 0 0; /* 枠線の左上角と右上角だけを丸く */

	float: left
}

div.tabcontrol_btn1_a_tag_on {
	color: #656766;
	text-decoration: none ;/*リンク文字の下線を取る*/
	
	width: 31.3%;
	border-top:solid 2px #656766;
	border-bottom:solid 2px #ffffff;
	border-left:solid 2px #656766;
	border-right:solid 2px #656766;
	text-align:center;
	margin: 0% 0% 0% 0.8%;
	padding: 1.75% 0  1.75% 0%;            /* 内側の余白 */
	border-radius: 0.75em 0.75em 0 0; /* 枠線の左上角と右上角だけを丸く */
	background-color:#ffffff;
	float: left
}

div.tabcontrol_btn1_a_tag_off {
	color: #ffffff;
	text-decoration: none ;/*リンク文字の下線を取る*/
	
	width: 31.3%;
	border: solid #656766;
	border-width: 2px 2px 1px 2px;    /* 下以外の枠線を引く */
	text-align:center;
	margin: 0% 0.75% 0% 0.75%;
	padding: 1.75% 0  1.75% 0%;            /* 内側の余白 */
	border-radius: 0.75em 0.75em 0 0; /* 枠線の左上角と右上角だけを丸く */
	background-color:#656766;
	float: left
}

/* ▼タブの中身(カスタマイズ中)  */

#tabbody div{
	width: auto;
	border-top:solid 2px #656766;
	border-bottom:solid 2px #656766;
	border-left:solid 0px #656766;
	border-right:solid 0px #656766;
	margin: -2px auto 5% auto;
	padding: 3.75% 1% 3.75% 1%;            /* 内側の余白量 */
	background-color: #FFFFFF; /* 背景色 */

}

#tabbody1 div{
	width: auto;
	border-top:solid 2px #656766;
	border-bottom:solid 2px #656766;
	border-left:solid 0px #656766;
	border-right:solid 0px #656766;
	margin: -2px auto 5% auto;
	padding: 3.75% 1% 3.75% 1%;            /* 内側の余白量 */
	background-color: #FFFFFF; /* 背景色 */

}

#tabbody2 div{
	width: auto;
	border-top:solid 2px #656766;
	border-bottom:solid 2px #656766;
	border-left:solid 0px #656766;
	border-right:solid 0px #656766;
	margin: -2px auto 5% auto;
	padding: 3.75% 1% 3.75% 1%;            /* 内側の余白量 */
	background-color: #FFFFFF; /* 背景色 */

}

#tabbody3 div{
	width: auto;
	border-top:solid 2px #656766;
	border-bottom:solid 2px #656766;
	border-left:solid 0px #656766;
	border-right:solid 0px #656766;
	margin: -2px auto 5% auto;
	padding: 3.75% 1% 3.75% 1%;            /* 内側の余白量 */
	background-color: #FFFFFF; /* 背景色 */

}

/* ▼タブの配色 */
#tabcontrol a:nth-child(1), { color: #ffffdd; }/* 1つ目のタブとその中身用の配色 */
#tabcontrol a:nth-child(2), { color: #ddffdd; }/* 2つ目のタブとその中身用の配色 */
#tabcontrol a:nth-child(3), { color: #ddddff; }/* 3つ目のタブとその中身用の配色 */

function aa() {
// ---------------------------
// ▼A:対象要素を得る
// ---------------------------
var tabs = document.getElementById('tabcontrol').getElementsByTagName('a');
var pages = document.getElementById('tabbody').getElementsByTagName('div');
	
// ---------------------------
// ▼B:タブの切り替え処理
// ---------------------------
function changeTab() {
   // ▼B-1. href属性値から対象のid名を抜き出す
   var targetid = this.href.substring(this.href.indexOf('#')+1,this.href.length);

   // ▼B-2. 指定のタブページだけを表示する
	for(var i=0; i<pages.length; i++) {
		if( pages[i].id != targetid ) {
			pages[i].style.display = "none";
		}
		else {
			pages[i].style.display = "block";
		}
	}

   // ▼B-3. クリックされたタブを前面に表示する
	for(var i=0; i<tabs.length; i++) {
		tabs[i].setAttribute('style','color:#ffffff;border-bottom:solid 2px #656766;background-color:#656766;');
	}
	this.setAttribute('style','color:#656766;border-bottom:solid 2px #ffffff;background-color:#ffffff;');

   // ▼B-4. ページ遷移しないようにfalseを返す
	return false;
}

// ---------------------------
// ▼C:すべてのタブに対して、クリック時にchangeTab関数が実行されるよう指定する
// ---------------------------
	for(var i=0; i<tabs.length; i++) {
		tabs[i].onclick = changeTab;
	}

// ---------------------------
// ▼D:最初は先頭のタブを選択しておく
// ---------------------------
	tabs[0].onclick();
}

※JavaScript等、こちらのページ記事を参考にしてカスタマイズしてみました。
「ページ移動せずに内容を変更するタブ機能の作り方」

ご意見あればお願いします。

次回も情報設計に関係した話題をお届け致します。
デジマースのネモトでした。

UI/UXについて考える【女性向け恋愛シミュレーションゲーム編】

こんにちは!ユイPです。もうすぐ梅雨ですね。
私は傘を持ち歩くのを忘れがちで、夕方から雨予報なのに傘を持ってない…なんて事がたまにあります。
そんな時いつも、(ここで私に「この傘よかったら使ってください」なんて言ってくれる素敵な男性が現れないかな~)という妄想をします。
しかし現実にそんな恋愛ゲームのイベントみたいな事起こるはずもなく…大抵小走りで帰るので家に着く頃にはびしょ濡れです。

前振りが長くなってしまいましたが、これも伏線…今回のテーマは、
UI/UXについて考える【女性向け恋愛シミュレーションゲーム編】です。
恋愛シミュレーションゲーム(以下・乙女ゲーム)のUIにどんなものがあるのか、それぞれどんな役割をしていてどんな体験を得られるのか…分析してみたいと思います!
ちなみに冒頭の妄想からわかる通り、ユイPは普段から乙女ゲームをそこそこに嗜んでいます。


♥今回は”家庭用ゲーム機用のゲームのUI”として考えていきます。
♥”ゲームのプレイ画面”とそこに関わる機能のUIに触れていきます。
♥ゲームの形式はノベル形式のもので考えています。


基本のプレイ画面

まず、乙女ゲームの基本的なプレイ画面を確認してみましょう。

いや本当にこういうイベント現実に起きないんですか?
私の記憶と経験と乙女ゲームのサイトを巡って導き出した最適な解がこちらです。もちろんゲームによって差異はあります。
これを基本として、それぞれのパーツが何の役割を果たしているか書きだしてみます。

①人物名
台詞を話している人物の名前が表示される。主人公が喋っている時は主人公名が表示される。
②メッセージウィンドウ
台詞が表示される。台詞の表示速度は基本的に変更可能。ユーザーの好みで変える事が出来る。
ゲームによってはここの不透明度を調整出来るものもある。キャラクターを透かすか文字の読みやすさを優先するかはお好みで。
③台詞送りマーク
台詞が全文表示されると表示される。「台詞を次に送れるよ」という合図。
チカチカするアニメーションがついている事が多い。
④自動台詞送りマーク
台詞が自動送り(操作しなくても勝手に進んでいくモード)になっている時だけ表示される。自動に設定していない場合は出てこない。
画面右上に表示が出るゲームが多かった。ただ右上に日付など他の要素が表示されているゲームの場合、テキストウィンドウの横など別の場所に表示されることも。

ゲームをプレイしている際、常に画面上に表示されている最低限のパーツはこの4つが多いです。
ゲームによっては日付だったり、主人公の顔も表示されていたりするものもあります。世界観にあわせてゲームによって色々変わってきますが、あくまで「男性キャラクター」がメインなのでそれを邪魔するほど目立つ要素は配置されていないように思います。

また、これらのパーツはボタン1つで簡単に表示/非表示が出来るようになっています。(後ほど詳しく説明)

プレイ中に呼び出せる機能

常に表示されているパーツ以外にも、ゲームをプレイする際に必要な機能は他にもありますよね。セーブやロード、設定などです。

これらのメニューや機能は普段は画面上に表示されていない事が多く、それぞれ対応したボタンを押す事で呼び出す事が出来ます。
(※「MENU」が常に表示されていたり、各機能がメッセージウィンドウの下に表示されている場合などもあり)

乙女ゲームでプレイ中に呼び出す事の出来る機能は、

①「セーブ/ロード」
その名の通りセーブやロード。タイトル画面に戻るのも大体ここから。
②「クイックセーブ/クイックロード」
ボタン1つ(もしくは2つ)でセーブやロードが出来る。
③「オートON/OFF」
上記でも説明した台詞の自動再生のON/OFFが切り替えられる。
④「スキップ」
既読の部分をスキップする事が出来る。速度は自由に変えられる。
周回する事が多い乙女ゲームにおいて大事な機能。もちろん未読でもスキップは出来る。
⑤「履歴(バックログ)」
これまでの台詞の履歴を見る事が出来る。ボイス再生が出来るものが多い。
⑥「メッセージウィンドウなどの表示/非表示」
一瞬で画面上のキャラクター以外のパーツの表示/非表示が切り替えられる。
キャラクターの絵の隠れていた部分や、スチルと呼ばれる1枚絵をじっくり見るための機能です。
⑦「キャラクター/ステータス」
キャラクターのプロフィールや好感度、イベントの発生条件などを見る事が出来る。
⑧「用語解説」
ゲーム中に通常した用語の解説。難しい世界観や特殊な設定のあるゲームには必須。
⑨「タイトルに戻る」
タイトル画面に戻ることが出来ます。
⑩「オプション(設定)」
台詞の速度やキャラクターボイスの音量調整など、ゲームの各種設定が出来る。

…など、このような機能が多いです。

これがどのように各種ボタンと連動しているかというと、
例えばとあるゲームでの、ボタンと機能の関係はこのようになっていました。
※S社の某携帯ゲーム機です。

「クイックセーブ」や「履歴」「スキップ」「表示/非表示」といった即時に行いたいものはボタン1つで出来るようになっていました。
このゲーム以外にも基本ワンタッチで行いたい操作はボタン1つで呼び出せるものがほとんどでした。ストレスフリー。
セーブやロード、キャラクターのページなど画面自体が切り替わるものはメニューを呼び出して開くようになっています。

選択肢や好感度などのUI

ノベル形式なので読み進めていく事がメインですが、「ゲーム」ですのでただただイケメンとのストーリーを読んでいくだけでは話は何も発展していきません。
途中で「選択肢」というものが登場します。この選択によってルート分岐というものが行われ、ハッピーエンドかノーマルエンドかバッドエンドか…つまりは結末がわかれていきます。

選択肢は乙女ゲームにおいて運命を左右するものといっても過言ではありません。なので、どの選択肢を今自分が選択しようとしているか、見てわかりやすいように工夫されている事が多いです。(色が違う、カーソルが表示される…など)
ちなみにこの画像の選択肢の場合、真ん中の選択肢が大正解です。1番上は普通、1番下は論外ですね。

そして正解(1番好感度があがるもの)を選んだ場合、その証拠としてエフェクトが出る事が多いです。

正解が可視化される事で「よかった~合ってた~!」という安心を得る事が出来ますね。逆に出なかったり、好感度が下がるエフェクトが出ると焦ります。切羽詰っているとクイックロードで選択肢のちょっと前に戻ったりします。シビアな世界なので。
また、正解がわかる事によって「このキャラはこういう返しをされるのが好きなんだな?」と、なんとなく性格が読めてくるのでその後の選択肢も選びやすくなります。

その他、気になったゲームの工夫

これは私が今までプレイした中でユーザーに配慮されているな…と思った要素の一つなのですが、
とあるゲームで「主人公(つまりプレイヤー)」の顔の描写をON/OFFに出来るという機能がありました。
恋愛シミュレーションゲームにおいて、主人公を自分と重ねて実際に自分がキャラクターと恋愛している気分になるか、はたまた第三者の視点で主人公とキャラクターの恋愛模様を楽しむかプレイスタイルは人それぞれです。でも前者だった場合、あまりにも主人公の個性が前面に出ているとちょっと没入出来ないよ…って人がいるかもしれません。
そこで「イベントCG(1枚絵で表示されるイラストのこと)」で表示される主人公の表情をOFFにする事が出来る!という機能のついているゲームがあり、没入系プレイヤーへの配慮がされていて手が込んでいるなあと思いました。だって表情ありとなしの2パターン用意されているわけですからね…。
イベントCGの顔は消せなくとも、メッセージウィンドウ横に表示される主人公の顔をOFFに出来るゲームも多いですね。

まとめ UIが生み出す世界観

ノベル形式のゲームでは、メッセージウィンドウなどの要素はゲームをプレイしている間、常に目に入ってくるものになります。
メインはキャラクターや背景などのグラフィックかもしれませんが、UIもゲームの世界観の一部を表現しているといっても過言ではありません。私はどんなにキャラクターや背景の絵が綺麗でも、それをとりまくUIに手が込んでいなかったらなんだかテンション下がってしまいます…。
例えば幕末が舞台で新撰組隊士と戦争の中恋愛していくシリアスなお話なのに、UIがピンクでキラキラしたメタリック!だとおかしいですよね。和風のお話ならUIも和風なテクスチャを使用したり、使うフォントもゴシック体よりは明朝体とかだと世界観を壊さずにゲームをプレイする上でしっくりきます。
もちろんこれは恋愛シミュレーションゲームに限った話ではなくどんなゲームのUIにも言える事ですが、常に視界に入ってくるノベル形式の恋愛ゲームでは特に大事と言えるのではないでしょうか。

乙女ゲームがUIによってどんな世界観を生み出されているか、どれほど手が込んでいるのか、気になった方は是非乙女ゲームブランドさんのサイトを見てみてください。


以上、UI/UXについて考える【女性向け恋愛シミュレーションゲーム編】ユイPがお送りいたしました。
この記事で例にあげたゲームが何かわかった貴方はユイPのお仲間です♥

★ユイPおすすめ乙女ゲームをツイートするかも?
デジマースブログ公式Twitter

エレベーターの開閉ボタンについて

身の回りのUI第2弾です。

エレベーターの「開ける・閉める」ボタンが間違えやすいという話を昔からよく聞きますよね?未だにこの話を聞くということは、車のワイパーが未だに昔と変わらず棒が左右に動き水をよけている事と同じで、もはや解決策がないのかもしれません…

ということで、今回はエレベーターの開閉ボタンが間違えやすい理由についてあれやこれやと考えていきたいと思います。

※本文中に出てくる「かご」とはエレベーターの人が乗る箱状の部分の事です。


では、突然ですが問題です。
どちらがエレベーターの「あける」ボタンでしょうか?

左ですね。

簡単に答えることができたはずです。

「あれ?いつもは迷うけど、今回は迷わなかったな」と思った方もいらっしゃるのではないでしょうか?

迷わなかった理由は“状況が違う”からです。

エレベーターで「開ける/閉める」の二択を迫られるときは「慌てて人が駆け込んできた」「早く閉めたい」など慌てている状態が多いですが、今回は違いますよね?自宅やオフィスで、ゆっくりしながら落ち着いて答えましたよね?(多分ですが…)

人は焦るとパフォーマンスが低下し、ミスを起こします。焦るという状況が発生しやすい環境も改善する必要があるため、開閉ボタンの問題をアイコンのデザインだけで解決するのは難しいかもしれません。ですが今回はアイコンのデザインでミスを軽減しようという考えのもと話を進めます。

なぜ間違うのかを考える

1.ひらくボタンを押すまでの手順の問題

ドアが閉じるまでは4秒前後です。その4秒前後で「ひらくボタン」を見つけて押す必要があります。ドアが閉まりかけの時に人が乗ろうとしてきた場合は4秒も確保できません。
このことから分かるように、アイコンデザインの良し悪し以前に押すまでの時間が短いという問題があります。
エレベーターのボタンは、どちらが「開く」か「閉じるか」に迷うよりも先に“探す”という行為を先に行う必要があります。ですので、開閉ボタンのデザインは「限られた時間でいかに早く見つける事ができるか」が重要になってきます。

※ちなみに…車椅子用ボタンを押すと閉まる時間が10秒ほどになります。また、エレベーター内のミラーは、車椅子の方がバックで降りるために設置されています。(かごの中で回転するのは難しいためです)

2.アイコンのデザインの問題

エレベーターの開閉アイコンは同じようなデザインのものが多いのですが、規格により統一されているわけではないので、アイコンを記憶しても意味はありません。統一してくれればいいんですけどね…。
開閉ボタンのアイコンは、迷わず行動に移せるほど分かりやすく、誰が見ても同じ意味を想像できる形が理想的です。そこを踏まえた上で現在頻繁に見かけるアイコンについて考えると、完全なものではないように思えますのでその理由について説明いたします。

頻繁に見かけるアイコンのデザインがわかりにくい理由

こちらのアイコンはよく見かけますが、パッと見た時に、どちらなのだろうかと迷い、結局補足の文字に頼ることが多いので、なぜ間違えやすいのかについて考えてみたいと思います。

1.ひらいている様子が伝わりにくい
「ひらく」も「とじる」も中心に矢印が寄せてあり、どちらも閉じていると言われれば閉じているように見えます。

2.ドアなのかが分からない
矢印のみだと、何がどのように動くのかが分かりにくいです。シンプルですがパッと見た時の情報が少ないです。

3.三角形だと矢印として伝わりにくい
人によっては矢印という意味よりも先に三角形ととらえる可能性があります。情報量を減らすという意味では成功していますが、「矢印」「三角」のどちらにも見えるとういあいまいな状態は、ナビゲーション目的のデザインにおいては避けるべきです。

以上のことからアイコンは「“何がどう動くのか”あいまいな表現を避けてハッキリと伝える」ことが重要となることが分かりました。


今回はボタンの開閉が間違えやすい理由についてあれやこれやと考察してみましたが、「限られた時間でいかに早く見つける事ができるか」「“何がどう動くのか”あいまいな表現を避けてハッキリと伝える」ことが重要なのではということが見えてきました。
ほとんどのエレベーターのボタンは「左がひらくボタン」です。また、色が付いているならば「色がついているほうがひらく」です。もちろん全てのエレベーターにあてはまるわけでは無いのですが、ほとんどがこのようになっています。
このような情報をユーザーが予め持っていればいいのですが、当然そうはいきません。そもそもUIデザインではユーザーの知識や経験を頼りに設計することはあってはならないことです。ユーザーは何も知らないし、間違うことを前提に設計する事が基本です。
少し話がそれましたが、今後もエレベーターのボタンに関して気になることがあれば記事にしたいと思います。
それではまた次回

(はら)

スマホ画面レイアウトのガイドライン/テンプレート

社内のスマートフォン(以下スマホ)向けのデザインガイドラインから、画面レイアウトデザインに絞って紹介します。


1. ガイドライン化の目的

2. 画面デザインの基本方針

3. HTMLで重要な「viewport」とは?

4. デザインしやすいフォントサイズ土台設定

5. フォントサイズパターンのガイドライン

6. 行間の設定

7. 左右の余白

8. 最後に「高さ」の余白設定


ガイドライン化の目的


ガイドライン化によるメリットを重視しない場合は意味を持ちませんが、テンプレートとして活用することで、サービスの立ち上げを短縮出来ます。

ポイントとして以下の3つでしょうか。

1. ブランディング
担当者の価値観に左右されない統一されたルールと表現


2. 効率化
サービスの立ち上げや運用コスト効率化をはかるため見せ方を統一


3. 精度の向上
都度ガイドラインの改修行い、精度の高いデザインに更新


画面デザインの基本方針


時間をかけてテクノロジーを導入し手の込んだ表層デザインにしても、ユーザーにはメリットがなく、自己満足で終わることがあります。

そういった傾向を回避するための方針が下記です。

1. シンプルに
2. ユーザー目線で
3. 新技術は追わない
4. 第三者チェック
5. 訴求は2~3秒で理解させる
6. アーティスティックな表層デザインは使わない
7. 明確な目的をページ毎に設定

ユーザーの目的達成に必要ではない要素は提供側のエゴになりますので、バッサリと割愛の判断して先に進むことが大事です。


HTMLで重要な「viewport」とは?


まずはスマホで表示されるweb画面の設定によりページの表示範囲や最適化に影響がある土台設定を行います。

ヘッダー領域の「Meta」内に下記「viewport」設定ソースを記述します。

******************Viewportソース_1******************
※ユーザーによるページのズーム不可
(アプリ的な固定画面を再現する場合はこちら)↓
<meta name=”viewport” content=”width=device-width,user-scalable=no”>
******************Viewportソース_2******************
※ユーザーによるページのズーム可
(文字、画像のユーザビリティー重視の場合はこちら)↓
<meta name=”viewport” content=”width=devicewidth,minimum-scale=1.0″>
*******************************************************

「viewport」とは、仮想的なweb表示領域を設定する機能で、
何も設定しない場合、

・iPhoneの場合の初期値は横幅980px
・Androidの場合の初期値は横幅800px

です。

スマホの物理的なティスプレイのリアルな解像度ではなく、
ディスプレイ内で表示される「ブラウザアプリケーション」などの仮想的Web画面表示領域/解像度のことです。

それでは「viewport」の設定による端末画面での見え方の紹介です↓


以上の設定による見え方の違いは理解できましたでしょうか。

スマホの場合は

“width=device-width”

の設定で、各デバイス側で適切にフィット表示してくれますので、設定はまずはじめに行いましょう。

ページ表示の土台が固定されたので次は「フォントサイズの設定」です。


デザインしやすいフォントサイズ土台設定


サービスで扱うフォントの大きさの設定をガイドライン化します。

基準点を統一必要があるため、HTMLタグの中で全体に影響がある「HTML」タグに、フォントサイズの基準設定を行います。

HTMLファイルとは別にCSS(スタイルシート)ファイルを設け、その中に以下の記述をします。

******************** CSSの記述例 ********************
html {
font-size:62.5%; /*10px基準*/
}


p.XXX {
font-size: 10px; font-size: 1.0rem; /*最小*/
}

*******************************************************

この設定を行うことで「rem」のフォント設定時に

1.0rem → 10px

という想定と扱いがしやすい明確な10px基準での大きさの設定がされ、

グラフィックデザイナーが「画面イメージ」をIllustratorやPhotoShopで作成する際に、
ピクセル数単位でフォントサイズの作業が進められます。
それによりコーダーとの組込み時の数値の乖離が少なくなるので有益です。


フォントサイズパターンのガイドライン


フォントサイズが10px単位で扱えるようになったので、ページ内で使用する用途別文字サイズを6種類に絞って設定してしまいます。

これにより都度フォントサイズの設定に時間を取られることがなくなり、各項目ごとに決められたフォントサイズを割り当てることが出来るようになりました。

丁度良い大きさのメリハリをつけた6サイズが下記となります↓

実際のフォントの大きさの違い具合が確認出来るでしょうか。

見出しは大きく、
通常説明文は程良く、
利用者の便益がないレギュレーション上必要な表記文などは必要最低限に小さく設定してます。

フォントサイズはガイドラインとして設定はしてますが、幼児やシルバー世代などにターゲットする場合は見やすくい大きさのルール設定が行われる必要はあります。


行間の設定


行間については表示されるブラウザのデフォルトCSSなど端末依存でのブレが発生しますが、

文字サイズの1.4倍以上~1.7倍まで空ける(推奨)

で設定されていればテキストが読みやすい間隔が確保でき、それ以下になると詰まった読みにくい文章になってしまいます。

******************** CSSの記述例 ********************
body {
line-height: 1.4;  /*文字行間設定*/
}

*******************************************************


左右の余白


左右画面いっぱいまで文字が置かれていると文章体が把握しづらいく読みにくいため、適度な余白が必要です。

ガイドラインでは表示幅全体を100%とした場合の設定を行うことで端末依存に対応できます。

テキストエリアの両サイドに、表示横幅の5%程度を左右にそれぞれ設定。


******************** CSSの記述例1********************
p.XXX {
margin:0 5% 0 5%; /*テキスト横空白設定*/
}

******************** CSSの記述例2********************
p.XXX {
width:90%; /*テキスト横エリア横サイズ*/
margin:0 auto 0 auto; /*エリアのセンター置き*/
}

*******************************************************
以上がフォントサイズまわりの設定となります。


最後に「高さ」の余白設定


ページレイアウトガイドラインの最後の設定は、テキストや画像などの要素間余白の高さです。

***************CSSの記述例_ソース1***************
p.XXX {
    margin:10% auto 10% auto;
    }

***************CSSの記述例_ソース2***************
p.XXX {
    margin:5% auto 5% auto;
    }

***************CSSの記述例_ソース3***************
p.XXX {
    margin:1.875% auto 1.875% auto;
    }

*******************************************************
こちらの設定も絶対的なものではなく、ページ構成の作業を進める上でとりあえずこの値で設定しておけば「おおむね問題ない」値です。

この工程に多くの時間が使えるスケジュールがあれば厳密に設定することは効果的ではあります。

以上のように、サイズや高さや間隔などをガイドライン化することで、実績あるページ設計が効率的に組み込むことができ多くのメリットを生みます。

効率化によって確保できた時間を有効活用してアドバンテージを増やしていきましょう。

次回も情報設計に関係した話題をお届け致します。
デジマースのネモトでした。

プロトタイプ/プロトタイピングの活用

今回は「起案」と同時にプロトタイプをつくる「プロトタイピング」の工程を進めてしまうことで、
より多くのサービスをUXを意識出来るレベルまで具現化して並行提案(開発)出来ないか妄想してみました。


開発コストがリスクだったプロトタイプ

商品開発中に全容認識が容易になるプロトタイプの製作は有意義な作業であることは明確でしたが、
プロトタイプ自体の開発期間/コストが問題でそれを行わず、
本開発を進めてしまう現実がありました。
そんな中、
モバイルwebサービス開発支援を目的とした「プロトタイピングツール」の台頭により状況は大きく変わってきております。
詳しくない方でも名前を良く聞くのは、
「Prott」「Sketch」「Adobe Experience Design」でしょうか。

個人的には以前紹介した「Adobe Animate」でもアプリ寄りなプロトタイピングも出来ると考えております。

プロトタイピングツールによって、
従来専門的なスキルと多くのリソースが必要だったサービス設計のやり方にも変化が起きました。

HTMLやプログラムの知識が無くても全体像の構成サンプルをマウス操作で作ることが出来、
実機確認出来る状態を他者へ共有シェア、遷移図の資料等の自動書き出しまで行えるツールもあります。
つまり、
リスクだったプロトタイプ制作のデメリットが解消されたのですから取り組まない手はありません。


プロトタイピングのメリット

従来からサービスの有効性/ユーザビリティーの検証方法として、
「ユーザビリティー調査(テスト)」が提唱されておりますが、
アジャイル的迅速なサービス開発が求められる現在ではその非効率特性が顕著に表れてきてしまいました。
サービス設計者はスケジュールを考慮すると、
まず「削減」を考えるフェイズになってしまっているのが実情です。

非効率化を解消し、
プロジェクトメンバー間での効率的な共有をする目的で開発されたプロトタイピングツールがあれば、
まずは自身もしくは、プロジェクトメンバー全体での認識として、
満足度の高いイメージ/ビジョンが反映されやすい製品プロトタイプが作れる環境にはなってきているのです。

以前は、長い開発期間を経過するなかで薄れてしまったイメージ/ビジョンがあり、
ユーザビリティー調査で「答え合わせ」するまで良し悪しの判断が出来なかったことが、
ツールの導入により素早くプロトタイプが作成出来、
温度差/感覚差が生まれにくい環境が整ったことが最大の導入メリットと言えます。


従来の開発フローで進めるリスク

効率的なツールを競合他社が使うなか、
従来の手法で確実なサービス設計を進めるリスクを考えてみます。

どんな「ひらめき」や「アイデア」が市場で成功するかの確証は残念ながら得られません。
そんな中進めるサービス設計について、
従来のマス需要に向けていれば十分な成功が得られた時代は終わってしまいました。

生活環境が多用化した現在では、同じ環境/価値観自体が少なくなり、そのリサーチしやすい需要も少なくなってしまいました。
先が暗いマーケティング事情なのか定かではありませんが、
「大衆向けヒット商品」が出にくい時代になったことは判断できます。

そんな中で「確実なサービス設計」で進めることはリスクが大きく、
プロジェクトラインを多く抱えられない企業では大きな機会損失に繋がるので、
多くのアイデアを次々と短い期間で具現化し、
そしてビジネスモデル検証するフローが求められると考えます。
そこで可能性を活かす理想論が、「起案」と同時に「プロトタイプ」まで進めてしまうプロセスです。


「ビックプロジェクト」ではなく「ひらめき」の可能性

多用化した生活環境、多様化した需要は裏を返せば、
起案者自身の個人的な需要でさえも、必要とするニッチな需要層である可能性が考えられます。

都合が良すぎる話ですが、
例えば、起案者自身がプロトタイピングツールを使いUX設計を提案出来れば、
残ったリソースでも多くのプロジェクトラインを同時に立ち上げることも可能なのではないでしょうか。

「数打てば当たる」ではなく、
「数打てなければ可能性が埋もれる」でしょうか。

サービスの提供期間についても短く変化してきている感もありなおさら…ではあります。

プロトタイピングツール「Adobe Experience Design」については、
Adobe Creative Cloudのサブスクリプション契約下であればすぐにでも導入出来ます(Mac/Windows10環境)

まずは無料体験期間のあるツールを使用してみてはいかがでしょうか。

次回も、サービスUX設計の話題をしたいと思います。
以上、サービスデザインに関わっているデジマースのネモトでした。

【身の回りのUI】テレビリモコンのUIって…

あなたのご自宅のテレビリモコンは使いやすいですか?

先日、某大手通販サイトに日本の某メーカーのテレビがサイバーマンデーと称し、3万5千円で販売されていたため購入ボタンを連打。

その後テレビが届いたので開封。ねじを数本回し組み立て完了!
外部機器を接続したためリモコンを手にして「入力切替ボタン」を押し……。

……。

……見つからない。

入力切替ボタンが見つからない…。
「絶対あるはずだ」と、入力切替ボタンを必至に探している時に思いました。

「無駄なボタン多い…」

私はテレビを普段使用しないのでこんなこと言うのもあれですが…(三ヶ月に一回見るか見ないか)
皆さんはテレビの機能って使っていますか?使いこなしていますか?

2画面、○○リンク、インフォメーション、電子取説、時刻表示、メニュー、サブメニュー、オプション、アプリ、節電切り替え、ヘルプ、他メーカー独自機能…

何に使うのだろうかというボタンばかりです。
文字で説明されても分からないボタンは使う気になりません。
使ったとしても、利用頻度はどうでしょうか?

昔はリモコンや本体のボタンからしか機能を引き出す導線がありませんでした、ですが現在は違います。昔のテレビと違い“テレビ内にホーム(またはメニュー)”画面を組み込むことができます。ホーム画面に入れれば済むような機能もあるはずなのに、ほとんどのリモコンは機能を全部のせしたような状態です。

テレビの使い方は人それぞれです。私は使わないから周りも使わないというわけでもありません。
当然、全てのボタンを使いこなすTVのスペシャリストも存在するはずです。

ですが、UIデザインの考え方でみるならば、ほとんどのリモコンのボタン数は適切ではないと感じました。

そんなこともあり。

リモコンにはまだ改善の余地があるのではないか!?
ブログのネタになるではないか!!

と思ったため、今回はリモコンのUI(主にボタン数)について、なぜ使いにくいのか?という事と、じゃあどうすれば良いのかという事についてまとめました。

1.リモコンのボタン数

各メーカーから出ているリモコンのボタン数を調べました。
※今回はテレビによく付属してくる「テレビ+録画機能」操作用リモコンでボタン数を調べています
※ボタンの配置は実際のものより若干変更しています

数字ボタン・音量・選局キーを除いたとしても46ボタン前後。ユーザーはこの中から目当てのボタンを探す事になります。この状態だと 使用に慣れても、手元を良く見てから押す必要があります。
ただ、スマートフォンのアプリケーションとは違い「使いにくいから削除」とはいかないので、使いにくくてもユーザーの方から我慢して学んでもらうことができます。しかし、ユーザーを迷わせる、直感的ではないという状態はUIとしては良くないので、どのリモコンもボタン数に関して改良が必要です。

 

 

ボタン数63形

ボタン数が多いため購入時は特にボタンの位置に迷うかもしれません。
テレビを購入したばかりのユーザーにいきなりストレスを与え、「難しい」という先入観を植え付ける可能性があります。また、利用の度に手元をしっかりと確認する必要も出てきます。お年寄りの方ならなおさらです。
様々な機能を知ってもらいたい、使ってもらいたい、という思いがあるのかも知れませんが、優先度が曖昧で、返ってどの機能も目立たなくなっています。
外見のデザインにも制限が多く掛かるため、お洒落、可愛い、など“所有することへの喜び”という体験を与える事は難しくなります。
機能的、見た目的にも……家庭向きなのでしょうか?と思ってしまいます。
まるで業務用デザイン…大型のロボットを動かせそうです!
これぞ日本メーカーといったデザインで、詰め込み&足し算デザインの典型といった感じです。デザイナーの意見は一切通らなかったのかもしれません…。

 

 

ボタン数53形

ボタン数を比較的抑えることができているリモコン。今回調査したリモコンの中だと一番ボタン数が少ないです。ユーザーは53ボタンの中から1ボタンを探すということを考えるとボタン数は少ないとは言えませんが、ボタンをしっかりカテゴリ分けするなどの見つけるためのきっかけを用意することができれば探すストレスは軽減できます。このボタン数だとボタンの配置が重要になります。
ボタン数から、機能を削りきれなかったが厳選した事が伺えます。デザイナー側のシンプルにしたいという思惑と、システム側の機能を使ってもらいたいという思惑がぶつかったようなデザインです。

2.ボタン数が多い事のメリットとデメリット

メリット
・多くの機能にアクセスしやすくなる
・多くの便利機能を知る事ができる
・機能が多いという安心感と充実感がある

デメリット
・目的のボタンを見つけにくい
・情報過多でボタンの優先度がわかりにくいため直感的な操作ができない
・スペースの都合上ボタンが小さくなる(押し間違えてしまう)
・リモコン本体サイズが大きくなる
・手元を見ないと操作が難しい
・デザイン面での自由度が低くなる(所有する喜びという体験が無くなる)

多少デメリットの方を盛った感がありますが…デメリットの事を考えるとやはりボタン数は改善すべきだと思います。

どのリモコンにも無駄だと思えるボタンが多く、使いやすくするためのシンプルさはありません。無駄だと思えるボタンと表現しましたが、正確には無駄なボタンではありません。押すとたいして需要のないであろう、差別化を図るためにメーカーが一生懸命考えた決定打にならない機能が起動するボタンです。

テレビは当然の事ながら映された映像を見るための道具です。それを踏まえると重要な機能は「番組視聴」「録画」「録画番組視聴」という答えに自然にたどり着きます。いくつかのリモコンはそんな利用頻度の高いボタンが、優先度の低いボタンに紛れていました。

使う人によっては、リモコンを使用した時点で「最近のテレビは使いにくい」「多機能すぎて難しいのでは?」「めんどくさそう」と思ってしまうかもしれません。

「そんなのどの製品でも最初はボタンの位置は迷うだろ!」

と思った方もいらっしゃるかと思いますが、ボタンが見つけにくいという問題を解消する方法はあります。
それは、不要な要素を削る、つまりはシンプルにするということです!

3.削ったボタンはどこへ?

ボタンは削る事はわかった。でも、削ったボタン(機能)はどうするのか?という意見もあると思いますが、
こちらに関しても解決策がございます!
それは…

テレビ内のホーム(メニュー)画面内に入れる!(テレビ内のホームのUIがしっかりしていればボタンに入れる必要がない)

です。
テレビ内のホーム(メニュー)画面にリモコンから削った機能を組み込めばいいだけです。
ただ、そのためには“ホームのUIも洗練されている”必要があります。
私が購入したテレビはテレビ内のホームもいまいちでした。テレビのUIに関してはまた別の機会に紹介いたします。

4.考えてみた

この機能もあの機能も使わないから取って…
この機能はメニューからアクセスできれば問題ないし…

ということで今回、私なりにリモコンのボタン数について考えてみました。
※テレビ購入時に付属する(テレビ+録画機能)操作用リモコンを想定しています

それがこちらです!

気になるボタン数は…40ボタン

テレビを見る、録画する、録画した番組を見るという、テレビを使用する上で重要な機能を中心にボタンを選定しました。お年寄りの方向けの究極にシンプルなリモコンレベルには削っていません(すでに多数存在するため)。

日本語で補足を加えるとこのようになります。

テレビを買って箱から出す、リモコンを手にとり自然に電源ボタンを押す、消音も入力切替も楽に見つかる。シンプルにする事でユーザーにとっての障害(探す・迷う)を減らすようにしました。

5.最後に

皆さんも自宅に帰ったら、リモコンを確認してみてください、きっと使っていない謎のボタンがあるはずです。そんなボタンが見つかったら、もったいないので是非使ってみてください!きっとマニュアルが必要となります。そして途中で面倒になり使用をあきらめるはずです。
テレビの差別化を図るために無理やり小技程度の新機能を付けるよりかは、シンプルなUIで上質な体験をどのようにして与えるか?ということに時間を割くべきだと思います。

ボタンを削るだけでは使用感に関して解決とまではいきません、テレビのOSとの連携をいかにスムーズにするのかがとても重要で、ユーザーに「ホームに行けばとりあえず機能が見つかる」と思ってもらえるUIにしておく必要があります。そうすればリモコンからボタンを削っても利用してもらうことが可能です。

(はら)