スマホが変化させた生活シーン/サービスの利用シーン

スマートフォン(以下スマホ)の登場により、
あらゆるアクションが場所を選ばず行えるようになりました。
(ある程度の許容は必要ですが)

行動必需品と化したスマホですが、
スマホの無い日々を想像してみて下さい。

他人との関わりや恋愛、旅行とドライブ、映像鑑賞など、
スマホが優先度高くこれらの行動手段の手足になっている方は多いのではないでしょうか。

あらゆるサービスや製品の設計者が「利用シーン」を考えた場合に避けられない、
そんな「スマホ有りき」な生活シーン変化させた利用シーンを今回は考えてみます。


都合が良いスマホ

そもそも、
我々が何故スマホを手放せなくなっているのかといえば、
「都合が良い」ユーザーメリットの塊、という理由に尽きます。

・携帯性  / いつでも所持出来る
・連絡機能 / いつでも連絡/通信が出来る
・情報取得 / いつでも欲しい情報が見れる

電波さえ届く場所なら場所を選ばない便益な利用シーンがここにあります。


手、足、スマホ

ある意味、現代人の体の一部になっているスマホは、あらゆるサービスの利用シーンに必ず登場します。

トイレでも、お風呂でも、就寝中でも、違法で危険な車両運転中の事象までも発生してしまっており、
何をする時でも肌身離さずスマホがそばにある現実となっています。

これほどまでに生活に入り込むと、家電や車など製品連携は必然でした。
製品のそばで操作するのではなく、
身近な手段であるスマホが場所を選ばず遠隔から操作できるようになりました。


いつでも傍にいるスマホ

昨今、若者にとっての恋愛感は、
リスクが高くドライで優先度が低い認識として広がっております。

実際のところはどうなのでしょうか…?

個人にとって、不安で気の乗らない状況はデメリットで不明確ですから、
いつでも明確なやり取りが可能な状況のほうが都合がよいメリットとなり大きな安心を感じさせます。

必要なときに誰とでも繋がれるので完全な「独り」の状況がなくなりました。
一人でいられる時間が苦痛ではなくなり、万が一文句を言われても遮断できる環境になりました。

本来、面倒を掛け合う助け合いで成り立つ人間関係の頻度は日常では減少、隣近所の気遣いも気薄になり、
さらに、思い通りにならない煩わしい異性との付き合いは、
ネガティブのリスクがあり面倒な対象となっていると考えられます。

大げさですが、
「頼りになるのはスマホ」
の感覚は広がっているのではないでしょうか。


ドラマにならないスマホ

スマホが入り込んだ利用シーンは、本や映画やドラマなどの現代劇を扱う場合にももちろん影響が出ます。

あらゆることが瞬時に解決できてしまい、
単調なメッセージのやり取りで終わるシーンの連続になる状況も危惧できますし、
推理ドラマの犯行状況にも影響が多々ありそうで要らない心配をしてしまいます。

また、
一つの作品のなかに必ず登場するスマホには、
作品製作に協力する製品企業の存在もあり、権利問題が膨らみます。

時代の変化ですが、
シンプルなミニマルスタイルがデザイン分野で進むなか、
我々の利用シーンもシンプルな一極化を進んでいるのではないでしょうか。


束縛するスマホ

スマホはあらゆるニーズを取り込んでいます。

電話/メッセンジャー、Web閲覧、カメラ、ビデオ、音楽プレーヤー

また保存したデータは、紐づいたクラウドに格納されており、
悪い言い方をすれば利用者の大切な情報を「人質」として委ねています。

この束縛は非常に拘束力が強く、
なかなか競合他社への乗り換えや別カテゴリのデバイス移動など、利用者の自由な選択肢の妨げになりつつあります。

委ねれば楽ですがそれで良いのでしょうか。


まとめるのもスマホ

電気、固定通信回線、携帯回線、すべてが一つに集約契約促進されている部分も拘束と考えられますが、
シンプルになりすぎた利用シーンには、万が一問題や変更が必要な状況ではリスクとなります。
後戻り出来るかは利用者次第という余地は残されておりますが、どれだけの人が対応できるリテラシーを持っているのでしょうか。

携帯電話がある利用シーンについては、

「携帯電話があると便利だね」
     ↓
「携帯もってる?」
     ↓
「え!?ケータイ持ってないの!?」

と時代の流れで人々の考えが変化してきたように、社会に出た場合はそれらの余地が少ない現実を受け止めなければなりません。

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

スマホが速度制限でもストレスのないWEBページについて

現在主流の4G通信回線の実行速度は、
15Mbps(15,000kbps)程度といわれています(規格上は150Mbps~225Mbps)。
※「bps」=バイト・パー・セカンド/1秒間に受け取れるデータ量

そんな中、利用者は、契約ギガバイト数を超過すると厳しい速度制限を受けることになりますが、その「128kbps制限」を体験している利用者は65%程度いる様ですので見過ごせません。
※『スマートフォンに関する意識調査』NTTコミュニケーションズ調べ

今回はそんな方のなかでもデータ容量の追加購入せずに月末を乗り切る利用者を考慮して、
「128kbps制限でもストレスの少ないWebページ」
を考えてみました。


回線速度の変遷リスト

まずは、通信の歴史、
固定電話回線と携帯電話回線の変遷をリストにしました↓


<固定電話回線>

電話回線(アナログ回線)1990年代  ※銅線
28.8kbps

ISDN回線(デジタル回線)      ※銅線
64kbps/128kbps(2チャンネル時)

ADSL回線              ※銅線
512kbps/47Mbps

光回線               ※光ファイバーケーブル
100Mbps前後


<携帯電話回線>

3G回線
2Mbps程度(実行速度)(規格上数Mbps/14Mbps)

4G回線
15Mbps(15,000kbps)程度(実行速度)(規格上150Mbpsや225Mbps)
速度制限を超えると通信速度が最大128kbpsに制限

※記載の速度実数値は参考程度となりますのでご了承ください。


上のリストは1990年代から「通信」を経験してきた年代には懐かしく、若年層には見慣れない項目が多いと思われますが、
制限状態にある「128kbps」という通信スピードがいかに遅い回線状態だったか理解いただけるのではないでしょうか。


128kbpsでできること

それでは速度制限を逆手にとって、
制限中もストレスなくサービスを利用出来ないかと考え、
分析を進めてみます。

まずは過去のFP時代のページ総容量レギュレーションを確認してみると…

・1ページあたりの容量は100kバイト以内(※概ねの指標)

とありますので

128kbps制限下でも、容量数字上は2秒もあれば表示されます。

FP(フィーチャーフォン)向け程度のページ情報を表示する分には十分なスピードです。


文字中心のページ製作へ

テキストは1文字につき、

・半角英文は、1バイト
・全角が必要な日本語は、2バイト(アジア地域などは「2バイト圏」と呼ばれます)

容量を使います。

単純計算すると、
128kバイトであれば、タグやスタイル、JavaScriptを含めて、
128,000文字の文章が書けます。
ブログ記事は2,000文字(4kバイト)程度が多いので、テキスト本文だけで考えると十分足りる計算です。
今回、
1秒程の読み込みを目指すのであれば、
タグや画像に、残りの124kバイト使用できます。
読み中心の静的ページであれば十分なのではないでしょうか。

さっそくサンプルページ作りを始めます。


読み物中心のページを作る

画像を載せる場合は容量制限を設定し、
大きすぎず適切な減色による容量削減が必要です。

ポイントとしてこちらでしょうか。
・グラデーションは使わない
・PNG8形式(インデックスカラー)で保存
・CSSスプライトで画像を1ファイル化(アクション発生件数を減らす)

今回、この記事ページ自体をサンプルとして扱い、使用画像含め128kバイト以内で作りました。
本文テキスト部分の文字数は2,000文字程度です。

ページ内容のみの容量は25kバイト程度ですので、
通常の電波状況ではストレスなく表示が出来ると思われます。


最後に

動画や画像中心のリッチなコンテンツページは、128kバイト以内では作れませんが、
制限下でも情報を問題なく表示できるページ作成は可能です。

ここまで詰め切る需要も少ないと思われますが。
FPのころの通信インフラにやさしいエコなサービス作りに挑戦するのも新鮮ではないでしょうか。
是非お試しください。

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

カルーセルパネルとは?注意すべきユーザビリティーのポイント

カルーセルパネルとは?

カルーセル[carousel]パネルとは、
複数画像を左右にスライドさせることで表示させる展開(回転)構造を持ったWeb/UIコンポーネントです。


スマートフォンが登場した黎明期から、
カルーセルパネルはナレッジと予見が必要な敷居の高い機能であった為、PC/スマフォでの使用には賛否がありました。
特に最終スライドまでの認知は、構造上少なくなっていく傾向は止むを得ません。

実装は「jQuery」で、Webデザイナーでも簡単に組み込めることから広く利用されておりますが、
理想のカルーセルパネルソースに出会えず、適切に運用されていない状況もあるのではないでしょうか。

今回はそんなカルーセルパネルを有効活用するためのポイントを紹介致します。


使いやすさのポイント

単純に単体静止パネルとして素通りされてしまうのが一番の問題なので、気付きのアピールが必要です。

1. ちょい見せ

「単体パネル」ではなく「複数パネル」であることを認識させる表現にする。

2. 手動+時間での切り替え

停止したままではなく、一定時間経過で自動的に動かすことで複数枚を認識させる

3. 全体数の表示

全スライド数を認識させる

4. ポジション

現在のスライドの表示順番を認識させる

5. ループ

最終スライドから先頭へ戻る(ループする)ことを視覚的に伝え、最初のスライドに手早く戻れることを認識させる。

以上に上げたポイントが一つでも十分でない場合、格納されたスライドの全てを認識させるのは難しくなります。


カルーセルパネルの動きをプロトタイピング

「jQuery」などオープンソースから理想の表現が出来ているカルーセルパネルが見つかれば話は終わってしまいますが、探すにも時間がかかるのではないでしょうか。

それでは、カルーセルパネルの内容や動きが確認できるプロトタイピングして具現化してみます。

デザインも出来て、JavaScriptが出来るWebデザイナーなら問題ないのですが、壁がとても高いと思われます。
そんなプログラムに精通していないデザイナーでも作れるツールが、過去の記事紹介している「Adobe Animate CC」です。

グラフィックUIの操作で作れるためデザイナーに相性が良く、
ある程度のJavaScript命令文を項目を選択するだけで記述出来、厳密に構文を覚える必要がありません。
「再生」「停止」「任意のポイントに戻る」「条件分岐」「繰り返し」
以上を組み合わせるだけでも、
プログラマーやプロジェクトメンバーに動きを確認してもらえるプロトタイプを作ることが出来ます。


早速作る

まずは基本的なレイアウトに「ちょい見せ」搭載したプロトタイプです。
クリックでしか動作が出来ておりませんが、回転してグルグルと回るカルーセルパネル本来の動きが確認できるのではないでしょうか。
クリック/タッチで動かせます↓


プロトタイプならではのバリエーション

追加で2種類のデザイン案も作ってみました。
クリック/タッチで動かせます↓

動きの想像が出来、ついつい回してしまいたくなる表現なら有効です。
クリック/タッチで動かせます↓


プロトタイプならではのバリエーション

追加で2種類のデザイン案も作ってみました。

動きの想像が出来、ついつい回してしまいたくなる表現なら有効です。


最後に

いかがでしたでしょうか。
オペレーションソフトやブラウザ速度の向上した現在では、多くの表現がWeb上で可能となっております。
Webデザイナーに求められるスキルも必然と増え、インタラクティブな動的コンテンツが求められてきていると感じています。

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

Apple Pencilに欠かせない120Hzの画面リフレッシュレートとUX

私たちが普段眺めているスマホやタブレットの画面ですが、
実は、操作してない時でも頻繁に画面を書き換えています。

画面を書き換え(⇒リフレッシュ)しているということは、
常に貴重なバッテリーを消費しているので、その部分だけ聞くとエコではありません。

スマホなど、使用開始から2年目に近くなると著しくバッテリーの劣化を感じますが、
出先での充電も面倒ではあるので、
可能であれば何とか温存して一日持たせたいところです。

そんなネガティブな話題から入りましたが、
リフレッシュレートの機能の恩恵は大きく、私たちの使用感/満足度など、
UXに大きく影響を与えます。

今回は機械的な話に寄りますが、
この(単位時間で画面をリフレッシュする⇒)「リフレッシュレート」の話をUXと絡めて考えてみます。


■リフレッシュレートとは?

一般的な説明として、リフレッシュレートとは、
1秒間にスマフォやテレビなどの画面を何回書き換え更新するか、の理解で良いと思います。
機器の仕様書には、

60Hz(ヘルツ)だの120Hzや最近ですと240Hzなんて数字も確認できます。

つまりはスマホの画面が一秒間に60回だったり120回だったり240回、
最新状態に書き換えしてる端末がそれぞれあるということです。
忙しくエネルギー使いまくってそうですね。

では日本でも売れているiPhoneやiPad Proの仕様についてみてみます。


■iPhoneやiPad Proのリフレッシュレートは?

・iPhone   60Hz
・iPad Pro  60Hz(可変リフレッシュレート)

でした。 ※2017/6/6時点発売済みの端末

ロック画面の静止画状態でも、1秒間に60回も書き換えているなんて、環境に申し訳ないですね…。
バッテリー消費もしているので使用者のメリットもありません。
これは良くない体験の様です。

でも…『iPad Pro』の仕様をよく見てください。
”可変リフレッシュレート” となってます。

『iPad Pro』の可変リフレッシュレートですが、
実は利用者が操作していない状況を判断して、
リフレッシュレートを低く[30Hz(30回書き換え)などに] 変更させているんです!
画面を操作していないときはエコモードになるなんて、
見えないところでもユーザーに恩恵を与えているんですね。
バッテリー持ちを良くするための機能だと思いますが、
双方にメリットがあり、
これは良い体験なのではないでしょうか。


■新型iPad Proの仕様

2017年6月6日、Appleは、
同社の開発者カンファレンス「WWDC17」の基調講演で、
「iPad Pro」シリーズの刷新を発表をしました。

・iPad Pro  120Hz [可変リフレッシュレート(48Hz/24Hzなど)]

こちらの製品の仕様では、
リフレッシュレートが大きく向上して120Hzに変更されました。
目的としては、「Apple Pencil」の体験向上が上げられ、
レスポンスが快適になるとのことです。

仕様上だけでもペン先への描画追従性が倍に上がるので、
”書き味”に大きな変化が現れることでしょう。

またリフレッシュレートの向上は、
画面スクロール時にも影響が出ると判断でき、
ヌルヌルとしたスクロールになることで、文字の視認性が良くなるのではないでしょうか。

大きな使用体験の変化は新たな需要を生みます。

「読む/見る」といったニーズでは行き渡った感があったタブレット端末ですが、
「描く/伝える」といった新たな体験と価値を提供するツールとして、
新しい市場を開拓するのではないでしょうか。

■今後のリフレッシュレートの向上について

モバイルツールとして120Hzのリフレッシュレートを実装してきましたが、
コンシューマ向け「据置型モニター」での市場では、
240Hzの領域まで量産技術が進んでいます。
さらに、
人間の目で判断できる限界(140~200Hzという説)もあり、
240Hzあれば十分なのですが、
ホールド型液晶画面は仕様上残像の問題が出るので、
その点をカバーする目的で、
高速にリフレッシュする480Hzまで行きつく必要があるのではないでしょうか。
表示応答性に優れた「有機ELディスプレイ」との組み合わせも考えると未知の領域ですが、
スマホでヌルヌルとスクロールしながら文字を速読する、
そんな体験が出来る時代までもう少しです。

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

Adobe Animate CC 2020 HTML5 Canvas シンプルゲームサンプルの作り方


今回は、アイデアとイメージを第三者に効果的に伝える目的で、ブラウザゲームのサンプル/プロトタイプを作ってみます。

ツールは『 Adobe Animate CC 』(旧『Adobe Flash Professional』)を使います。
Flash時代は「ActionScript」でしたが、Animateで「HTML5 Canvasドキュメント」を製作する場合は「JavaScript」で制御を行います。以前と同じオペレーションなのでインタラクティブなwebページが作れるメリットは変わりません。

それでは、その昔、デパートやバッティングセンターで遊べた『山登りゲーム』風の簡単UIワンボタンゲーム、
こちらの↓『山田ノボルゲーム』を作りたいと思います。




■まずは設計

必要スキルですが、
極初歩的なJavaScriptの知識が多少あればグラフィックデザイナーでも直感的にグラフィカルな制御ができるのでおススメです。

まずは遷移図がこちら↓

なんと要素の少ないことでしょう;
しかしながら、
これらの内容全てを盛り込める時間もありませんので、
形に出来るように取り組んでまいります。

遷移図を見る限り、単純な「if文分岐」で作れそうです。

「ランキング」機能については、実現は難しそうですが、
今回の目的は、
短い期間でアイデアを展開出来る形に落とし込むサンプル(プロトタイプ/プロトタイピング)ですので、
やりたいことのイメージ/ビジョンが、
第三者に伝えられる状態になっていれば問題ありません。
最低限伝えたい雰囲気だけは再現していこうと思います。

時間が限られていますので急いで進めていきます!


■画面イメージを起こす

早速『 Adobe Animate CC 』に組み込む画像を作ります。

遷移図を参考に、各ページを『illustrator』で作ります。

アートボードを画面単位で運用ファイル名をつけて設定してしまえば
ワンアクションで全てのページが書き出し出来て便利です。
したがって、必要な画面のブラッシュアップは適宜おこなえますね。
本当に便利です。

ゲームをプレイするターゲット(今回は1970~80年代の古き良き遊び世代)に好感を持ってもらうため
液晶/LSIゲームの表現を取り入れてます。
ターゲットの懐古UX度上げていきます。

※今回は単純な内容なのですが、
「ユーザー・エクスペリエンス(ユーザー体験)」を重視しています。


■いざ組込み素材の書き出し!

必要な画像が揃ったので書き出しします。

⇒ファイル/書き出し/スクリーン用に書き出し…
です。

今回の作業は「横幅375px」で『illustrator』上で作業をしてますので、
ターゲット端末(iPhone6 サイズ 横幅750px)で使用した場合も必要な解像度が得られるように、
「x1」(倍)から「x2」(倍)に切り替えて書き出しします。
※「iPhone6 Plus サイズ 横幅1242px」がターゲットの場合は横幅414pxで作り「x3」(倍)

それではポチッと書き出し…

…細かい部品も含めてワンアクションで書き出し完了でリネームも必要ありません。
便利です。

さぁ!時間がありません!

『 Adobe Animate CC 』で簡単プロトタイプを製作するために組み込みしましょう!


■『 Adobe Animate CC 』での組込み

※オペレーションは割愛させてください
『Adobe Animate CC』の使い方についてはこちらの記事にて紹介してます。
↓ ↓ ↓ ↓ ↓
『Adobe Animate CC HTML5 Canvas キャラが画面横断するバナーの作り方』

組込み方はFlash時代と変わりありませんので、
ライブラリに格納した画像を「ムービークリップ」にそれぞれ設定しましょう。

ステージサイズはWeb表示時に一画面に収めたいので375×554(くらい)。

スクリプトのレイヤーを作ってJavaScriptはまとめて記述しましょう。
基本遷移アクションのスクリプトは項目を選ぶと自動である程度書き込まれます。
楽々ですね。

あとはスライドショーをつくる感覚でタイムラインを制御して実装を続けるとサンプルゲームの完成です。




※あくまで製品雰囲気を伝えるサンプル(プロトタイプ)なので、
挙動や当たり判定の完成度には期待しなくて問題ないです。

十分、提案したい内容は伝わるのではないでしょうか。

今回のサンプル(プロトタイプ)では再現出来ていない「スコア」、
「スコアの違いを生む要素」、共同体験が可能になる「ランキング機能」などは、
より良い体験(UX)に繋がる要素です。

是非、アイデアを形(サンプル/プロトタイプ)にして、
より具体的な提案をしていきましょう。

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

UX設計_接触ポイントと必然的な利用シーン

あなたが関わっているサービスの、UX設計上の「利用シーン」はどんな状況でしょう。

「テレビで聴いた楽曲を購入したくなったとき」など唐突にサービスを使用している場面が多いと思われますが、
初めてサービスに接触する「その時」の環境と需要を意識出来ていることが重要です。

と、さすがにこんな具体性なく都合よくあなたの関わるサービスを見つけ使ってくれる状況は、そこまでに至る過程を省きすぎだと理解いただけるとは思います。

「何に困っているのか」「何を欲しているのか」「どう接触してきたのか」
という利用者の抱える問題を踏まえた「必然的な利用シーン」がある上でサービスのUX設計をしていく必要があります。

今回は、
「ペルソナ設定/行動シナリオ」の設計フェイズでも方向性がぶれないように
開発起案段階での「環境」「需要」などの「接触要素」と過程の理解を考えてみます。


環境ありきの「接触」

サービスと利用者が「接触」できる環境(状況)を正しく認識するために「ターゲット」を知る必要があります。

近年、マス(大衆/集団)だけでセグメントをすることは適切でなくなり、
「何」に関心があり何に関心が無いのか、
また、どういった移動手段をつかうのか、どういった趣向をもっているのかという、「心理的変数」「行動変数」など動向別にセグメントすることが有効になってきました。

「心理的変数」
・価値観、ライフスタイル、性格、好み、将来の希望

「行動変数」
・利用方法/手段、購買意欲、購買履歴、商品への忠誠/親密度(ロイヤルティー)

上記のワードを常に意識してサービス起案の方向性を決めていれば、
提供者視点を避けられそうです。

つまり、
人々の考え方を神のように常に把握していれば「究極マーケッター」に成れそうですが、現実は難しいので仮説の元、細々と都度データで確証を得てターゲットの行動を理解していくしかないようです。
地味な作業がやっぱり大事なんですね。

ターゲットの行動が見えてくると、どのような環境下でサービスとの「接触」が行われるかが見えてきますので、
初めてサービスに接触するその時の「利用シーン」の具体的な過程がわかってくるのではないでしょうか。

下記は、
ブランド・ロイヤルティなど、
状況によって「起こり得る/起こり得ない接触」「環境」の例です↓


「隠れた需要」との接触

「需要」を考える場合、ユーザーから直接聞くことが適切と思われますが、
その「聞き出した需要」はそのままでは必ずしも適切ではない場合が多いようです。

私たちが世の需要を掴みにくい状況は、「利用者側が発する声」にも表れ、
本人も本質が見えていないため、例えば、必要だと思って買った商品が結局使われないまま埃をかぶることは良くあることです。

その時の状況を思い返すと、
単純にタイムセールの商品で限定感で買ってしまったり、
モデルやタレントへの憧れから同じ洋服を買ってしまっていたり、
忠誠心/信仰心から、同じ系統(系譜)の商品を惰性で買っていたりと、
つまり「間接的な要因による需要」があることを認めざるを得ないわけです。
よって、「利用者の声」には「本当の需要」が隠されています。
一度寝かせて落ち着いたタイミングで、広い視点で分析、有効活用していきましょう。

必然的な利用シーン

以上を踏まえて、改めて冒頭の利用シーンを考えてみると、下記のような行動をする利用者も設定できるのではないでしょうか(あくまで手段の一つ)。

上記は今回の説明のために極端にセグメントをして必然性を上げているので母数は限られますが、
具合的な接触ポイントの必要性を理解いただけるのではないでしょうか。

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

複数人体制によるUXのスケジュール進行


ユーザー・エクスペリエンス(以下UX)の概念を解説されても、具体的に日々の業務に何がどう関係していて、どう進めるのか行動に結びつかないものですよね。
また、何とか概念を理解出来ても環境や開発体制、会社の文化などによって導入が難しかったりする場合が多いのではないでしょうか。
厄介ですねぇ。

今回はそんな厄介UXを何とかスマートフォン向けサービス開発に当てはめて都合よく解釈してスケジュール立て/複数人体制によるスケジューリング導入出来ないか考えてみました。


UXってどういうこと?

そもそもUXの目線でサービスを設計するということを大雑把に短く言葉にすると、
ユーザーの需要があり、
ユーザーの目線で提供され、
ユーザーの望むゴールが達成できて、
ユーザーが心地良い!素敵!と感じてまた利用したいと思う設計を、
関わるプロジェクトチームメンバー全員が統一意識で、効率的に精度高くポジティブに開発を進めることと解釈してます。

一番重要なポイントは、
「だれに」向けた「需要」あるサービスなのかを明確に設定することで、この設定次第でサービスの成功が決まるのではないでしょうか。

以上を踏まえて、
「なにを」「いつ」「どこで」「なぜに」「どのように」提供するかを考ることでユーザー体験の設計が行えるはずですが、
ここでUX開発を難しくする環境の問題が出てきます。

実際のサービス開発では、何を売りたいか、どんな手段で提供したいかが、サービス側の事情から既に決まっている状態から企画がスタートすることがあり、その状態ではユーザー目線と需要から起案されることがそもそもないことです。

どんなにUX設計を心がけたとしても、
「ビジネス目線」からスタートした企画には、後付けでUXを適応する事は出来ないと考えておいた方が良いのではないでしょうか。

それでは、UX開発を具体的に設定してみましょう。


チーム内の役割を再認識する

UX設計のフローと、関わるメンバーのスキルについて整理してみます。
フローの内容と、それぞれの担当がプロジェクトに参加するタイミングを表にしてみました↓(注>あくまで弊社環境の場合です)

いかがでしょう?
まだまだ書き込む詳細は残っているので今後も表の最適化を進める予定です。

表のなかで注意が必要なポイントは、
会社やプロジェクトの規模、外部協力会社によって、担当欄一人それぞれの活動範囲に違いはあるところです。

中小規模プロジェクトであれば、幅広い工程を一人で担当することもあり、
大きなプロジェクトであれば、外部の協力会社も入り、各工程を専門スキルに特化した活動を分担して進めることになります。
専門スキルに特化するということは、難易度の高い設計がそれぞれに求められ、広く浅いスキルでは対応できない状況が多いのではないでしょうか。

それでは、ご自身の状況を重ねてみてください。

敢えてネガティブに例えると、
「プランナー」の立ち位置の方はほとんどの工程に関わりますが、
1人で黙々と設計を進めて結果を関係者に共有する流れが多いのではないでしょうか?
専門スキルをもつ各担当者と一緒に具現化作業を進め、多くの機能や仕組みを提案してサービスを充実させていくことが重要なんですが、なかなか責任感が柔軟的方向性を見えにくくします。

逆にプランナー以外のメンバーは、「サービスの製作には協力している…」という他人事意識になりがちな部分…あるのではないでしょうか。
どうしてもどこかで最終的な責任は関係しないという考えが消えずに協調性が不足します。

それぞれの立場が
「私(誰か)の考えたサービス」
の意識が無くならないかぎり、その視点で開発が進むと「複数人体制によるUX開発」には到底ならず、
提供者側視点/ビジネス目線の、
マス(大衆)に向けたサービスから脱却はできないと考えられます。

その状態では今の時代の「有効ターゲット」に届かないから、UX設計が必要になってしまっているんですね。

UX設計は先ほどお伝えした通り、
「プロジェクトチーム単位」複数人体制で進める必然がある以上、
メンバー全員の意識統一が重要なのです。

「私達が考えたサービス!」

…声に出すとなかなか恥ずかしいものですが、割り切って声高らかにポジティブ意識をもってサービスのUX設計を進めてみましょう!

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

検索について

こんにちは。今回のブログ更新担当のデジマースのはらです。

皆さんはアプリやwebサイトで欲しい商品や見たいコンテンツなどがある時、どのようにして探しますか?「新着」ページや「人気」ページ、あるいは「おすすめ」などから探しますか?
最近流行している商品などは、大抵どのサービスでも目につくように紹介されているので、上記の方法ですぐに見つかるかもしれません。
しかし少し古い商品、あるいはマニアックなコンテンツなどはすぐには見つかりません。そんな時、皆さんはサイト内で何をしますか? おそらく「検索」を行いますよね? 虫眼鏡のアイコンやテキストフィールドを探しますよね?
と、いうことで今回は「検索」について紹介していきたいと思います。

代表的な検索方法は?

代表的な検索方法は2つ、「キーワード検索」と「カテゴリ検索」があります。今回は見せ方や関連の機能も合わせて解説して行きたいと思います。


1.キーワード検索

読んで字のごとく、入力されたキーワードを基に情報を検索する方法です。キーワード検索は意外に難しく、慣れている人は多いのですが、普段アプリやwebを使わない方には高度で、本当に必要な情報を引き出す言葉を見つけるには慣れが必要です(慣れていても検索ワードを絞る事は難しい時があります)。少しでも検索を簡単にするためには、ローマ字・ひらがな・カタカナなど、どの入力方法でも検索できたり、検索候補の表示(サジェスト表示)されることが望ましいです。

検索ボックスの位置
商品やコンテンツの多いECサイトでは、サイトTOPに検索ボックスを配置することが望ましいです。なぜかと言いますと、「これが欲しい」と目的を持ったユーザーは、まずはじめに目当てのものを探すからです。その際に検索機能がサイト下部やメニューの奥に隠れていると、使用するたびにストレスになってしまいます。ですので特別な理由がない限りフッターや本文への検索ボックスの配置は避けたほうが良いです。(検索結果に情報が引っかからなかった場合のために検索ボックスをフッターに配置する事は問題はありません)
TOPに検索ボックスがあれば、慣れているユーザーには自然で使いやすくなります。また、不慣れなユーザーにとっては見つけやすい位置となります。

検索ボックスのデザイン
キーワード検索は通常テキストフィールドとボタンで構成されています。検索ボックスのデザインは、視認性が高い事が重要で、特にテキストフィールドの視認性が悪くならないように気を付けてデザインすることが重要です。検索開始を決定するボタンには「検索」「GO」「SEARCH」「虫眼鏡アイコン」などの文字・アイコンが一般的に使用されています。また、検索ボックス内にボタンの要素は含めず変わりにキーボードの決定ボタンで検索を開始するパターンもあります。


2.カテゴリー検索

カテゴリ検索は「バラエティ」「スポーツ」「ファッション」などに分けてまとめられた情報を、目的の情報まで選択して辿っていく検索方法です。ユーザーがキーワードを考えたり文字入力をする必要が無いため、分かりやすくカテゴリ分けされていれば、効率よく目的の情報までたどり着けます。カテゴリの分かりづらいものが多い場合に使用するとかえって使いにくくなってしまいます。

カテゴリ検索のデザイン
カテゴリ検索の見せ方や仕組みはサービスによって大きく変わってきます。シンプルなカテゴリ検索の場合、カテゴリの大項目にアイコンを使用したり、文字のサイズを変えてメリハリをつけるとより直感的に伝わり、使いやすくなります。

関連機能
カテゴリ検索時に、カテゴリ内の検索数を表示する機能を「ファセットカウント」と呼びます(例1)。これによりユーザーは求めているカテゴリの検索結果をページ遷移を行うことなく確認する事ができます。他には、検索時に「価格、色、サイズ、性別、機能」などの複数の条件を指定して結果を絞り込む「絞り込み機能(例2)」があります(そのままの呼び方ですね…)。

 


検索は便利です。しかし、めんどくさい作業です。検索機能は「手間が少なく正確で、目的のものに最短でたどり着ける」という事が重要です。位置や仕組を工夫して使ってもらえる検索機能にしていく事が大切です。また、検索機能の改善はすぐに大きな成果につながるわけではないのですが、こうしたユーザビリティの改善がサービスの印象を変えます。検索機能を実装しているサービスがある以上、実装していないと「こんな機能もないのか…」思われてしまうかもしれません。

【Adobe Animate CC】Flashとの違い_進化したWebアニメーションツールとは

今回はWebの一時代を華やかに着飾った「Flash」の、代表的な制作ツールの進化(需要対応?)についてです。


そもそも「Flash」とは?

元々は旧Macromediaが開発したインタラクティブWEBアニメーションファイルを制作するツールで、
現在はAdobeに吸収されています。
Webページの切り替えにオーバー表現なアニメーションが展開されたり、アーティスティックな個人WebサイトのUIでは目を奪われる表現に使われたり、さらには、YouTubeなど、Web動画再生の仕組みにも過去使われていました。

そんなFlashの制作ツールはタイムライン制御GUIによる直感的な操作が特徴で、
JavaScriptやhtmlなどが苦手なWebデザイナーでも簡単にアニメーションが作れたことで大変支持を得たのです。

「Flash」で出来ること

また、
特に独自のActionScriptを使用することでインタラクティブな制御か可能となり、
プログラムスキルがあればFlashアプリも作ることが出来る特徴があります。

近年では、SEO対策や脆弱性問題とブラウザ組み込みプラグインという特性上から標準搭載されなくなっている傾向もあり、
AdobeはFlashを「2020年末に終了」を正式発表しております。

時代の流れにも対応

そんな、Web業界で余命を宣告されたFlashのオーサリングツールである「Adobe Flash」ですが、
ツールの名称を「Adobe Animate CC」に変更して開発が継続されることになり、世のフラッシャーに希望を与えました。

違いは、近年対応を進めてきた「HTML5 Canvas」機能の正式実装によるJavaScriptアニメーションアウトプットを全面に押し出したコンセプト変更です。

「Adobe Animate CC」の活用

個人的な意見を述べるのであれば、
デザイナーが慣れ親しんだこのオーサリングツールを、
最終的なアウトプットやコンテンツを制作する目的に限定するのは大変もったいないので、
UIの確認を行う「プロトタイピング」の工程で大いに活躍することが出来ると考えています!

UX全体を考慮するのであれば単純な画面遷移アニメーション(トランジション)具合も重要なサービスの振る舞いになってきますので、
「静」でなく「動」の表現を企画者や開発者に伝える手段として適切なツールなのではないでしょうか。

「Adobe CC」を導入している環境であれば「Adobe Animate CC」を是非活用して、
プロジェクトメンバー間で、プロトタイピングによる使用感の共有を進めてみてください。

「Adobe Animate CC」を使った広告制作の紹介はコチラ↓

簡単!『Adobe Animate CC』の使い方_HTML5 で広告作り

次回も日々変化するWeb制作環境などにスポットを当ててご紹介します。
サービスデザインに関わっているデジマースのネモトでした。

サービスコンセプト運用中の注意点【顧客目線と営業目線】

今回は「サービス運用中の注意点」の説明をしたいと思います。


顧客目線と営業目線

サービス設計中は「UX」や「顧客目線/ユーザー中心設計」を重視して開発が進められていますが、
サービス開始後の運用(日々の運用/追加機能開発/施策の投入)ではどうでしょうか。

プロジェクトメンバーと相談が出来ないままサービス変更が続き、それが習慣化して「営業目線/売り手目線」が続くとユーザー体験に大きな問題が発生していきます。

おざなりになる顧客目線

スマートフォン向けの月額定額/サブスクリプション対応サービスでは、サービスへのアクセスがレベニューシェアの成果となるため、多くの対象サービスでは利用者をアクセス直後、他サービスへの流動遷移によって促します。
これは利用者からみた場合「顧客目線」とは別角度の「売り手目線」、売り手都合となります。
結果、別サービスへの「離脱」を優先度高く促され、求めた需要は達成しにくい状況となり、ユーザー体験が著しく阻害されています。

「どのようにすれば利用者は、こちらの求めた行動をしてくれるのか」

この考えは営業目線上にある顧客目線であり、それはアンチ顧客目線なのです。

160713_01

利用者需要と優先度を保った施策の組み込み

それでは、営業目線での施策そのものに問題があるのでしょうか?
問題があるとすれば、サービス設計/ユーザー体験を踏まえない独立した施策にあります。

利用者がサービスに求める需要達成に干渉しない施策であれば、ユーザー体験を阻害することはないからです。

考えられる利用状況として2つ想定出来ます。

(1)はじめてサービスに訪れた利用者が、内容をある程度確認した状態で、自分に向いたサービスではないと判断

(2)サービスを継続利用している利用者が、今回の需要/目的を達成した状況

表示画面スペースの限られた情報系のサービスであれば、ファーストビューの情報量はUIの命であるため、営業施策は優先度が非常に低くなります。

ただ、ファーストビュー内であってもユーザーの目線/意識が弱い領域が存在します(最上部の狭い空間等)。
(1)(2)の状況を両立できるレイアウトはもちろん理想ですが、
利用者需要を優先しながらも、目立たない傍からそっと付き添う様な営業施策を組み込んでいければ問題ないのです。

160713_02

顧客目線と営業目線の経路設計

道路は、双方の走行車両が決して接触することが無いように、ドライバーが守る交通ルールと経路設計よって安全に作られています。
顧客目線と営業目線についても同じように、お互いを干渉させないルールを設定して、別視点、別経路であるべきです。

また、「離脱/流動」も状況によって発生する利用者のニーズの一つと考えれば、
ポジティブな利用者の行動に物理的に干渉しにくいサービス設計は可能なのではないでしょうか、

「これから進めようとしている提案は本当に利用者のためになっているか」

「今作っている資料は利用者がみても理解される内容になっているだろうか」

会社としてのミッション、営業としてのミッションは、顧客目線を進める上で非常に悩みどころではありますが、
営業側の売りたいものと、顧客の買いたいものは違うものです。

顧客目線を進めながらビジネスとして売上が立っていくビジネスモデルは理想論ですが、
長期的には結局そんなやり方を目指さなければいけないのではないでしょうか。

次回もお付き合いください。