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

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

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にしておく必要があります。そうすればリモコンからボタンを削っても利用してもらうことが可能です。

(はら)

スマホ向け抽象的デザイン

モバイル向け画像を製作する作業は、
画面解像度の低い携帯電話向けに作っていた時代から、高解像度のスマートフォン向けにシフトしており、非常に多くの情報を扱う必要があります。

240pixel → 320pixel → 640pixel → フルHD/2K → 4K

結果、
レイアウトや素材を製作する場合の情報選択肢/余地が増え、判断に時間がかかり、細部まで作りこみが出来てしまう為、終わりが見えなくなる作業を生む可能性が高まり、
また、高まった表現力は「具体性」「趣向」の判断を生む状況にも及んできております。

…今回はそんな予期せぬセグメントを避ける抽象的な表現情報量との適切な向き合い方を考えてみました。


制約の中での可能性

日本人は制約を受けた状況下での、アイデアと効率化を得意としているといわれています。
理由として、限られた島国国土の中で生活をしてきた影響もあるのでしょうか。

1980、90年代の量産性に長けたアニメフォーマットの確率や、家庭用ゲーム機ハードとソフト面での成功、
そして、携帯電話とハード/ソフトの開発においても世界の指標たる結果を残してきた状況は、
いずれも、「黎明期から成長期へ向かう中でのテクノロジーが後追いする制限下」であったといえます。

しかし、
逆の視点から見てみると、
日本人は可能性溢れる選択肢状況下では目的を見失い、
多彩な表現力の状況下でも方向性を見失いがちな思考を持っているとも考えられます。

話を「表現」「UI」に絞ってみると、
日本人は、シンプルで捉えやすいUIに長けている可能性が考えられるのではないでしょうか(強引ですが)。


シンプルで捉えやすい表現とは?

わかりやすさの条件は「単純構造」で「敷居が低い」でしょうか。

グラフィックデザインでは標識やマークなど「アイコン化」されたものがその代表ですが、
そのわかりやすさを追求して結果が、私たちが良く見るシンプルなデザインになっています。

いずれのマークも初見の記憶がないくらい一般的に生活に浸透しており、
作りこんだ表現にする必要がないことを理解いただけるのではないでしょうか。


セグメントしない表現とは?

人を選ばない(セグメントしない)表現とは、狭義ではなく広義で抽象的であることです。
作りこみ、具体的にすることが目的である以外はシンプルな表現で進めることのメリットが多いのではないでしょうか。
例えば、

・運用性/更新性の向上
・容量削減
・表示速度改善

でしょうか。

ピンク色の画像は描き込みが多く具体的で、見る人にカテゴリ(犬/車)を越えて詳細(犬種/車種)まで想像させています。


まとめ

情報設計に「更新」は付き物です。
運用パフォーマンスを考えた場合、
グラフィックデザインはトータルコストを抑えられる素材を選ぶ必然があり、
アーティスティックなグラフィックであれば、
芸術品として「想い」を込める必要があります。

限界の作りこみが価値に大きな影響を与えるコンテンツはありますので、
都度案件の「目的と訴求対象」を意識して、
抽象的で適切な情報設計を運用してみるメリットは十分あるのではないでしょうか。

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

2016-2017 ブログまとめテスト

こんにちは、はらです。私の年内最後の更新となります。
今回は2016-2017年のデジマースブログの中からUIに関してクイズ形式でいくつか出題したいと思います。
どの問題もデジマースブログを毎週チェックしている方ならわかるはずです!?
※解答はページ下部に記載しています。
 


 
(15点)

1)カテゴリ検索時に、カテゴリ内の検索数を表示する機能をなんと呼びますか?

解答・解説をすぐ見る>

(各5点)
コントロール系部品の名称についてお答えください

解答・解説をすぐ見る>

(各5点)
コントロール系部品の名称についてお答えください

解答・解説をすぐ見る>

(20点)

1)図のような実際の画面を利用し、直接ボタンの意味や操作手順などを説明する見せ方をなんと呼びますか?

解答・解説をすぐ見る>

(20点)

1)UIの手法の1つで、仕様説明を初回起動時に行うことをなんと呼びますか?

解答・解説をすぐ見る>

(5点)

1)図のような複数画像を左右にスライドさせることで表示させる展開(回転)構造を持ったWebコンポーネントの事をなんと呼びますか?

解答・解説をすぐ見る>

いかがでしたが?難しい問題が多かったと思いますので、点数が低くても気にする必要はありません。これらの情報は知っておくとミーティングがスムーズに進むのでUIに関わる方は知っておいて損ではないと思います。ではまた来年に…はらでした。


解答はコチラ

【1】15点
1)ファセットカウント

【2】各5点
1)セグメンテッドコントロール
2)スライダ
3)アクティビティインジケータ
4)ピッカー

【3】各5点
1)ステッパー
2)ページコントロール
3)ラジオボタン
4)スイッチ

【4】20点
1)コーチマーク

【5】20点
1)ウォークスルー

【6】5点
1)カルーセル

押せる画像・ボタンについて考えてみる

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

▼押せる画像・ボタン①

サイト内で画像やボタンを押す際に分かり辛くて、踏みとどまったり、探したりしたことはありませんか?
さて今回はそんな画像やボタンをどうしたらユーザーへ認識してもらいやすくなるか、改めて考えていきたいと思います。

上記のワンちゃんの画像をみて「押せる」と直感的に感じた方は少ないのではないでしょうか。
上記の画像は見出しの写真かと思いつつも、さりげなく押してみたら先へ進む事ができたというパターンになりやすい一例です。

とにかく押せるかどうかはちょっと分かり辛いですね。
それでは、この画像をどうしたら「押せる」と直感的に認識、感じることができるのでしょうか?考えていきたいと思います。

画面横いっぱいに画像を置いてしまっている為、上下にある帯(※コンテンツ帯)と同じく押せない領域と見えてしまいがちです。

■押せない画像との差別化(左右のスペース)
・押せるボタンは画面横いっぱいまで使用せず画像の左右のスペースをあけるとべたっとした状態から浮き出てくるので差別化がしやすく、この場合コンテンツ帯との押せる・押せないメリハリもついて分かりやすい。

■一目で押せると分かる様にする。
・?マークで遷移できることを視覚化。「こちら」などのダイレクトな文言でも可。
・押せるものは角丸で表現する等。

※これらは一例のため、目的があってこの形にしている場合はこの限りではございません。

▼押せる画像・ボタン②

サイト上部右上にもっと見るボタンが有るのがお分かりでしょうか。
文字が小さく見辛い点とそもそも帯上でのテキストの羅列ですので、「押せる」と認識するのに少々時間がかかってしまう気がします。
サイト運営側で意図してこの表現または優先度にしている場合を除き、このままですとユーザーが見落とす可能性が高くなってしまいますよね。
それでは見落としが無い様にするにはどうしたらよいか考えていきたいと思います。

・帯上にあるテキストの羅列ですので、「押せる」と認識がし辛い。
・文字が小さく視認性が悪い。

■視認性アップ(図A)
・単純に文字の視認性を上げて、見やすくする。
右側のの帯タイトルより大きくなると不自然になってしまうので注意が必要です。

■見やすく図形化させる(図B)
・四角いボタンにすることで「押せる」イメージをわきやすくさせる。

■目線の流れで見える位置に移動(図C)
・もっと見るを帯状ではなく、ダウンロードボタンの下などのコンテンツ内容内に置くことで自然と目に入る訴求にする。

※これらは一例のため、目的があってこの形にしている場合はこの限りではございません。

▼押せる画像・ボタン③

上記の画像、押せる画像なのですが一見「押せる」という認識よりも押せない画像に見えてしまいます。

押せるようなイメージがないから、といってしまえばそれまでなのですがそれ以上に注意しなければならないことがあります。
早速ですが見ていきましょう。

・(一応左右に空白スペースがあり帯との差別化はできているが)画像がファーストビューに収まりきれておらずスクロールしないと全体像がみえない。
・押せる画像は大きすぎると押せる=ボタンの認識が弱くなりやすい。

■画像を適度なサイズにする
・押せる画像を最低限ファーストビューに収まる様、調整をする。
一目で押せると判断できるとなるとこのサイズ感でも少々大きめなので、ファーストビューの2/3以下にまとめると良いと思います。

※これらは一例のため、目的があってこの形にしている場合はこの限りではございません。

▼最後に

デザイン案を考える際に押せるものの表現をどの様なものにするか等も内容と同じくらい細かく設定するとユーザーに
伝わりやすいサイトになるのではないでしょうか。
ex)角丸にする、左右に余白を置く、遷移マークを入れる等

遷移させる画像やボタン等が分かり辛く、それらの箇所で回遊が停滞してしまうのは致命的といっても過言ではございません。
ユーザーがスムーズに回遊できるよう改めて遷移させる画像やボタンの見直しをしてみるのも良いかもしれません。

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