速度制限でもストレスのないWEBページ

Pocket

現在主流の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のころの通信インフラにやさしいエコなサービス作りに挑戦するのも新鮮ではないでしょうか。
是非お試しください。

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

Pocket

スマホ画面サイズユーザビリティ

Pocket

今回はモバイル端末を中心に、「画面サイズ/画素密度と目の距離に関係するユーザビリティと満足度」を考えてみます。

画面サイズと画素密度の相対関係を考えると非常に奥が深く楽しそうなので、まずは個人的に思い入れがある端末でスペック表を作ってみました↓


主要画面表示機器スペック表

スマホ 画面サイズ / ppi リスト

iPhone 3G
3.5 インチ 320× 480  HVGA 163ppi

iPhone 3GS
3.5 インチ 320× 480  HVGA 163ppi

iPhone 4
3.5 インチ 640× 960  Retina 326ppi

SO-01B
4.0 インチ 480× 854  FWVGA 254ppi

IS03
3.5 インチ 640× 960  WVGA 330ppi

iPhone 4S
3.5 インチ 640× 960  Retina  326ppi

iPhone 5
4.0 インチ 640×1136 Retina  326ppi

iPhone 5S
4.0 インチ 640×1136 Retina  326ppi

iPhone 6
4.7インチ  750×1334 RetinaHD 326ppi

iPhone 6plus
5.5 インチ 1080×1920  FHD 401ppi

iPhone 7
4.7インチ  750×1334 RetinaHD 326ppi

iPhone 7plus
5.5 インチ 1080×1920  FHD 401ppi

iPhone 8
4.7インチ  750×1334 RetinaHD 326ppi

iPhone 8plus
5.5 インチ 1080×1920  FHD 401ppi

iPhone X
5.8インチ 1125×2436 SuperRetinaHD 458ppi


ガラケー 画面サイズ / ppi リスト

W11H
2.2 インチ 240× 320  QVGA 182ppi

W52SA
2.8 インチ 240× 400 WQVGA 167ppi

W54SA
3.0 インチ 480× 800 WVGA 311ppi

MARVERA KYY08
3.2 インチ 480× 854 FWVGA 306ppi


ガラホ 画面サイズ / ppi リスト

MARVERA KYF35
3.4 インチ 480× 854 FWVGA 288ppi


携帯ゲーム機 画面サイズ / ppi リスト

Nintendo DSi LL (上画面)
4.20インチ 256× 192      76ppi

Nintendo 3DS (上画面)
3.53インチ 400× 240 WQVGA 132ppi

Nintendo 3DS LL (上画面)
4.88インチ 400× 240 WQVGA 96ppi

Nintendo Swich(携帯モード)
6.20インチ 1280× 720  HD 237ppi


モニター 画面サイズ / ppi リスト

モニター/デスクトップ
24.0 インチ 1920×1080 FHD  92ppi

MacBook Pro
15.4 インチ 2880×1800 Retina 221ppi


TV画面 サイズ / ppi リスト

ブラウン管TV
29.0 インチ  640× 480  SD  28ppi

ハイビジョンブラウン管TV
32.0 インチ 1280 × 720  HD  46ppi

フルHDTV
50.0 インチ 1920×1080 FHD/2K 44ppi

4K TV
60.0 インチ 3840×2160  4K  73ppi

8K TV
60.0 インチ 7680×4320  8K  147ppi


大きさと密度の移り変わり

2001年から3G携帯電話(フィーチャーフォン)がサービス開始されましたが、その当時の画面サイズは下記でした。

--------QVGA端末--------
・240×320 pixel (QVGA解像度)
・2.2インチ
・画像密度は182ppi
---------------------
※ppi (pixels per inch)
1インチ当たりの画素数
数値が大きいほど高精細


現在の端末と比較すると、
四角い大きな画素(ドット)がハッキリと認識できるもので、
いわゆる「8ビット的」な画質制約の中でサービスやその広告バナーを作っていました。

WEBページの容量制限(Web1ページ100KBまで等)もあり、質素倹約の時代だったのです。

その後は画面の高精細化と大型化が進み、「VGA解像度の端末」(QVGAの倍の解像度もつ端末)が登場することで、フィーチャーフォンは成熟期を向かえます。

-------- VGA端末 --------
・480×800 pixel (WVGA解像度)
・3.0インチ
・画像密度は311ppi
---------------------

そして、新しい市場/エクスペリエンスに向けて登場したのがスマートフォンです。

日本ではiPhoneやAndroid端末を発売開始した2010年あたりからスマートフォンの普及が始まりましたが、
大型化した画面と高細化した解像度を十分に処理できるスピードとOSの環境が整うまで時間がかかり、
特にAndroid初期端末の「モッサリ感」は苦い記憶として残っている方も多いのではないでしょうか。

-------- iPhone 6 --------
・750×1334 pixel (Retina HD)
・4.7インチ
・画像密度は326ppi
---------------------


最適視聴距離による体験

それでは本題である「画面サイズ/画素密度と目の距離に関係するユーザビリティと満足度」について「ブラウン管式の家庭用TV」の時代まで戻ってから考えてみます。

過去のブラウン管TVの場合、画面の高さの「5~7倍」離れて視聴する状態が「最適視聴距離」とされてきました。
「最適視聴距離」とは「1ドットを構成するRGB画素」が距離をとることで程よくぼやけ、溶け込み、画面全体が「綺麗な一枚絵」として視聴できる距離とされています。


液晶TV/ハイビジョンTVの場合は(共にフルHDレベルの条件)、ブラウン管(SD)と比較して高精細になった為、画面の高さの「3~4倍」の離れた距離で十分な絵が視聴出来るようになりました。


----最適視聴距離の基準設定要素----
・16:9のアスペクト比
・視野角33度
・視力1.0での走査線識別が出来ない距離
※ハイビジョンTV走査線数(1125本)
---------------------

過去のTVと比較して、液晶TVの画素密度(ppi)は「4K化」「8K化」など高精細化が進んでおります。
家庭環境において意識して見入る映画や鑑賞コンテンツについては、
視野角を踏まえたうえで今後も視聴距離が近くなっていく可能性があります。

それでは、そのTVよりも高精細な画素密度を持つスマートフォンの「最適視聴距離」はどうでしょうか。


スマホの最適視聴距離?

まず、スマートフォンについては「最適視聴距離」の概念は適切ではないと考えます。

理由として、手に持って使用するスマートフォンはTVなどの機器とは利用環境がそもそも異なり、目と端末の距離は常に意識せず一定に保たれています。
距離の違いは身体特徴のほか、近視、遠視、老眼など視力の個人差により出てきます。

目に負担の少ない利用距離の確認方法としては、今回詳しく紹介は行いませんが「ハーモン距離」と言われる距離測定の考え方もあります。

「画面の大きさ」「画素密度」の違いはユーザビリティと体験に大きな影響を与えます。
年齢によってはスマートフォンを使うこと自体が負担となり使いにくい場合もありますので、
自身の環境に適した使いやすい機器を選んでいくことが大切です。


年齢による距離の違い

下の表を見る限り、
「20歳」と「30歳」「45歳」の裸眼状態では文字を読める最適な距離がまず違うことが確認できます。


注目する部分は、「20歳」と「45歳」では距離の開きが3倍近い点です。
既に「45歳」の裸眼状態では、ピントが合わず「近く」が見えにくい為、
腕を伸ばし頭を引くといった、若年利用者とは異なる厳しい使用環境が待ち受けています。

素直に老眼鏡を受け入れる割合も少ないことから、
サービス設計する側は、利用者の大半をも占める興味深いこのターゲット層も踏まえてガイドラインを策定して、適切なサービス設計を行なうと良いのではないでしょうか。


最後に

モバイル端末の普及により目の疲労に拍車をかけているこの現代だからこそ、普段のデスクワークで使用するPCモニターの適切な配置が必要です。
幅広い利用者に向けてユーザビリティを考えていくのであれば、なお大切な心掛けなのではないでしょうか。

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

Pocket

カルーセルとユーザビリティー

Pocket


カルーセルとは?

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


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

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

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


使いやすさのポイント

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

1. ちょい見せ

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

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

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

3. 全体数の表示

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

4. ポジション

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

5. ループ

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

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


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

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

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

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

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


早速作る

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


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

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

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


最後に

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

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


/////////// 関連記事はこちら↓ //////////

『リフレッシュレート』とUX

プロトタイピングに挑戦する

プロトタイピングの活用

Pocket

『リフレッシュレート』とUX

Pocket

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

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

スマホなど、使用開始から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設計に関係した話題をしたいと思います。
以上、デザインに関わっているデジマースのネモトでした。

////////// 関連記事はこちら↓ //////////

プロトタイピングに挑戦する

プロトタイピングの活用


[必然的な利用シーン]環境/需要との接触


UX(ユーザー・エクスペリエンス)を解釈する


サービスVSユーザー!UIリテラシー格差


あぁ…Flashツールに望みはあるか?


8bitに学ぶUIデザイン


サービス運用中の注意点


データとセグメンテーション


サービス立ち上げとデザイン

Pocket

プロトタイピングに挑戦する

Pocket


今回は、
Webサービスのプロトタイピング(ゲーム)に挑戦します。
ツールは、以前にプロトタイピングツールの紹介記事のなかで紹介した
『 Adobe Animate CC 』(旧『Adobe Flash Professional』)を使って、
UXのエッセンスを加えていきます。

現在、FlashとFlash制作ツールは過去のものとなっておりますが、
「ActionScript」から「JavaScript」の制御に変更になる点と、
記述方法の独自の縛りを認識して進めれば、
同じオペレーションスキルで『 Adobe Animate CC 』による、
「HTML5 Canvas 」のアウトプットが作れるメリットがあります。


■まずは設計

私のスキルですが、

・Flashツールのオペレーション
・極少々のJavaScript

程度です。

そんな理由もあり、今回は課金等発生するサービスではなく、
「HTML5 Canvas 」を活かしやすい、
簡単UIワンボタンゲームを作りたいと思います。

まずは遷移図がこちら↓

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

遷移図を見る限り、単純な「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 』での組込み

※オペレーションは割愛させていただけます。

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

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

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

あとはスライドショーをつくる感覚でタイムラインを制御して実装を続けると…

こちらの状態が出来ました。



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

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


■UXを意識した調整

今回の目的に「UX」があります。
画面イメージなど意匠でもUXを意識して制作していますが、
最後に、楽しい体験を演出する表現を追加してみます↓



まだまだ足りませんが、
先ほどの状態より背景の草が動いていて、ポジティブな感情になりましたでしょうか。
単調な内容でも、
目的をより良く導く体験要素を組み込むだけで、
感じる体験の内容が変わってくるのではないでしょうか。

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

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

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

/////////// 関連記事はこちら↓ ///////////


プロトタイピングの活用


[必然的な利用シーン]環境/需要との接触


UX(ユーザー・エクスペリエンス)を解釈してみた


サービスVSユーザー!UIリテラシー格差を考える


あぁ…Flashツールに望みはあるか?


8bitに学ぶUIデザイン


サービス運用中の注意点


データとセグメンテーション


サービス立ち上げとデザイン

<a

Pocket

プロトタイピングの活用

Pocket


スマホ市場も成熟期に入り、コンテンツ配信では競合も多く、
サービスの運営に不安を感じることが多くなっていると感じます。
そんな状況はサービス設計についても従来の設計から変革が必要となってきており、
コンセプトやターゲティング、ビジネスモデル構築に十分な時間をかけて設計を進めるリスクを避ける、迅速な発想の商品化が求められてきています。

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


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

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

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

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

/////////// 関連記事はこちら↓ ///////////


[必然的な利用シーン]環境/需要との接触


UX(ユーザー・エクスペリエンス)を解釈してみた


サービスVSユーザー!UIリテラシー格差を考える


あぁ…Flashツールに望みはあるか?


8bitに学ぶUIデザイン


サービス運用中の注意点


データとセグメンテーション


サービス立ち上げとデザイン

Pocket

[必然的な利用シーン]環境/需要との接触

Pocket

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

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

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

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

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


環境ありきの「接触」

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

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

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

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

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

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

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

下記は、
状況によって「起こり得る/起こり得ない接触」「環境」の例です↓


「隠れた需要」との接触

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

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

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

必然的な利用シーン

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

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

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

/////////// 関連記事はこちら↓ ///////////

UX(ユーザー・エクスペリエンス)を解釈してみた


サービスVSユーザー!UIリテラシー格差を考える


あぁ…Flashツールに望みはあるか?


8bitに学ぶUIデザイン


サービス運用中の注意点


データとセグメンテーション


サービス立ち上げとデザイン

Pocket

UX(ユーザー・エクスペリエンス)を解釈してみた

Pocket


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

今回はそんな厄介UXを何とかスマートフォン向けサービス開発に当てはめて都合よく解釈して導入出来ないか考えてみました。


UXってどういうこと?

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

/////////// 関連記事はこちら↓ ///////////

[必然的な利用シーン]環境/需要との接触


サービスVSユーザー!UIリテラシー格差を考える


あぁ…Flashツールに望みはあるか?


8bitに学ぶUIデザイン


サービス運用中の注意点


データとセグメンテーション


サービス立ち上げとデザイン

Pocket

検索について

Pocket

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

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

代表的な検索方法は?

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


1.キーワード検索

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

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

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


2.カテゴリー検索

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

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

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

 


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

Pocket

あぁ…Flashツールに望みはあるか?

Pocket

今回は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」を是非活用して、
プロジェクトメンバー間で、プロトタイピングによる使用感の共有を進めてみてください。

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

//////// UI系 関連記事はこちら↓ /////////

簡単!ペーパープロトタイピング
カルーセルとユーザビリティー
UIとアニメーションの関係②
『リフレッシュレート』とUX
UIとアニメーションの関係
プロトタイピングに挑戦する
プロトタイピングの活用
[必然的な利用シーン]環境/需要との接触
UX(ユーザー・エクスペリエンス)を解釈してみた
サービスVSユーザー!UIリテラシー格差を考える
8bitに学ぶUIデザイン
サービス運用中の注意点
データとセグメンテーション
サービス立ち上げとデザイン

Pocket