ペルソナを作るとわかる２つの良いこと - サービスデザイン編
最近のUXデザインでは必須のものとなってきているペルソナ。
ペルソナとは、ユーザーの行動パターンを調べ、そのデータから作り上げた、サービスのユーザーを代表する仮想の人物。
この仮想の人物をユーザとして、サービスを考えていきます。
では、ペルソナを作るとどんな良い事があるのでしょうか？
プロジェクト内の方向性がブレない
ユーザがあれも、これも、なんて考えていると、ユーザ増がぶれ、それに伴ってサービス要件、その他いろいろぶれてきます。
ペルソナを作ってみると、この仮想ユーザが満足するサービスを作れば良いのだから、こうしたら良いのではと、プロジェクト内の意見も出やすく、考えもまとまりやすくなり、意思決定が早くなります。
何か迷ったらこのペルソナに聞けば良いのです。
ユーザファーストになる
ペルソナを考え、作る事で、ペルソナに親近感がわき、ペルソナファーストなサービスを自然に作る事ができます。
ユーザの詳細な体験も想像できるようになり、サービスに何が必要なのかが明確になります。
実際に作ってみるとわかりますが、似顔絵も書くと愛着も出てきて、このペルソナにはどんなサービスを用意すれば喜んで利用してくれるんだろうか。
そんな事をメンバー全員が考えながら作れます
不要な機能を考えたとしても、それってこのペルソナが利用すると思う？思わないよね。で終わります。
今日はここまで、次回はペルソナの作り方でも。
話題のChromeBookってどうなの？知らないと損する5つの常識
ChromeBookって何？
Google Chrome OSを搭載。
データは全てクラウドにおき、基本的にはすべてweb上で動作するアプリケーションを利用するPC。
Chromebookの特徴
・webブラウザだけあれば良いスタンス
・高性能なメモリ/CPUは不要で、低スペック環境で問題なし
・データをローカルに保存しないので、HDDも少なくていい
・起動が超速い
・バッテリーの持ちが素敵
・200～300ドルで購入可能
・日本語も問題なく使える
・ウィルス対策も標準で完備
ChromeBookを買うと良い事
・起動や終了が非常に速い。
数秒で起動し、数秒でシャットダウンする
・データを持たないので、PCのお引っ越しが容易
ChromeBookの不満
・オフライン状態での文章の編集、反映が微妙
・Windowsアプリケーションが利用できない
デザイナーにとっての必需品である、Photoshopやillustratorはインストールできません。
・プリンタやスキャナが利用できない
・Windowsの共有フォルダにアクセスできない
Googleリモートデスクトップで対応する
知らないと恥ずかしい！話題のChromecastって何ですか？
ちまたで話題のChromecastって何なの？
そんな疑問を少しだけ解決してみます。
Chromecastとは？
テレビのHDMI端子に差し込む端末。
専用のアプリで設定するだけで、テレビ番組、映画、音楽を楽しめる。
4200円です。
良い点
・スマホから操作ができる。
TSUTAYA TVとかで面倒なのが、操作はリモコンで行うところ。
chromecastは操作をスマホやノートPCでできるのは大きなメリットです。
・今後の展開に期待
現状でもyoutube、hulu、その他いろいろなサービスと連携されている。
今後いろいろなサービスと連携することで、生活のプラットフォームの１つとなるのかもしれません。
悪い点
・費用
Chromecastの費用 + サービスごとの費用がかかる。
Chromecastを無償提供であれば納得かも。
・Youtubeなどの再生のレスポンスが悪い
・アプリひとつで何でもできるタイプではない
総評
初め、TSUTAYA TVのようにネット配信されたものがTVで見れるってものかと思ったら違いました。
既存のサービスをアプリを通して、TVに映し出すガジェットなんですね。
映画をみるために必要なものだと思っていましたがそうではないようです。
私には、youtubeをTVでみたい、googlemapをTVでみたい、なんていうPCやスマホで普段利用しているものを、テレビで利用する欲は存在しないため、これを欲する機会が訪れる事はありませんでした。
Huluをchromecastで見れる、ってそれもうChromecastじゃなくていいじゃん。なんて思ったり。
TSUTAYA Stick、smart TV、似たような商品が…。
ただし、今後の世の中で、このChromecastがあれば、様々なネットサービスをテレビで配信できるというのはどこかに良い機会があるのではないかなと思いました。
Hulu、Tsutaya TV、その他同じようなChromecastを製造するのではなく、1つで済むもの。
そんな存在に慣れると素敵かと思います。
hファイルとmファイルの使い分けはなに？Objective-cのお勉強
元々はC言語を元に作られているためか、Objective-cでは、hファイルとmファイルのペアで実装をする。
hファイルとは？
拡張しが「.h」のヘッダファイル。
クラスの宣言部分はこのhファイルで行う。
mファイルとは？
拡張しが「.m」のメインファイル、メソッドファイル
クラスの実装部分はこのmファイルで行う。
mファイルで実装するもの
・クラスの宣言ファイルであるhファイルの読み込み（import）
・宣言したクラスやメソッドの実装
hファイルとmファイルにわける理由
mファイルにクラスや関数の宣言を書くと見辛いので、宣言はhファイルに書く
実際に、mファイルに全て書く事も、hファイルに実装部分を書く事も可能。
しかし、1つのファイルに実装も書いてしまうと、プログラムを全体に公開することになる。
ヘッダファイルは公開し、実装部分は隠蔽した状態での利用することができる。
話題のアイコンフォントって何？知らないと損する４つの真実
アイコンフォントとは？
Webフォント（CSSでフォントデータをweb上から取得し、利用できるようにする）を利用して、アイコンを表示させたもの。
利用方法
きっと①、②はやらず、web上で公開されているアイコンフォントを利用する人がほとんど。
①SVGでアイコンを作成
②アイコンデータに変換
③実装
アイコンフォントのメリットは？
・画像よりも動作が軽い
・スプライト画像のように、1つのファイルをロードするだけなので、リクエスト数を減らせる
・更にスプライトのように面倒な管理が不要
・ベクターファイルのため、拡大しても綺麗（retinaも問題なし）
・フォントなので色やサイズの変更が簡単
・アイコンを作る手間が省ける
・スマホなら主要OS、ブラウザでサポートされているので使いやすい
アイコンフォントのデメリットは？
・古いブラウザで使えない場合がある
・1アイコン内に複数の色の指定ができない
・特定のアルファベッドとアイコンフォントを紐付けるため、HTML上には不明なアルファベットが置かれる。
そのため、検索エンジンから見たら不要なものが入っていると認識される。
・フォントデータがダウンロードできなかった場合、返還前の不要なものが表示される
アイコンフォントはどんな時に利用すべき？
アイコンフォントは制作コストが高いです。
もし、Web上のものを使える環境にいるのであれば、上記デメリットを考えつつ、利用するのも良いかと。
しかし、自分で作成する必要がある場合、実際にアイコンを使って表示した方がコストがかからない可能性もあります。
担当サービス内で、アイコンをふんだんに使いたいのであれば、使ってみる。
そうでなければ、いつも通りアイコンを使ってみる。
なんて考えでも良いかもしれません。
しかし、最近ではretina対応で2倍、いや今後は3倍など解像度がどんどん増えていく可能性もあるため、このようなものも考えてみてもいいかもしれません。
食べログの評価が当てにならない４つの理由
最近では食事にいくにもネットで検索をします。
以前まで、食事は食べログを主に活用していました。
方法は食べログで検索し、口コミ数が多い、評価が高いなどを基準にいろんなお店を食べ歩きました。
美味しいお店も多々あります。
しかし、中には口コミも評価も高いのに、「あれ？」「何がいいの？」と思われるお店も多々ある事に気付きました。
「ある程度ある」ではなく「多々ある」ことの注目です。
食べログ基準では、3.5を超えるものは好評価のお店となるよう。しかしそうでもない。
また、その逆で、3程度の評価でも、すごく美味しいお店、おすすめなお店がありました。
この原因ってなんだろう。
レビュアーによって影響度が違う
一番大きな原因はこれじゃないでしょうか。
口コミ数や、評価の高いレビュアーは影響度が変わってきます。
そんなレビュアーに気に入られるだけで、お店の評価は高くなります。
逆にどんなに良いお店でも、そのレビュアーに嫌われると、評価は低くなるそうです。
男性と女性でも、レビュー評価に差が出るそうです。
そもそもレビューを書く動機って何？
良い、悪い経験を書き、どちらでもない人の意見はあまり書かれない
利用していないユーザも、入店前に悪い印象があれば、悪い経験を書くことがある
1つ星のレビューのほとんどが味ではなくサービスに対する不満である。
食べログユーザの評価しか存在しない
そもそも食べログのユーザってどんな層なんでしょうか？
例えば若い子が好きそうなお店よりも、もっと30代の方の方が多い気がします。
ということは、30代の方の意見に偏ってしまっているかもしれません。
また、食べログのユーザの中でも、レビュアー会員でなければ行けません。
ユーザの中の初めから誰かに発信したいと思っているユーザのみがレビューをできる仕組みになっているのです。
ということは一般目線のレビューではなく、レビュアーとしても目線でしか見れません。
一説によれば、このレビュアー会員は「男性が40代後半、女性が30代前半の自宅通勤者が」が多いとのこと。
これでは偏った評価しかみることができません。
口コミ数はあてになるの？
「レビュー星が0.5星追加されるだけで、最も人気のある時間帯の売上げが13％～34％増加する」
「1つのレビュー星の追加が収益の5～9％の増加につながる」
こんな話もあるらしく、以前にも話題になったお店側の偽装レビューによるランク上げが存在します。
一概に口コミ数が多いお店が良いわけではありません。
「レビューを書いたら100円引き」 なんてキャンペーンをしているお店があったら口コミ数が多くなるかもですね（そんなことをしたらレビューにも書かれそうですが）
私は食べログのそこそこヘビーなユーザでした（レビュアー会員ではありません）が、このような内容も踏まえて、評価の基準は変えるつもりです。
今後も食べログは利用していこうと思いますが、食べログで評価の高いもの = おすすめできるお店である ということを念頭に、利用していきたいと思います。
※上記内容は、個人的な感想です。
Node.jsについて知っておきたい４つの真実
Node.js 耳にした事はありますが触れた事はなかった。
そんなNode.jsを少し知ってみよう。と思い軽く調べてみた。
そんな内容です。
Node.jsってなに？
通常Javascriptはクライアント、要はブラウザ上で実行されます
しかし、このNode.jsはPHPのようにサーバサイドで実行されるJavascript？
その程度しか知りませんでした。
なぜNode.js？
元々Node.jsはあったっぽいです。
最近ではブラウザやPCの進化に伴い、Javascriptも流行りだし、Javascriptを使える技術者が増えてきました。
しかしサーバーサイトスクリプトのPHPやJavaは使えない。Javascriptなら。
そんなユーザにとって好都合なものがNode.jsだったそう。
なら、PHPを覚えればいいのでは？
ぶっちゃけ、Javascriptなどプログラミング経験があるひとは、ある程度勉強すればPHPでもJavaでも、Objective-cでもなんでも書けるようになるのでは？とも思いました。
そこでNode.jsの利点があったのです。
Socket.IO
Facebookメッセージのようなリアルタイムに相手と通信するもの
リロードが必要のない処理をNode,jsのSocket.IOを使うとできるとのこと。
これによって、ブラウザ上でリアルタイムに情報を共有できるようになりました。
Node.jsのデメリットってなに？
なら、Node.jsでやる方が良いじゃん。デメリットってないの？
デメリットが無いものなんでありません（筆者の感覚）
調べてみたら結構デメリットがあったので少しだけ。
Javascriptであること
Javascriptなので、オブジェクト指向が微妙です。
もしかしたら、ユニットテストについても微妙かも？JavascriptのユニットテストではJasminを利用していましたが、テストに限界がありました。
安定していない
今はどうか不明ですが、開発者も少なく、本体も改善を繰り返しているため、安定していないそう。
実用化としてはまだ微妙なんて声もありました。
重い処理があると全体に影響する
重い処理でCPUが使われるようなアプリケーションには向かないそう。
簡単なメッセージのやり取りのようなアプリケーションで使うのが良さそう。
以上、かんたんなNode.jsについて知っておくべき事でした。
