バナー制作でおさえておきたいポイント

こんにちは。ユイPです。
最近2年使ったiPhone 7をiPhone XSに機種変更しました。画面とカメラの綺麗さにはテンションがあがりますが、まだ使いこなせている気はしません。

今回は「バナー制作の時におさえておきたいポイント」がテーマです。
以前「新米デザイナーが作る!バナーの作り方」という記事を書きましたが、あれから約10ヶ月…制作したバナーの数も10ヶ月前の時点では約300個でしたが、この記事を書いている時点で約800個まで増えました。1000個までもう少し。

前回の記事ではバナーの作り方を作業工程と共に解説していきましたが、今回はタイトルの通り、「バナー制作時におさえておきたいポイント」を解説していきたいと思います。

※前回の記事と少々書いてある事が被る部分もございます。
※またこの記事で使われているバナーは全て架空のバナーです。


バナーとは広告や宣伝などのために使われる画像の事です。
バナーの目的は主に「見た人にクリックしてもらう」事です。
掲載場所やターゲットによってデザインや訴求ポイントは変わってきますが、クリックしてもらうために「このバナーで誰に何を訴求したいのか」を考えて作っていく事が大切です。

これを踏まえて制作時のポイントを解説していきます。


1.めりはりをつける

例えばこの2つのバナーだったら、どちらの方が大事な文言がより強調されていると思いますか?
答えは下です。文字サイズの強弱や色の差がついているので「人気作品”無料”」という言葉が一番見せたい部分なんだなとわかります。
めりはりは文字サイズ、フォント、文字色などでつける事が出来ます。

掲載場所や内容によっては、文字や色のトーンが統一されたものなども使用されています。
そういったバナーは訴求力が重視されているのではなく、「雰囲気にあった」バナーである事が多いかと思われます。
広告などで使われるバナーは目を引く事が大事になってくるので、人の目に触れてほしい部分がどこかを考えて、強調する部分と控えめでいい部分、差をつけて作っていきましょう。

2.不自然な”余白”は埋める

このバナー…どうにも真ん中の文言と写真の間の余白が気になりませんか??文字や写真/絵を調整すれば埋められそう?…そんな時はどうにかして埋めてしまいましょう。

という事で文字の組み換え、写真のサイズ調整などをしてみた所、見事に埋まりました。
変な余白があるとなんだかそこに目が行きがちですし、画面も寂しくなります。文字を大きくする、組み方を変えてみる、文字間や行間の調整、画像があればその位置を調整してみる、図形や線を足してみる…など余白の埋め方は色々あります。
もちろん余白を活かしたデザインというのもありますので、埋めるのは”不自然な”余白です。

3.要素を散らばせない

人の目線は左上から始まり右下で終わる、Z型の流れのレイアウトが見やすいというのはどんな媒体にも言える事ですね。
もちろんバナーも、そういった流れを意識して自然と読みやすいように制作しています。

例えばこのバナー、要素が四方に散っているし、図形は多いし、どこが大事でどこから読めばいいのか…読めない事はないけど散らばっていてなんだか気持ち悪い…。
なので流れを意識して作ってみます。

これなら、上の情報と下の情報、混乱せずにスッと読む事が出来ると思います。要素を分散させずに、図形や線を使う時もバランスには注意しましょう。

4.困ったら位置変え・傾ける

基本の法則は守っているけれど遊び心がない。つまらない。そんな時は思い切って文字の位置を変えたり、傾けてみたりしましょう。

ちなみに傾ける時は左下から右上に向かって↗この角度で傾けた方が文章が読みやすいです!

5.表示されるサイズを考えて作る

私は普段1020×360のサイズのバナーを作る事が多いです。そのサイズを開いていると、普通にPhotoshopの画面いっぱいくらいに大きく表示されていますよね。
ここで陥りがちなのが、「スマートフォンの画面サイズで見た時に、文字がちゃんと読めるか?」という問題です。

このバナー、PCの画面では大きく見えていても、実際にサイトに掲載されたら…(スマートフォンでこのブログを読まれている方には既に見えづらいかもしれません)

こんな風に小さくなりますよね。こうなった時、このバナーの上の部分の白文字、読めますか?正直読みにく~~いですよね。
こうならないためにも、ある程度サイズが小さくなった時の事も考えて制作しましょう。
今回はこのように調整してみました。

白文字の部分に太字の効果をかけ、背景に濃い色を引いてみました。先ほどのよりは少しは見やすくなったかと思われます。

このように情報量が多いバナーだと限界もありますが、出来るだけ配慮して制作しましょう。

6.文字間・行間の設定はしっかり

文字が主役なバナーにとって、これは本当にとっても大事な事です。

文言・配置は同じでも、上のバナーよりも下のバナーの方が、読みやすいと思いませんか?文字間を調整する事で「55%OFF」の部分は更に大きく強調されていますし、緑枠の中の説明文も間を開ける事で読みやすく、無駄な余白もなくなりました。少し調整するだけで、こんなにも変わります。
文字は手動で調整してバランスを美しく整えましょう!


以上が、私がおさえておくべきだと思うポイント6つになります。

とは言え私もまだまだ勉強中で完璧ではありません。上記の内容も最初からわかっていたものではなく、色んなバナーを見て学んだり、たくさん指導して頂いて覚えたものです。
バナー作りにこれから携わる方は、色んなバナーを見て、学んで、たくさん作ってみてください!

それでは、また。
ありがとうございました。

ストレスを感じる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:スガ

老眼のユーザビリティ

驚愕ですが、15歳を過ぎると既に「老眼」の症状が進行しているそうです。

私はUI、ユーザビリティに関わっていますが、スマホなど近くが見えない老眼症状を感じる年齢になり、毎朝茶碗に盛られたお米にも焦点が合わず経験と感覚で食事してたりします。

そこはポジティブに受け止めて、自身でもある団塊ジュニア世代(第二次ベビーブーム世代)の大きなターゲットに向けたユーザビリティを考えてみます。


スマートフォンの画面

私の場合、画面との距離は30cm程度で持つとピントがハッキリとします。

一般的に近点距離の年齢別の目安として、
20歳で15cm
30歳で21cm
40歳で33cm
50歳で60cm
60歳で150cm

以上の距離が必要とのデータもありますので安定して進行しているようです。

下記はiPhone6系の画面にそれぞれのサイズの文字を表示させています。
※一部ブラウザの基本仕様により、10pxより小さいサイズはCSSで設定しても10pxで表示されてしまいますので、最小サイズは10pxに設定

⇒スマホでの実サイズ表示はこちら

確認してみると、10pxの文字は自身には可読性が低いと感じられます。

40代から老眼の症状が気になってくるといわれておりますが、
目の負担により、肩こり、頭痛、吐き気の症状があり仕事に支障をきたします。

ですが現実問題として老眼鏡をかけてスマホを見る行動について、外出中は特に難しいと感じています。

スマホの画面表示の場合は、優先度が高い部分での10px、12pxの文字の運用はターゲットにより控えるべきですが、
弊社の「フォントサイズ運用ガイドライン」を確認すると↓

優先度が低い訴求部分で10px、12pxの文字が運用されております。

メインターゲットにもよりますが、年齢に応じたCSSを使い分けるのも大変な手間なので、対象利用者は端末の文字サイズを「設定」から「標準⇒拡大」に変更する勇気ある決断が必要です。


混雑率200%~の車内

フォントサイズを大きくするなど物理的な対応を行い何とか乗り切れたとしても、どうにもならない状況が日々の通勤時に発生します。
「混雑率200%~の車内※」
(※週刊誌程度ならなんとか読める)
です。

主観では満員電車で必要外のスマホ利用は控えるべきと考えますが、
混雑率200%を超えてくると、車内で他の乗客と適切な感覚を確保する事は難しく、
その利用シーンではスマホ画面との距離は20cm程度まで近くなる状況になります。

そのなかで老眼の場合、ピントが合わず30cm以上距離をとる必要が出てきます。

物理的に無理があり他の乗客の迷惑となりますので利用者はスマホの使用を控えましょう。


大画面テレビ

老眼より近視の影響もありますが、
視聴距離が2mを越える4Kや8Kの50インチ越え大画面テレビのきめ細かさを認識をするためには、画面に近づく必要があるため高解像度化の恩恵がありません。

そんな状態で4Kの恩恵を得られるのは視聴距離が40~60cm程度と短いPCの画面など24インチ前後のモニター/ディスプレイです。


サービス側のユーザビリティ配慮

 
たとえば利用者が、書き方がわからない漢字を調べる場合

ブラウザに読みを入力。
・「忖度」…画数が少ないのでや文字が小さくても構成が判断できます。
・「薔薇」…この画数は厳しいです。

状況によって利用者はピンチ操作で画面表示を拡大します。
したがって、サービス側での配慮としては、10pxや12pxの文字サイズの運用を避けつつhtmlのメタ設定では、

<meta name="viewport"content="width=device-width,initial-scale=1.0,user-scalable=no" />

この記述内の
「user-scalable=no」部分を設定さえしなければ、利用者はピンチ操作で任意のページを拡大縮小できるようになります。是非配慮をしてあげてください。


その他の配慮

紙に印刷して展開する細かい数字などの資料ですが、
若い方には読めても、歳を重ねた方には大変な苦痛が起き、目が疲労して頭痛、肩こり、吐き気の症状があらわれます。
是非配慮をしてあげてください。

また、社内の廊下の奥に人がいる場合でも、歳を重ねた相手側にはあなたが誰か認識できていない場合があります。
是非察してあげてください。


まとめ

老眼のユーザビリティ対応

・~10px、12pxの文字使用は避ける
・HTMLメタ内「user-scalable=no」の運用は避けピンチ操作に対応する

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

Featured Video Play Icon

左利きの視点から見たユーザビリティ

こんにちは、ユイPです。毎日暑いですね。平成最後だからって夏頑張りすぎじゃない?

突然ですが、あなたの利き手は右手ですか?左手ですか?おそらくほとんどの方が右手だと思います。
左利きの人口は全世界で約11%だそうです。100人いたら11人。多いか少ないかで言えば少ない方ですよね。
ところがどっこい、私ユイPは左利きです。お箸を持つのも字を書くのも絵を描くのもボールを投げるのも左手。スマホを持つ手は右です。

みなさんも一度はネット上で「左利きは●●が不便~!」みたいな話を見かけたことがあるのではないでしょうか。確かに世の中は右手を使う事を前提に作られているものが多いので正直不便に感じる事も多いです。
でも不便な事ばっかりじゃなくて、利点もあるのでは?そもそも今右利きを前提に作られているものも、少しの工夫で左利きにも優しくなるんじゃないかな?と考え、今回は左利きである私の視点から身の回りに溢れるもののユーザビリティについて書いていきたいと思います。
※決して「左利きってほんと不便なの!配慮してよ!」という愚痴をぶつける記事ではありません。


1.改札

改札でICカードをタッチしたり切符を入れる場所は右側ですよね。右利きの方はおそらくみなさん右手を使う方が多いと思います。私も無意識下では左手でICカードを持ってしまうので手をクロスした状態でピッとやります。もう慣れてしまいましたが…。

もしも改札が、両側どっちにタッチ(切符)してもいいよ!という設計になったら理想的です。

コストや事故など色々考えるとなかなか実現は難しいと思いますが。

2.スープレードル

ユイPが個人的に1番左利きでストレスを感じるのがこれです。ファミレスのスープバーなどでよく見かけるこやつ。
この写真のものは丸いお玉型をしているのでまだそこまで使いにくくないのですが、お店にあるもっと細くて先が尖ったタイプのやつ…(写真が用意出来なかったのでこちらから)使いづらさが最上級です。仕方がないので右でいつも使いますが、注ぎにくいのでこぼしてしまったりする事もあります。

なのでどちら側からでも注げるように、両側に注ぎ口があるレードルがあったりしたらいいなあと思います。

左利き用も売っているので自宅ではそれを使うしかないですね。

3.ハサミ

どうしようもない。
左利きハサミを常備するか、右で扱えるようにするしかない。私もハサミは右で使えます。右利き用でも普通に左手でも切れるやつあるんですが、切れないやつと何が違うんでしょうね?

4.お菓子の切り口

お菓子の切り口って左手で持って、右手で開ける事が想定されているので左側に切り込みが入っているものが多いです。なので左手で開ける場合裏返して開ける事が多いです。開ける事に支障はありませんが、切り口のガイドが見えないので切り方を失敗してしまう事もなくはないです。

両側どちらからも開けられるものだと嬉しいです。

5.電話機

会社でおなじみ!電話機。

左でとって右手でメモなどが出来るよう、左側に受話器がついていますよね。左利きは右でとって左でメモします。私も会社のデスクでは右側に電話を置いていますが、もしこれが位置固定で左側にしか置けなかったら…手がクロスしてメモが取りづらい。
なので受話器は上側にあったりすると平等かもしれません。

昔なつかしのこの形を更に改良していけば使いやすそう。

6.スポーツ

体育のキャッチボールとかだとペアの相手に嫌がられる事もありますが、勝負の世界だとレフティって有利とも言われますよね。これは左利きのメリットだと思います(私はスポーツ苦手なのであまり感じたことないです)。
左利きの人はおそらく利き足も左利きの人が多いですよね。サッカー選手でいうとメッシでしょうか。

7.銀行とか役所にある固定されたペン

(手作り感の強い写真ですみません)
紛失や盗難防止なのでしょうが、右側に固定されている事が多いですよね。この固定している紐やチェーンの長さが短いと書きづらい…。

これはシンプルに真ん中に設置する、そして紐は長めにしておいてほしいです。

8.楽器

私は学生時代左利き用のベースを弾いていました。まず左利き用の楽器を扱っているお店はあまり多くありません。そして左利き用を使っていると「あ、ちょっと貸して~」と友達に借りる事も出来ませんでした。
右も左もわからない初心者なら、一般的な右利き用で始めるのもアリだと思います。かつて私も楽器屋さんのお兄さんにもそう言われました。
(それでも当時の私は好きなアニメの推しキャラクターがレフティのベーシストだったという理由で左利き用を買いました。世界のポール・マッカートニーもレフティ)

9.キーボードとペンタブとマウスと私

これはペンタブで絵を描く方限定の悩みだと思うので、伝わりにくい方には申し訳ありません。

左手でペンを持っているとキーボードのCtrl+Z(を始めとした一般的なショートカットキー)が押しにくい!

カスタマイズ出来るタイプのキーボードやワイヤレスだといいのですが、普通に設置されているものだと右手がつりそうになります。
Photoshopなどはショートカットキーもカスタマイズ出来るのでそういった所で対処していくしかありません…。

ですが、左手でペンタブを使っている時にも利点はあります。
そう、それはマウス。

マウスは右という左利きさん、私もですが身近にも多いです(マウスも左だわ…という方がいたらごめんなさい)。
マウスが右だとペンタブを左手で使いながらマウスも握っていられるんですよね。これはとても利点だと感じています!

10.ノート

横書きのノートは左手の側面が確実に真っ黒になります。

ペンだとにじんでしまったり…これはもうどうしようもないです。にじまないボールペンが好きです。
またリング式のノートやファイルも手にリングが当たって書きづらいので、私はこれは取り外しの出来るルーズリーフを使って対処していました。会社のファイルなども出来る限り取り外しの出来るものだと嬉しいですね。

ただし唯一右利きに勝てる所があります。それは「縦書き」。

身近な所でいうと国語のノートでしょうか。これはものすごく書きやすいです。

11.左利き=天才じゃない?という風潮

世界の名だたる偉人には左利きがとても多いです。レオナルド・ダ・ヴィンチも、ミケランジェロも、ピカソも、アインシュタインも、ニュートンも、エジソンも、ベートーヴェンもみんな左利きです。左利きの人は右脳が発達しているから、何かに長けていることが多い…という説がありますね。
ですが私は左利きでも今のところ何も発明していないので凡人です。
「左利きなんだ!なんかかっこいいね!」と言ってくる方たまにいますが、反応に困る。


というわけで、いくつか紹介をしてみました。いかがでしたでしょうか。
不便な点も多いですが、メリットがあるものもあれば、自分なりに改善できる点、世の中全体で改善して頂けたら使いやすくなりそうなものもありました。

世界の89%は右利きなので、多い方に有利な世界なのは当然だと思います。決して左利きにもっと配慮しろ!なんていうつもりはありません。正直私は日常生活を生きる上で左利きであることにそこまでストレスや不便さを感じていません(ここまでこれだけ色々書いたのに)。

ですが今回の利き手の話に関わらず、多い方だけを優先するのではなく少ない方に対しても少しでも配慮をする事が、デザインや開発をする上で心に留めておくべき大事な事なのではないでしょうか。

とりあえず左利きの人が食事の席で人の左側に座りたがる事を許してください。

さもユイPが人類の左利き代表のように書いてしまいましたが、そんなわけはないのでこういう意見のやつもいるんだなあ~という気持ちで受け止めて頂けたら嬉しいです。
それではまた次回!

右手で書きました。


★ほぼ毎日更新中!
デジマースブログ公式ツイッター

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

こんにちは、はらです。
私は前回エレベーターの「開く」「閉じる」ボタンのアイコンは紛らわしいという記事を書きました。

その記事では「なぜ紛らわしいのか?」「こうすると良いのでは?」など、あれこれ語ったにも関わらず、実際に新しいアイコンデザインは考えませんでした。

すると、やはりと言いますか…「あれこれ語ったのなら究極のアイコン作れるよね?」という声が上がりました。(震え声)

という事で今回、私が思う理想の「ひらく」「とじる」ボタンを実際に制作したいと思います。
エレベーターのボタンに関して現在はこうだという定量的な表現ができないので、デザイン上必要な条件を満たしていくという方法で最良の答えをみつけていきます。
この記事を書き終える頃にはきっと、とてもわかりやすい「ひらく」「とじる」ボタンが完成しているはずです!(震え声)

制作する上で注意した点

前回の記事を参考にしながら、制作する上で注意するポイントをまとめました。

1.ひらくボタンが優先されているか?

「ひらく」ボタンはドア挟み防止という安全上の理由から「とじる」ボタンより優先度を高く設定する必要があります。今回は色やアイコンの形状により優先順位を明確にします。
(開きたいと思った時に「とじる」ボタンに目線を向けてしまうとそれだけで時間を無駄にしてしまうので優先順位を明確にする事は大切ですね!)

2.色使いは適切か?

エレベーターの「あける」ボタンに色が付いている場合は緑色が使われています。
目立つので赤では?と思った方もいらっしゃるかもしれませんが、赤色は機械に使用すると非常用ボタンや緊急連絡ボタンなど「緊急」を連想させてしまうため、ボタンに利用すると押す際にためらいが生じます。また、焦りも増徴させてしまいます。黄色も同じように使い方次第で警告や注意喚起を連想させるため普段使いのボタンに使用すべきではありません。
緑は安心感、落ち着き、緊張の緩和などをのイメージに繋がります。機械に使用すると、進む、平常運行、作業完了、準備完了、充電完了、といったような安全なイメージ繋がります。以上の事からボタンを目立たせるという目的に使用する色は「緑」が良いといえます。

3.一目見ただけでアイコンの意味が理解できるか?

エレベーターのアイコンが抱えている問題はコレですよね…。一目見ただけでアイコンの意味が理解できるかという問題。ボタンが「ひらく」か「とじる」かを判断する時間は4秒前後のため当然アイコンは一目見ただけで判断できるようになっている必要があります。アイコンに対し過剰な装飾を加えたり、余計な立体感を加えると情報量が多く人によって処理に時間がかかってしまったり、解釈に違いが出てしまいます。いかにシンプルにするのかが重要です。今回は一つの記号に対し2つ以上の情報を与えないよう意識して制作を行います。

4.文字の表現は適切か?

年齢や国籍の事を考えるならば文字表記なしで伝わるのが理想ですが、前回の記事で文字に関しても触れたため今回は文字による補足も加えます。その文字表記に関して漢字は絶対にオススメしません。いわずもがなですが、「開」「閉」はとても紛らわしいです。焦っていない状況でも間違えます。文字を載せる場合はひらがなで、「ひらく」「とじる」がもっとも間違えにくいです。「左右」もそうですね「ひだり」「みぎ」と書いたほうが間違いを減らす事ができます。

この4項目を満たすと、わかりやすいアイコンになります。
それでは早速、上記のチェック項目を基に制作して行きたいと思います。

実際に考えてみた

良いと思えたもの

いろいろ迷いましたが完成!

もうすでにありそうですね…分かりやすくするために必要な4項目を全て満たしているので、押し間違いの発生率を下げることができる…はず…です。


「ひらく」ボタンのサイズを大きくしなかった理由

利用シーンあるいはユーザーの属性によって、どちらのボタンを重要と捉えているのかが変化するため、今回の記事ではボタンサイズを統しました。

介護施設や病院など判断や動作に時間が必要な方の利用が多いと考えられる場合は「ひらく」のボタンサイズを大きくするべきだと考えております。

「ひらく」を大きくする事は、目立たせる手段として大変効果的なため、サイズ感に関しては大変迷いましたが、今回は「ひらく」を目立たせるのではなくどちらが「ひらく」か判断を早めるという考えのもと制作を行ったため、サイズを統一いたしました。

また、「ひらく」を大きくする事によって、階数ボタンとの優先順位が変化し、階数ボタンよりも先に「ひらく」ボタンに目線が向かう可能性があると考えたためサイズを統一いたしました。

最後に…。

いかがでしたか?結局ありそうな形に収まりましたね…。
ひらくボタンは安全上必要な場合がありますが、とじるボタンは最悪無くても問題ありません。ですので閉じるボタンを削ってしまうのも手かと思います。とじるボタンが無ければ、ひらくボタン一択になり、迷う要素はありません。海外ではとじるボタンは無い事が多いそうです。
ただ、日本のUIは丁寧&補足詰め込みが大好きなので、削ったところで「このエレベーターには閉じるボタンがありません」なんていうシールが張られてしまいそうですね!
手でとめるというのも究極ですよね!何も迷いません。物理的にとめて開く…究極に直感的です。ただ、挟まると言う危険と恐怖がありますので良くはないですけど…。
このボタンの問題、完全な解決難しいと思いました。人が人である限り…。

ちなみに…アップル銀座のエレベーターには操作ボタンが全くありません。

それではまた。

(はら)

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

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

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

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

最初に

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

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


ハンバーガーメニュー

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

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

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

メリット、デメリット

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

《 ユ ー ザ ー 目 線 》

メリット

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

デメリット

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

《 デ ザ イ ナ ー 目 線 》

メリット

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

例えば一例ですが…

デメリット

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

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

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

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

最近の傾向では

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

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

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

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

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

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

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

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

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

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

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

最後に

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

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

お掃除ロボットは何故カワイイの?【UXで考えてみる】

こんにちは!
今回のテーマは「お掃除ロボットは何故カワイイの?【UXで考えてみる】」です。

働くロボットや愛玩ロボットなど、私たちの何気ない生活の中にロボットが溶け込み初めていますよね。
有名所だとルンバやAIBO、Pepper君でしょうか。持っていないこそすれ、名前だけは聞いたことがあると言う人がほとんどかと思います。

そんなロボットたちに、みなさんは“カワイイ”と感じた事はありますか?
私はあります。世の中にはロボットをカワイイと感じ、親しみを覚えたり愛着を持つ人間がいます。
人間や生き物でもないただの機械を、なぜカワイイと感じてしまうのか。
今回は「お掃除ロボット」に焦点を当て、UXデザインの観点から考えてみたいと思います。


お掃除ロボットと利用シーン

お掃除ロボットは、いつどこで誰が何の為に利用するのでしょうか。少し整理してみます。


1.いつ?

仕事に行っている間や寝ている間、別の家事をしている間など。人間が別の事をしている時に掃除しておいてもらう事がほとんどかと思います。

2.どこで?

家庭のリビングや廊下など共用スペースで利用される事が多いかと思います。
一般家庭だけでなく会社で利用している場合もありますね。弊社にも休憩時に使うスタッフルームにお掃除ロボットが常駐しています。

3.誰が?

対象ユーザーは忙しい共働き夫婦や一人暮らしの男性、掃除が困難な老人など、老若男女様々です。

4.何の為に?

利用する目的は「人間の代わりに掃除して欲しい」です。そのままですね。
少し言い方を変えると、掃除はロボットにまかせて、空いた時間を別の事に活かしたいと言う目的もあるかと思います。


利用シーンをざっくり書いてみましたが、これだけだとロボットをカワイイと感じる要素はないかと思います。
ですが、これをUXに置き換えてみると少し変わって来ます。


ロボットとUXのハニカム構造

お掃除ロボットをUXの観点から見ると、非常に優秀だと言えるかと思います。

UXとは、楽しさや心地よさなどのユーザー体験の事です。
UXには下記のようなハニカム構造があります。

お掃除ロボットはこのハニカム構造の多くを満たしています。

特に注目したいのが「Useful (役に立つ)」と「Desirable(好ましい)」です。ここに、お掃除ロボットを“カワイイ”と思わせる要素が含まれていると私は考えます。

「Useful (役に立つ)」は、人間の代わりに掃除をしてくれる所です。
「Desirable(好ましい)」は、上記に加え、少し不器用な面がある所です。


不器用で健気なUX

お掃除ロボットの不器用な面とは、ロボットだけで隅々まで掃除する事が出来ない所です。
床のゴミを吸い取るロボットは、構造上の問題でコーナーや狭い場所の掃除が苦手です。ちょっとした障害物や段差があると掃除する事が出来ません。
また、掃除の時間も人間以上に掛かります。長い時には1時間以上掛けて掃除する場合もあります。
一見マイナスな事ばかり書いてしまいましたが、ここにロボットの“カワイイ”のポイントがあります。
人間だったらさっさとこうするなと思う反面、健気さも感じるからです。

お掃除ロボットはプログラムやAIによって、行動、学習、計算のサイクルを繰り返して掃除を行います。
部屋全体を最適なルートで綺麗に掃除する為であり、非常に合理的ですが、それ故に融通が利きません。
言い方を変えると「不器用だけど頑張り屋」です。
段差や障害物の前ではぶつかったり小刻みに動いて状況を判断、方向転換してルートを考えます。地道な作業を繰り返しながら、部屋を何往復もしながら掃除してくれます。
そのため人間が掃除機を掛けるより時間が掛かりますが、結果として人間の目的である「綺麗な居住空間(継続的)」と「掃除に掛けるはずだった時間」を提供してくれます。

人間とはまったく異なる小さな無機物が、彼らなりに考え、指示された目的を達成しようとする姿はとても健気で、人に「好ましい」と言う感情を起こさせます。
ロボットの構造上やむを得ない不器用さの中で、人間の欲求を満たしてくれる「好ましさ」が人に“カワイイ”と感じさせるのではないでしょうか。


おわりに

いかがでしたでしょうか?
お掃除ロボットに焦点を絞り、UXデザインの観点から何故カワイイと言う感情を起こさせるのか考えてみました。
その結果、「Useful (役に立つ)」「Desirable(好ましい)」の部分が影響している事がわかりました。
お掃除ロボットに焦点を絞って書いてはいますが、他の家庭向けロボットにも共通して言える事ではないかと思います。
ロボットがより人間に近い動きや見た目になると、便利だと感じこそすれ、カワイイとは思わないかもしれませんね。

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

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

モバイル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等、こちらのページ記事を参考にしてカスタマイズしてみました。
「ページ移動せずに内容を変更するタブ機能の作り方」

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

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