Continued" />

2016年 5月 の投稿一覧

Web制作者が知っておいた方が良いと思う、HTML5ハイブリッドアプリのフレームワークについて

ここのところ、バンクーバーにある専門学校の方とお話することが多いのですが、WEBデザイナーの専門学校なんかの授業でもハイブリッドアプリの科目が取り扱われているみたいですね。最近はWEBデザイナーに必要なスキルの一つとしても、HTML5のハイブリッドアプリ開発は大事になってきてるんじゃないかなと思ったので、これから色々勉強してみようと思っている方向けに最初のとっかかり記事を情報共有として記事を書かせて頂ければと思います。

僕自身もアプリ制作専門で活動したことは無いのですが、最近は「WEBサイト作りましょう」で、モバイルの話が上がる事はほぼ絶対になってきていますよね。で、WEBという媒体を使って何かを提案する姿がWEBデザイナーである以上、そうやってフィールドがモバイルにも派生しているのであればアプリ面の知識も「全く知りませんでした」は正直避けたい所になっていくのではと思っています。

というわけで、今日はそんな非アプリ開発者であってもとりあえずWEBベースのスキルで色々な事が出来るようになってるんだよという、テンション上がりそうな所だけ紹介しようかなってノリで、HTML5のハイブリッドアプリフレームワークを幾つかご紹介出来ればと思います!

Cordova(PhoneGap)について

名前は聞いたことがあるという人も多いかと思いますが、恐らくHTML5のハイブリッドアプリとしては最も有名なフレームワークです。ちなみにCordovaってバンクーバーにあるストリート名の一つで、そのストリートにあった会社がPhoneGapという名前のプロダクトを作っており、PhoneGapがAdobe社に買収された後にApacheに寄贈され、自分たちの会社にゆかりのあるCordovaという名前になりました。バンクーバー市内では実は有名な話だったので、僕は順序的には逆でCordovaの方を先に知り、PhoneGapの方を後に知ったのですが、この2つの違いについては下記の記事が日本語で非常に参考になったので、少し前の記事ですがご紹介させて頂ければと思います(僕は下記の記事を見るまで2つとも一緒だろって思ってた…)。

今日はこのCordovaをベースにしたフレームワークを幾つか紹介したいと思うんですが、その前に、これまでWEB制作者(要するに僕)の目線から見たアプリ開発の経緯を、簡単にですがまとめておこうと思います。皆さんがどう思って見ていたのかは分かりませんが、僕の目にはこんな感じに映っててた的な。

とりあえずイメージだけ沸くようにしときたいある程度の流れ的な

ここからは、僕自身もHTML5ハイブリッドアプリのフレームワークを知ってほしい時に毎回言う事になりますが、これまでもアプリ開発にはネイティブかWEBかと沢山論争されてきました。ネイティブはiPhoneやAndroid毎に専用のアプリケーションを開発するという事になり、動作も早く、データの持ち方もシンプルで良いのですが、iPhoneならSwiftやObjective-C、AndroidならJavaベースと、開発に対するコストが非常に大きく、要するに大変。

じゃぁWEBでいいじゃんってなるんですが、やはり性能差という点ではネイティブに軍配が上がってきました。カメラや通知機能など、WEBだとモバイルデバイスならではの機能が使えない点も大きく、モバイルデバイスからのアクセスステップもネイティブ程確立していないなど、色々議題に上がる部分が大きかったんですね。

その後、4年前の時点ではFacebookがHTML5ハイブリッドでアプリを公開し、HTML5に注力しすぎた的なことを伝えた上でネイティブに移行したことにより、尚更「やっぱネイティブじゃん」な印象が強まってしまった時期もありましたが、当時もザッカーバーグは別にHTML5に未来が無いという話をしているわけでは無く、自身もHTML5の動きには長期的に楽しみであり、HTML5の重要性についてTechCrunchの動画を見てもきっちり言及しています。この時点ではネイティブの方が良いやんという話になる人が多かったようにも思うんですが、得意不得意があったというだけで、例えばFacebookのタイムラインに見られる無限スクロールなんかはその典型だったという事だと思うんですね。

ただ、僕らのようなWEB畑の人間から見ると(…って一括りに言って良いのかわからないんですが)、「やはり今からJavaやSwiftを1から勉強してネイティブアプリの開発に着手するには時間が掛かり過ぎる、単純にだるい。世の中はネイティブだって言うし、もういいや。」こんな経緯があってアプリ開発って面白そうだけど、面倒だなーって人って多かったと思うんですね。実際僕も数年前までは言い訳を自分で頑張って探して作っていたような、そんな感じの体たらくっぷりでした。

特徴さえ知っておけばあらゆる可能性を広げるHTML5ハイブリッドアプリ

最近ってわけでもないんですが、多分ここまで説明したような流れでWEBとネイティブの論争があった中で、ますます注目を集めて来たHTML5ハイブリッドアプリ、WEBからの利用が困難だったカメラや通知機能を利用出来るだけでなく、WEB制作のスキルと知識でほぼ開発出来てしまうという良いとこ取りなポジションですが、それぞれに特徴があり、どれを採用するかはプロジェクトによって考えるべきです。ですが、僕らのようなWEB屋畑な人間からすれば最初の取っ掛かりとして単純に楽しいと思うので、今日はこの部分に注目して最初の触りの部分だけ共有させて頂ければなと思います!

またネイティブと違い個人レベルからの開発も可能である事や、利用するフレームワークによっては丁度良い具合にAngularJSを使ったフレームワークの勉強としても良い題材となると思いますし、Ionicがドーンと登場した辺りからはプロトタイプをハイブリッドで作るという流れもまた一般化しだしているのではと思うので、知っておいて損する事は無いかと思います。

というわけで、突然ですが早速PhoneGapをベースに使い方を見てみましょう。

1.PhoneGapのインストール

PhoneGapはデスクトップアプリとCLIの両方があるので、インストールは楽に出来ます。

PhoneGapの公式サイトからいづれかの方法でインストールしましょう。ちなみにCLIからインストールする場合にはnode.jsとgitのインストールが別途必要です。

英語で良くわからんという方は、こちらでCLIのインストール方法が簡単にまとめられているので参考までにどうぞ。公式サイトからはその後のインストール方法がまとまっているので、簡単に見ておくと良いかもしれません。

2.PhoneGapでアプリを作成

公式サイトを元にしてもらった方が良いのですが、一応英語なので簡単にだけまとめておきます。

2−1.プロジェクトの作成

プラスボタンから「Create new PhoneGap project」を選択し、保存場所とプロジェクト名(フォルダ名になります)を入力。

2−2.アプリの表示

問題無くアプリが起動すると、以下の画面のようにプロジェクトが追加され、画面下にあるアドレスにアクセスするとPhoneGapの画面が確認出来るようになると思います。これで準備完了です。

2−3.モバイルデバイスからの確認

PhoneGapはスマフォアプリも配布しており、デバイス上からの確認も行えます。簡単なステップは本サイトを参照してください。

注意事項としては、モバイルアプリ上のServer Addressとデスクトップ上のPhoneGapのAddressを一致させて置くこと(上記の例なら192.168.0.19:3000)。

3.wwwフォルダ以下を編集し、表示確認

先ほどPhoneGap Appをインストールしたフォルダ内には以下のようなファイル群が作成されているはずです。この中のwwwフォルダ内を編集し、アプリ画面内の編集を行います。

index.htmlを編集すれば当然プレビュー画面も編集されます。

4.PhoneGap/Cordovaベースのフレームワークを使ってみる

個人的にはここからゼロベースで開発していくとテンション上がるまで相当掛かる気がしますが、最近はPhoneGapベースのUIフレームワークも非常に多く登場してきました。ここでは最近注目を集めているIonic Frameworkを使って、一気に「こんな事が出来るのか!」とテンションをあげてみましょう。

Ionicを試すために、まずはGet Startを参考にAppを作ってみましょう。

4−1.ターミナルからIonicをインストール

一応ちゃんと公式から見た方が良いと思いますが、インストールの流れとしては簡単に。

[code]$ npm install -g cordova ionic [/code]

エラーが出る場合は

[code]$ sudo npm install -g cordova ionic [/code]

4−2.任意のフォルダ上からプロジェクトの作成

[code]$ ionic start ionic-sample[/code]

“ionic-sample”の所は自分の好きなように変更。途中ionic.ioのアカウント作成をするかという質問が出てきますが、とりあえずここではnoを選択。

するとこのようなフォルダが出来てるはず。先ほどのPhoneGapで作成したフォルダの構造と非常に良く似ていますね。

4−3.PhoneGap上からプロジェクトを追加してみる

当然、IonicもPhoneGapと同じCordovaベースで作られた物なので、先ほどのPhoneGapアプリケーション上でPhoneGapプロジェクトとして追加しても同じように動作します。

作成したionic-sampleが表示されましたね。アイコンが表示されてないのが気持ちわるい場合は、config.xmlから修正する事も出来ます。以下の行をconfig.xmlの適切な位置に配置してあげましょう。

[html]<icon src="img/ionic.png"/>[/html]

ちなみにこのconfig.xmlはアイコン指定だけでなく、アプリのプラットフォームの設定なんかでも使う事になります。その辺は公式サイトから確認しておいても良いでしょう。

無事追加されていれば以下のようにブラウザからも確認出来るようになると思います。

もちろん、アプリを導入していればデバイス上からも確認可能です。

5.エミュレーターで起動してみる

iPhoneやAndroidを持っていればアプリ上から確認も出来ますが、持ってない方はエミュレーターから確認する事もできます。Get Startページからも確認出来ますが、以下の順でエミュレーターを起動できます。あと、今更ですがコマンドライン/ターミナルの使い方わからんという方は別途ググッて、このあたりを参考に簡単に勉強しておきましょう!

[code]$ cd [プロジェクトフォルダ] $ ionic platform add ios $ ionic build ios $ ionic emulate ios[/code]

Ionicには既にiosプラットフォームはインストールされているかと思いますが、僕の場合は以下のようなエラーが発生しました。

[code]ios-sim was not found. Please download, build and install version 3.0.0 or greater from https://github.com/phonegap/ios-sim into your path. Or ‘npm install -g ios-sim’ using node.js: http://nodejs.org Error: /Users/senna/projects/ionic-sample/platforms/ios/cordova/run: Command failed with exit code 2[/code]

言われた通りに、ios-simをインストールしたら問題無く起動しました。

5−1.Androidエミュレーターを起動してみる

iOSはXcodeのインストールとiOSエミュレーターさえインストールされていれば問題無いのですが、問題はMac上でAndroidエミュレーターを起動する場合。

この場合はまず、Android Studioのインストールが必要ですが、JDKのインストール等で躓く人も多いと思います。こちらの記事がAndroid Studioのインストールを簡単にまとめていましたので、参考までに共有します。

Android Studioのインストールが完了した後に、以下のコマンドを実行してください。

[code]$ ionic platform add ios $ ionic build ios $ ionic emulate ios[/code]

エミュレーターのイメージ(AVD)が見つからない場合は、Android Studio上のAVD Managerからインストール出来るので、試してみてください。

以上が上手く行くと以下のようなAndroidエミュレーターが起動するようになります。

これでMac上でもiOS、Androidのアプリ確認が出来るようになりましたね!

6.Ionicを色々触ってみる

Ionicには既に様々なCSSコンポーネントが用意されており、公式サイトより確認してもらうことが出来ます。

例えば以下のようなコードからアプリのヘッダーデザインは簡単に作成出来ます。

[html]<div class="bar bar-header">  <button class="button icon ion-navicon"></button> <h1 class="title">Header Buttons</h1> <button class="button">Edit</button> </div>[/html]

実際にwwwフォルダ内のindex.htmlから確認してみましょう。

コンテンツ部分ももちろんのこと、簡単なコンポーネントの導入でそれっぽいUIを実現出来ます。

気になるコンポーネント集は公式サイトから確認してみてください!

7.チュートリアルから実際に作ってみる

ここからはどこまでやりたいかだと思いますが、実際にアプリとして動かすためにはJavaScriptを使った設計が必要になります、Ionicの場合はAngluarJSをベースにしている事もあり、どうしても簡単な動作テストのレベルでもAngularJSを多少理解する必要があると思いますが、数あるIonicチュートリアルの中で僕が一番勉強になったのはこちらのチュートリアル。

ゼロベースからIonicを使ったモバイルアプリ制作の流れを理解出来るだけでなく、JSONファイルを読み込んだ簡単なアプリケーションの作成が出来るようになるので、データの扱いや流れの概要を理解するのには持ってこいだと思います。

例えば、先ほどのチュートリアルとWordpressプラグインのWP REST APIを組み合わせれば上のような簡易的なリーダーアプリが作れます。

チュートリアルでは、というよりIonicはAngularJSを採用しているので、JSフレームワークの勉強としても最適だと思います。今回Ionicを最初に紹介させて頂いたのも、こういったチュートリアル等の情報が非常に豊富でコミュニティが広い事が

その他必要となる知識は多いですが、こういった物が作れるようになると想像が付いた上で学ぶのと、何かよくわからない物をつくろうとして学ぶのとでは、習得までのやる気の維持も変わってくると思うので、是非参考にしていただければ幸いです。

その他のHTML5ハイブリッドアプリフレームワークについて

HTML5ハイブリッドアプリについては様々なUIフレームワークが既に登場しています。日本で有名なのはOnsen UIだと思いますが、それ意外の物もこの場で一度まとめておきますので、プロジェクト毎の適切な物を探して見てもらえればと思います!まとめ方は適当ですが…。

Onsen UI

Onsen UIは日本発の世界的に使われているUIフレームワークの一つです。Ionicの競合として見られているフレームワークの一つだと思いますが、jQueryベースのコンポーネントが使われてることから、jQueryユーザーからの指示も高い印象ですね。

Kendo UI

同じくAngularJS、jQueryを使えて70を超えるコンポーネントやBootstrapもサポートしており、使いやすいそうなUIフレームワークの一つですね。

Intel XDK

Intelが提供しているHTML5開発用のIDEで、Cordovaでの開発もサポートしています。またWEBアプリケーションで開発するかCordovaベースでのハイブリッドアプリの両方が開発出来る点は大きいですね。

Sencha Touch

エンタープライズグレードでの利用が想定されているフレームワークですね。豊富なウィジェットと様々なOSに対応しているテーマが魅力的なフレームワークの一つです。

Famo.us

これらもCordovaをサポートしており、AngularJSベースでの開発が可能。また様々な開発者からもパフォーマンスの高さについて得に非常に高い評価を得ています。

Mobile Angular UI

Bootstrap3とAngularJSを採用しているUIフレームワークです。Bootstrapユーザーを使い慣れている方は馴染みやすいかもしれませんね。

以上、いかがでしたでしょうか?

僕自身もまだまだ勉強途中の分野なのですが、冒頭でも述べたよう最近はWEB制作系の専門学校でも多く取り扱われている分野な上に、モバイルの重要性と変化は非常に激しいため、今から勉強しないとなかなかついていくのは厳しいのでは無いかと思い、共有させて頂きました。

プロトタイプをこういったWebViewベースから開発する事も多いでしょう。また、ネイティブ開発をガンガンやってた人のスキルセットの一つとしてこういったハイブリッドアプリの開発を求められることも最近は良く耳にしますし、僕自身もしばらくはどっぷりこっち系の情報収集に勤しみそうです。

今Frogのメンバーの皆さんと作っているアプリもハイブリッドベースで開発を検討しているので、情報共有含めここでまとめさせて頂きました。

それでは皆様、よきハイブリッドライフを〜。

UXデザインを行うときに重要なプロセス

ここ数年でUXデザインという言葉をよく耳にするようになりました。僕自身はこれまで企業のWebサイトやサービスを運用する仕事を中心にやってきたので、言葉の意味を調べると、それが何を指しているのものかは掴めるのですが、同時に、言葉だけで聞くと難しいという印象を受けるので、UXデザインの全体的な流れと、UXデザイナーが何を考えているのか?を共有したいと思います。

僕はそもそも、UXデザインという名称を知ったのが6,7年前の事で、周りもこの名称に対しての認知が無く、僕が自己紹介する場合「Webデザイナーです」「Web担当者として仕事しています」と自己紹介してきました。

しかしその場合、やっている仕事の範囲が広すぎるということや、Web担当者にしては仕事の範疇を超えている。という意見を頂く事が多く、今思えば、この名称が自分のやっていた仕事にマッチしていたなという印象です。

目次

UXデザインのフロー

UXデザインのフローは下記のようになります。これは僕がこれまでやってきたやり方であり、不足点や不要点があるかもしれません。ですので、一例として捉えていただけると恐縮です。

  • リリースしようとしているサービスの市場調査
  • ユーザーを仮説立てるペルソナの作成
  • ペルソナの感情変化を捉えるためのカスタマージャーニーマップ作成
  • カスタマージャーニーマップを元にワイヤーフレームの作成
  • クライアント(僕の場合は社内で)とのディスカッション
  • プロトタイプの作成(UIのすり合わせ)
  • デザインの作成
  • プロトタイプの作成(前述のプロトタイプにデザインを取り込んだもの)
  • クライアント(社内)とのディスカッション
  • ワイヤーデザイン及びの修正
  • プロトタイプの修正
  • 製品版の作成
  • プレリリース
  • ユーザー調査
  • ペルソナの作成・ユーザーテスト
  • リリース
  • 運用開始
  • アナリティクスによる数字からのペルソナ作成
  • 運用側、エンドユーザーからの課題調査
  • あがった課題から、パーツ単位でのリニューアル
  • 検索ワードを利用してもらえてるかの調査(クライアントの要望とエンドユーザーのニーズの誤差確認のため)

サービスリリースの際に行うのはこれぐらいです。 工程としては調査することが多く、制作会社であればディレクターが担う部分も多いと思います。 デザインやコーディング、フロント、バックエンドのプログラムを書くことも多いですが、UXデザイナーの仕事と考えると、一般的にはフロントの動作部分デザインまでという人も多いのではないでしょうか?

仕事の内容をフローとして書くと

  • 市場調査
  • ペルソナ、カスタマージャーニーマップの作成
  • ワイヤーの作成
  • デザインの作成
  • プロトタイプの作成
  • 製品版の作成
  • リリース
  • 運用

です。デザインの作成とプロトタイプの作成を分けていますが、同フェーズの場合もあれば、順番が逆の場合もあります。

ペルソナやカスタマージャーニーマップを元に、ワイヤー、デザイン、プロトタイプを検証し、PDCAで回して先のフェーズへ進めます。

PDCA

PDCAサイクル(PDCA cycle、plan-do-check-act cycle)は、事業活動における生産管理や品質管理などの管理業務を円滑に進める手法の一つ。Plan(計画)→ Do(実行)→ Check(評価)→ Act(改善)の 4 段階を繰り返すことによって、業務を継続的に改善する。

Wikipedia:PDCAサイクル 

そして、製品をリリースすれば運用フェーズとなり、実際の運用の中でPDCAを回してくのが実務となります。

UXデザインのフローは以上となります。UXデザイナーが行う仕事の肝はおそらくペルソナ、カスタマージャーニーマップの作成と、ワイヤー、プロトタイプの作成の部分だと思うのですが、もっとも重要なのはUXを考える部分になるので、そのあたりを掘り下げていきたいと思います。

ワイヤーフレーム、プロトタイプ作成で考える事

ワイヤーやプロトタイプを作成するのは

  • エンドユーザーが使いやすいと感じるのはどういうものか?
  • クライアントが見せたい情報はどこにあるのか?
  • 市場ではどういったデザインが採用されているのか?

これらの要因をまずまとめ、そのサービスの在り方を決めるためです。

その上で、クライアントとの認識のズレが無いか?のすり合わせを行い、デザインのフェーズへと移行することが目的で、それを実現するためであれば、ワイヤーやプロトタイプはそのプロジェクトごとに異なります。

ワイヤーフレームの作成について

ワイヤーフレームの作成では、要素をどこにどう置くか?が要点として捉えられるよう、なるべくシンプルに作成しておいて分かりやすいようにします。

そうでなければ、ワイヤーの時点で余白やフォントサイズ、色味などに意識をとられてしまい。本来決めるべき部分と異なる部分で議論が始まってしまうからです。

それを避け、ユーザーがサービスを閲覧した時どう捉えられるか?の部分に着目して話し合えるようにします。

プロトタイプの作成について

プロトタイプの作成では、UIがどういう動きをするか?をクライアント(社内)とすり合わせる為に使います。

ワイヤーで要素の確認をとり、プロトタイプでUIの動きやフォントサイズ、色味や余白などを確認しながら話し合い、決定すればデザインのフェーズへ移行するといった流れになります。

ここで決まらなければ、プロトタイプ→ワイヤーフレームへとフェーズを戻し、決定が出るまで繰り返します。

この時の決定は

・ユーザーにどれだけストレスを与えないか? ・クライアントの伝えたいものはしっかり伝えられるか

が課題であり、これらを考えるために市場調査や顧客調査、ペルソナ・カスタマージャーニーマップの作成をこのフェーズで行います。

プロトタイプの作成時、僕が社内運用の仕事をやっていた頃は、絵コンテで説明したり、コードを書いて実際の動きを確認してもらったりしていました。コードを書くと時間がよりかかってしまうのですが、 最近ではProttのように、サイトの遷移のプロトタイプが比較的簡単に作れるサービスが登場し、非常に便利になりました。

UI(ユーザーインターフェース)の設計で知っておくユーザーの心理

新しいサービスを開発したり、UIをデザインする際に考えるのは、それに触れるユーザーが使いやすいか?であり、その為に設計やワイヤーフレームでのやり取りをしっかり行います。

そもそも、その使いやすいUIとは何でしょうか?

皆さんもこんな経験がありませんか?

  • WindowsからMac、もしくはその逆にしたら、アプリケーションのをどこから起動するのかわからなくて困った。
  • 新しいグラフィックツール、開発ツールが気になるので触ってみたが、どこをどうすれば何が出来るのかわからない。
  • 今まで使っていたアプリケーションのバージョンがあがり、今までそこにあったはずのメニューが無くなってしまって、どこから探せば良いのかわからなくなった。

これらはこれまで自分が使ってきたもので脳内に培った情報が、新しいものでは通用しない為に起こる弊害で、非常に大きなストレスですよね。

しかしこの時、使うことを諦めた人は少ないのではないでしょうか?(使い続けた上で、合わないとして使うのを辞めるケースは省きます。)

これらの場合、使う物自体が変わったとしても、過去に利用したものに似たものであれば、例え一瞬わからなくても、自分の勘で探し当てたり、検索やマニュアルを読んで調べることで問題を解決できたと思います。

この解決に至るためのプロセスは下記となります。

  • 脳が過去の経験から問題を解決できると予測されるものを呼びだす。
  • それを利用し、検証する
  • 解決しない場合、最初に戻る。

人間の脳は、これを瞬間的に繰り返し、使えるか、使えないかの判断を下します。

先程の例でいえば、下記の行動が例となります。

  • スタートメニューがどこにあるか? Windowsなら左下、Macになると左下にない。→他の画面隅にあるのではないか?→結果どうなったか
  • グラフィックツール、開発ツール自体は変わったが、メニューはどこにあるのか?→上部にある?→結果どうなったか
  • メニューが無くなってしまったが、自分が見たい項目は存在するのではないか?→検索を使ってみる→どうなったか

これらの行動はUXよって引き起こされる行動で、全ては脳内にインプットされている情報が鍵を握っています。

UX

ユーザーエクスペリエンスとは 製品、システム、サービスを使用した、および/または、使用を予期したことに起因する人の知覚(認知)や反応

wikipedia:ユーザーエクスペリエンスデザイン

パソコンに関する例は、どれも仕事のような「それに触る必要がある前提の物」ばかりです。このケースであれば、利用者にとって必要不可欠なものが題材になっているため、興味が薄い者に比べ、長時間うけるストレスでも我慢して問題解決まで動作を繰り返すことができます。

しかし、触る人にとって興味が薄くなるサービス等の場合、下記のような問題が出てきます。

  • 過去のユーザー体験から情報を引き起こすのが容易ではない
  • 興味関心が低ければ低いほど、ユーザーは少しのストレスで離脱してしまう。

人間は一定のストレスを感じるとその場から逃げようとします。 本能的にストレス=危険なものと知っているからですね。

サービスに触れることがどう危険か?というと、人は生きている中で非常に沢山の事柄を体験して成長し、生きています。 しかし、興味の薄いものにまで時間をとられていると、自分が本当に必要な事をする時間を失ってしまうので、本能的にそこから逃げようとします。

その為、UIをデザインする場合、ユーザーがまずそのサービスについて知らないということを常に意識し、知らないということはどういうことか?知っておく必要があります。

ユーザー体験とストレスの関係

人間は例え初見のものであっても、脳内から過去の情報を取り出し、どうすればよいのか?を予測して、検証します。 しかし、密な関連性を持った物が存在しない場合は、予測しようにもその範囲が広くなり、検証すること自体が困難になってきます。

思い出してみてください。 あなたが初めてパソコンを触った時、容易に使うことができたでしょうか? おそらく、多くの人がノーであるものの、結果については差があったと思います。

  • 何をどうするのかさっぱりわからないまますぐ触らなくなった
  • アイコンを開いてデータを見ることができた
  • とりあえずインターネットはできた

これらの差は、パソコンに触れるという状況に至るまでに体験してきた事や、環境などで大きく変わります。

「勘が働く」という言い方がありますが、これは、それに触れるまでに蓄積してきた情報が、目の前の問題を解決するのに必要な情報に近いものを、どれだけ持っているかが関係し、より近いものを持っている人ほど、勘が働くということになります。

そして、勘が働きやすい人ほどストレスを感じづらく、勘が働きにくい人ほど、使いづらい・わかりづらいといったストレスを感じやすくなります。

さらに、自分にとって興味の薄いものに対しては、ストレスに対する耐性が低くなりますので、勘が働きづらく、且つ、興味の薄いものは離脱率がどうしても高くなります。

利用する上での離脱率上昇を抑えるには

  • そのサービスのユーザーがどういうターゲットになるのかを掘り下げる
  • そのユーザーが過去に体験したであろう予測を立てる
  • その予測で想定されるレイアウトを採用する
  • 勘が働くようにする

などを意識し、なるべくユーザーがストレスを感じないようにすることが重要で、ユーザー体験とストレスの関連性は密にあるといえます。

ユーザー体験を活かすUI

UIとはユーザーインター・フェースの事で、サービスとユーザーとが情報をやり取りするためのインターフェースです。 パソコンであれば、ディスプレイ、マウス、キーボード、タッチパネル、タブレット、マイク、スピーカーなどがそれにあたります。

UXは触って感じ取る知見と定義されていますが、UIは実際に触れるための部分であり、サービスとユーザーとの架け橋のようなものです。

Webサイトは非常に多く存在し、そのデザインは様々な形がありますが、UIの部分はパターン化されているものが多いです。

これはデザインをする際に、ユーザーが迷わず使えるようにという配慮から、多くのデザイナーがデザインパターンを利用することを選択しているからです。

ユーザーが迷わない為には、すでに体験している記憶を呼び起こさせれば良いわけですから、パターンを活用することは非常に理にかなうアイデアです。

もし、キーボードやマウスが全く違う形、ボタン配置になると使うときにためらいが出るはずです。

そうならないよう、ユーザーが持っている過去からの知識をなるべく利用することが、ユーザー体験を活かすUIといえます。

顧客調査・市場調査とペルソナ

UXはそれを採用するサービスの市場調査を行い、ユーザーとなりうるペルソナを想定します。ペルソナとは、ユーザがどのような心理をもち、どういった行動をもつか?サービスに対してどのような期待値を持つか?などを仮説立て、問題点・改善点を見出して改善するためのものです。

ペルソナを立てるには、他者にサービスを使ってもらう想定を立ててインタビューを行ったり、実際に触ってもらってフィードバックを得たりする方法や、そのサービスに関するデータを元に立てる方法など、立て方は様々です。

5/28にIA/UXプラクティス モバイル情報アーキテクチャとUXデザイン の発刊イベントが 日本ディレクション協会 主催でとり行われ、そこで著者である坂本 貴史さん(@bookslope)も同様の事をおっしゃっていました。

僕はもともと坂本さんのファンで、実際に参加しお話を聞いたり、ワークショップで隣の人にインタビューをしてペルソナを実際にたてたりしました。

僕は前職まで、企業のWebサイト運用を仕事にしてきていたので、非常に馴染み深く興味の強いセッションだったのですが、フリーランスで制作の仕事をメインにしてる今、ペルソナを立てるケースが現状だとあまり無い為、久しぶりに普段と違う脳みそを使ったので非常に楽しかったです。

質疑応答の時間で、リニューアルを依頼される場合もペルソナを立てなおしたりしますか?という質問をさせていただいたのですが、坂本さんは「リニューアルやその企業に数字がある場合は、それらを活用してペルソナを立てるのはごくごく普通に行います。」という答えをくださいました。

僕がこれを聞きたかったのは、これまでの仕事でペルソナを立てる、立て直すことは普通にしてきていたのですが、それが他の人もやっていることなのか? 数字を活用することもペルソナを立てると言っていいのかが疑問を持っていました。 しかし今回、このように解答を頂くことでそれを解決できたのは素直に嬉しかったです。

坂本さんは以前の著書である IAシンキング Web制作者・担当者のためのIA思考術 を読ませていただいた時に存在を知りファンになったのですが、今回のイベントで実際にお会いし、少しでは有りますがお話させていただけたことが嬉しかたです。

それとサインを頂いて一緒に写真をとってくださったことは何より嬉しかったです。ありがとうございました!

あ、脱線しました、続けます。

UXを考える時、人とサービスの交わりをとにかく考えます。その為、顧客の調査や市場の調査は欠かせないものであり、そこを考えていかなければ、UXは成立しません。

UXをデザインするという事は、そのサービスや企業の在り方をしっかりと認識し、何が課題となるのか?を見つけてそれを改善することが重要なポジションとなります。

ユーザーの感情変化を捉えるカスタマージャーニーマップ

前項にて顧客及び市場調査を行いペルソナを立てました。ペルソナでは様々な課題を見つけることができ、それを解消するにはどうすればよいか?を知ることができます。

しかしペルソナだけではユーザーの感情、改善点が端的に見えてしまうので、感情の移行までが見えません。

ユーザーがサービスを利用する場合、端的ではなく行動として流動的に感情が変化するので、そこを捉える為にはペルソナを用いたカスタマージャーニーマップの作成が有効です。

カスタマージャーニーマップとは、ユーザーの行動フローを時系列にしたマップのことで、商品の購入でいえば、サイトへのアクセス→画面の遷移→商品情報の閲覧→レビューの調査→商品の注文→顧客情報の入力→メールの受信→商品到着といった一連の動作を指します。

このマップがあれば、ユーザーがいつ感情に変化が現れ、その感情が正の感情なのか、負の感情なのか? 何をすればより良いサービスを提供できるのかが見えてきます。

>

カスタマージャーニーマップを正しく活用するには「おもてなし」と「カスタマーエクスペリエンス」の理解から

カスタマージャーニーマップは数字だけでは追えない、ユーザの思考や感情を時系列に捉えることができるので、改善すべき点をよりイメージしやすくなるのがメリットです。

最後に

冒頭でお伝えしたとおり、UXという言葉やUXデザインという言葉をよく耳にします。

しかしこの言葉が出る以前から、サービスを考える時、多くの人がそれを意識せず、自然と行ってきたことが殆どだと思います。

ペルソナをたてることも、実際に立てては居なくてもユーザーのことは想定してきたでしょうし、カスタマージャーニーマップについても、ユーザーの感情変化も、そのサービスをより良くするためにを考えていけば自然と意識する部分だと思います。

今Web制作者の中でUXの事が話題になるのは、近年スマートフォンの登場とそれの普及によって、過去のやり方だけでは太刀打ち出来ない課題が多く出てきたことに有ります。

広く認知されたフローやプロセスなどは、それをわざわざ置き換えることに時間を費やすことは少ないですが、自身の経験だけで対処できない事が出てきた時、誰しもそこに時間を費やし、努力します。

おそらくそれがここ数年間のWeb業界全体における流れではないでしょうか?

今回の記事は非常にボリュームが多いものになりましたが、UXデザインで考えることは非常に多く、今回紹介しただけでは到底収まりきりません。

今後必要なものを少しづつ紹介していきますので、これからも当ブログをよろしくお願いいたします。

本記事でお伝えしたツールや、UXの参考に。

  

bxSliderで自動再生が止まってしまう不具合の解決方法

この記事の目次 bxSliderとは bxSliderは、スライダーのjQueryプラグインの一つです。主な特長は下記の通りです。 レスポンシブ対応で、タッチ操作にも対応している。 IE7以上をサポートしている。 オプシ […]

Zeplinでサイズが従来の半分になる原因は「Density:2x 」

Zeplin でオブジェクトのサイズが従来のサイズの半分(1/2)になった時のメモ。

原因は、そのプロジェクトのDensity (密度) の設定。 Zeplinではデフォルトで 2xになる模様。 Sketchの方で等倍ピクセルで作成していたら、Zeplin側でもインポート後に設定を変更する。

プロジェクトのスクリーン一覧の右列で 「Density:2x 」なっているかを確認。

項目「Density」をクリックで編集ウインドウが出る。 「2x → 1x」に変更

スクリーン一覧で 「Density:1x 」となっていればOK。

これで従来の等倍サイズが表示されるようになりました。

SHIHO AOYAMA SELECTION SALT PACKAGE

社団法人日本ソルトコーディネーター協会の青山志穂さん選定の塩シリーズのラベルをデザインさせていただきました。文字通り手塩にかけたこだわりの天然塩ブランドばかりなので、ひとつひとつ書の手書きで制作しています。種類が多く、微妙に色合いの違う塩をバックに映えるよう、かつ自然の恵みを想起させるような配色にいちばん苦労しました。 色々なところで販売されるようなので、どこかで見かけることがあったらぜひ手にとってみてください。

SHIHO AOYAMA SELECTION SALT PACKAGE

社団法人日本ソルトコーディネーター協会の青山志穂さん選定の塩シリーズのラベルをデザインさせていただきました。文字通り手塩にかけたこだわりの天然塩ブランドばかりなので、ひとつひとつ書の手書きで制作しています。種類が多く、微妙に色合いの違う塩をバックに映えるよう、かつ自然の恵みを想起させるような配色にいちばん苦労しました。 色々なところで販売されるようなので、どこかで見かけることがあったらぜひ手にとってみてください。

Aasa – 沖縄産天然アーサ

沖縄産天然アーサ「Aasa」のパッケージデザインです。 兄弟商品である「SUNUI」と同じく、今回も偉大な海の恵みに敬意を表して筆でリングを書きました。禅書における円は、「一円相」と呼ばれ宇宙の真理や悟りの境地などをあらわすと言われています。 本州のアオサとはまた違った風味が楽しめます。 沖縄の土産ショップにSUNUIと並んで販売されているそうなので探してみてください。

Aasa – 沖縄産天然アーサ

沖縄産天然アーサ「Aasa」のパッケージデザインです。 兄弟商品である「SUNUI」と同じく、今回も偉大な海の恵みに敬意を表して筆でリングを書きました。禅書における円は、「一円相」と呼ばれ宇宙の真理や悟りの境地などをあらわすと言われています。 本州のアオサとはまた違った風味が楽しめます。 沖縄の土産ショップにSUNUIと並んで販売されているそうなので探してみてください。

Advanced Schedule Posts ver.1.1.2 リリースノート

Advanced Schedule Posts — WordPress Plugins

Changelog

= 1.1.2 = * when overwrite the another post, it change the `post_id` that is included in the menu objects.

上書き予約投稿を実行した時に、上書き先の投稿がナビメニューに含まれていた場合、ナビメニュー内の post_id も上書きするように修正しました。

これまでの上書き予約投稿のロジックは、スラッグ(パーマリンクURL)を上書くだけだったため、上書き先の記事がナビメニューに含まれていた場合にリンク切れになる不具合がありました。それを改善した形です。

v1.1.1以前の不具合

管理画面のナビメニューUIのリストから選択してナビメニューを設定すると post_id を保持するためリンク切れになる。 カスタムリンクでナビメニューを設定すると パーマリンクURL を保持するため問題ない。