Blog.おにぎりたまごうぃんなー

Suzuki Yuki@s12bt おべんと箱みたいに色々つめこみたい。仕事とかデザインとか料理とか好きなもののことを書きます。

3万円でユーザビリティーテストルームをつくる

ユーザビリティーテストの設計から実施までの仕事を受ける機会があり、テストルームの準備も行いました。
テストルームを借りるという選択肢もあったのだけれど、今回はデメリットのほうが大きかったので、自前で一番安くあげるテストルームを設計してみました。

都内でユーザビリティーテストができるスタジオを借りるとなると1日10万円前後くらいになると思うので、3万円で1回社内にテスト環境作っておいとくと、選択肢が増えて楽だと思う。

( ※この記事はクライアントさんの了承を得て書いています )

ユーザビリティーテストを実施するにあたって必要な要素

f:id:s12bt:20140618155556p:plain
接続概要図

部屋(テストルームと観察ルーム)

それぞれ個室である必要はないが、テストルームは被験者の集中力を見出さないためになるだけ個室であったほうがよいと思う。
観察ルームである程度大声で話してもテストルームに声が届かない距離、仕切りは絶対にあったほうがいい。テスト中は、プロジェクトの関係者が観察ルームに集まって、被験者が行った操作についてその場で議論を行ってほしいと思っている。テスト中にモデレーターに聞いて欲しい質問事項、予想が間違っていた点、次回への改善点など話すことはたくさんあると思う。

被験者の操作と表情、音声を観察室に伝える

ユーザビリティーテストでは「思考発話法」という方法を被験者に行ってもらいながら進めることが多い。思考発話法とは、思っていること考えていることを逐次声に出しながら進めてもらう方法で、例えば「明日の天気を調べてください」というタスクを被験者に与えた時に「Googleでウェザーニュースを検索します…あっ、天気予報が出てきた。えっと東京は…新宿…1時間単位じゃなくて明日の天気…週間天気あった。明日は晴れです」というように見ているもの、思っていること、考えていることを全て口に出してもらうようにする。実際にGoogleでウェザーニュースを検索しながら上の発話を見てもらうをわかりやすいかもしれない。そのため、音声がよくとれることは重要。

表情については、発話だけでは伝わりにくい被験者の感情、様子を取るためにある。今、困った顔でディスプレイを見ているのか、怒っているのか、笑っているのか。サブ的な位置づけのように見えるかもしれないけれど、被験者の様子を取るのに一番わかりやすいものになる。

安く上げるキモはネットワークカメラ¥20,520

防犯や留守番時の家の様子などを見るのに使われるネットワークカメラを使った。

ネットワークカメラ行う利点

  • 持ち運び可能なので、どこでもテストルームにすることができる
  • 配線が楽
  • 遠隔地でも見ることができる
  • ビデオカメラ買うより安い

ネットワークカメラの中でも色々調べた中でこの製品の利点

  • 遠隔でカメラの操作を行うことができる
  • 録画しようと思えばできる(今回はしなかったけど録画したくなったときに対応もできる)
  • 音声もとれる

今回のテストルーム設計

f:id:s12bt:20140618160005p:plain

  • 被験者の様子観察は、上記のネットワークカメラで
  • 被験者の操作画面、音声は、チャットワークのビデオ通話の画面共有で

行った。

テストルームのノートパソコンは外部ディスプレイとミラーリングしていて、これは今回のテストがデスクトップPCから操作するものなのでそれを再現したもの。
ノートPCで操作するのと、デスクトップPCで操作するのでは操作感がだいぶ変わってしまうので。キーボードとマウスもノートパソコンから接続して、擬似デスクトップPCにした。こうすることで、モデレーターが画面観察しやすくなったりもする。
チャットワークで画面共有している部分、最初はUstreamでスクリーンキャストしようかと思っていたのだけれど、ネットワークカメラとの映像ラグが10秒以上出てしまって使えなかったため、急遽用意した代案だった。
でも、画面を見ながら、大事なことはチャットログに残したり、テストルームと観察ルームのやりとり(モデレーターへの指示、質問事項伝達)などにも使うことができて、すごく便利だった。
音声についてはノートPCに外部マイクを接続してチャットワークで共有した。

f:id:s12bt:20140605183807j:plain
実際のテストルームの様子。個室が用意できなかったのでパーテーションで区切って簡易個室で実施した
f:id:s12bt:20140618160328p:plain
ネットワークカメラからの映像。ブラウザとiPhone,iPadアプリからの閲覧をすることができる。左側のコントロール部分でカメラの操作が可能
f:id:s12bt:20140618160549p:plain
被験者操作マシンの画面を、チャットワークの画面共有で観察者側のモニタから見た様子

ネットワークを使用しない場合の設計

f:id:s12bt:20140618160724p:plain
ネットワークを使用するものよりちょっと高くかかる。機器の調査をちゃんとしていないけれど、8~10万円くらい。
スピーカーがついているディスプレイを用意すれば、HDMIで音声をそのまま出力できるので、HDMI音声分離器まわりが不要になる。
価格が少し高くなってしまうのと、配線などの設置の手間がかかってしまうけれど、ネットワーク不調などに影響されず、スムーズにテストができるメリットがある。

おにぎりたまごうぃんなーではユーザビリティーテストに関する仕事も受けてますよ

ユーザビリティーテストってやってみたいけど、どうしたらいいんだろう?やったらどんなメリットがあるの?など相談に乗ります!
何を知りたいのか、製品・サービス・会社の成熟度、プロジェクトのステータスによってもやり方、内容が変わってきてしまうので、簡単にパッケージ化できないところだと思っているので、お話しするところからで全然OK。
美味しいごはんで釣られます!s12bte@gmail.comまでお気軽にどうぞ。

コワーキングスペースの利用者からオーナーになりました

というわけで、オーナーになりました!!!!!

高円寺コワーキングスペース「こけむさズ」のオーナーになりました!

独立してからずっと使っている場所。今までは固定席を借りて1利用者として利用してた(コワーキングスペースに拠点を置く - Blog.おにぎりたまごうぃんなー)けど、2014年4月から共同オーナーの綿村さん、石嶋さんにジョインしました。

f:id:s12bt:20140411145500j:plain
3人目のオーナーになりました

きっかけは人の数に対して場所足りてない問題

高円寺の雑居ビルの2階のちょっとおこもり感溢れる穴蔵、こけむさズ。
実はスタッフが増え、固定席利用者が増え、ドロップインのお客さんが腰を落ち着いて作業するスペースがないという問題が。

f:id:s12bt:20140522212336j:plain
ひとがいっぱいいるときの2Fこけむさズ

同じビルの1Fが空いていることが判明し、
「そこに移動できたら広さ倍になるよねー」
「路面店になるから、今までよりもずっと気軽に入りやすくなるよねー」
と、オーナー2人となんとなく会話を交わしていたりはしたのだけれど。

利用客も顔なじみが増え、人の循環が淀んできている感じがして、おこがましくも一利用者としてなんとかしたいなぁと思っていた。

「お金出すから、1階に移らない?」

f:id:s12bt:20140106141825j:plain
1Fに初めて内覧しにいったときの様子

やってみようと思った2つの大きな理由

お金出す、といっても気軽に言ったわけじゃない。結構な時間悩んだし、夢に見るくらい悩んだ。
簡単にお金にならないことは側で見ていてわかっていた。
もし一緒にお金を出すとなったら、最低限稼がなきゃいけない金額が増える。継続してその金額を稼いでいけるか。
しばらくフリーランスを続ける気ではいたけど、もし企業に属したい(属しなくてはならない)状況になったらどうするのか。

やってみたいという気持ちのほうが勝った。
1つめはUXデザイナーという立場から。
どうしてこの場所を知ったのか、どうして来たいと思ったのか、ここでどういった時間を過ごすのか、また来たいと思ってもらえるか。
人が集まって、リアルなコミュニケーションの場ができる。
UXに関わっていて、憧れないわけがない。
2つめはこの場所にもっと関わりたいと思ったから。
今の2人のオーナーとも、スタッフとももっと関わりたい。この場所がもっとよくなるなら協力したい。
1年後も2年後もこの場所があってほしい。そのために自分も頑張りたい。

f:id:s12bt:20140522213010j:plain
すごい頑張ったらすごいステキな場所になった

やることも、責任も、稼がなきゃいけない金額も増えたけど、半年前にやりたいって名乗り上げてよかったなと思ってる。
利用者じゃないよ!オーナーだよ!
これからもスズキをよろしくお願いします。
共同オーナー綿村さん、石嶋さんこれからもよろしくね!

こけむさズはここ!ぜひ遊びに来てね!

高円寺コワーキングスペース こけむさズ

スクリーンショット管理にEmberがよかった

2014/5/9 追記

便利なんだけどなんかすごい不安定で、2回ほどデータが飛んでます。。。
iCloud上でライブラリ作るんじゃなくて、ローカルマシンにライブラリ作ったほうが安心かも。

スクリーンショットは資産だ

いいな、参考にしたいなと思ったページを、今まではてブすることで集めてた。
Webサイト収集に関するs12btのはてなブックマーク
見返してみたら、違うデザインに更新されていたり、404になっていたり、ドメインがなくなってしまっていたり。。。
あのとき出会ったステキデザインたちに2度と会えなくなってしまった。
画像データとして手元に置いておかなきゃ!ということに気づいた。

そこでEmber

DropboxやEvernoteやWebサービスでやろうとしたけど、どうもうまくいかなかった。
試用版があってよさそうだったので、思い切って購入。

Ember - Screenshot, Annotate and Share

Ember - Screenshot, Annotate and Share

  • Realmac Software
  • グラフィック&デザイン
  • ¥5,000

試用版はApp Storeでは配布されておらず、公式サイトからインストール。
Collect, Organize and Share the images that inspire you — Ember for Mac, iPad and iPhone

f:id:s12bt:20140115205322p:plain

iCloudでどこからでもデータ追加、アクセスが出来る

MacクライアントとiPhoneアプリが用意されていて、iCloudで連携ができるようになっている。(試用版ではできない)
複数のマシンで同じデータ共有できるし、MacとiPhoneでデータ共有できる。
iPhoneのブラウザ、アプリでとったスクリーンショットも、iPhoneからだけでデータ追加できる。
カメラロールに眠っていたスクリーンショットが陽の目を見るぜ!

ブラウザから1クリックで保存、URLも一緒に取得してくれる

Chrome拡張も用意されているので、ブラウジングしていてスクリーンショットとりたくなったとき。
f:id:s12bt:20140115210242p:plain
クリックしたら
f:id:s12bt:20140115211300p:plain
タイトルとURLまで自動で保存してくれる。

クライアント側でWebビューが取得できるけど、画面サイズを指定して取得できるのが便利。
f:id:s12bt:20140115211544p:plain

Macクライアントのちょっと残念なところ
  • Flashサイトのスクリーンショットが取れない(表示できない)
  • 画面幅をTabletやiPhoneに変更できるけどUAは変わらないので、スマートフォン最適化されたページなどのリダイレクトがきかない

アイコンがかわいい

f:id:s12bt:20140115211002p:plain:w150:leftf:id:s12bt:20140115210715p:plain:w250f:id:s12bt:20140115211656p:plain:w150



ちょっと高いけど、きちんと管理できてこその資産だし

FlashサイトでChrome拡張のAwesome Screenshotと併用することもあるけど、スクリーンショットのストレージはEmber一本でできるので、探す場所が1ヶ所になったのはデカい。
タグ、フォルダでの管理もできるし、画像の色によるスマートフォルダが作れたり、管理としてやりたいことができる。
Evernoteのクライアントの重さに泣いたり、Dropboxでタイトルが「スクリーンショット…」で始まる画像の多さに泣いたりしない!サービス終了のお知らせに悔やむこともない。
オススメ。

LessでCSSハックはどのようにコンパイルされるのか

CSSハックをLessの中で書くとどうなるのか気になっていたので実験。

  • とりあえずIEハックを検証
  • ネスト構造が崩れてしまうので、セレクターに何かする系は除外
サンプルコード
.container {
  padding: 10px;
  .h1 {
    _color: red;  // IE6
    color: red9; // IE8
    *color : red; // IE6, IE7
    /color: red; // IE6, IE7
    color/***/: red9; // IE7, IE8
    color : red\9; // IE6, IE7, IE8
  }
}
コンパイル
lessc sample.less sample.css

以下2行でパースエラーが出た。

/color: red; // IE6, IE7
color/***/: red9; // IE7, IE8

_colorと*colorでエラーが出なかったのが意外。
エラーが出た2行を削除して再コンパイル。

結果

コンパイルを通しても、意図したどおりに出力されている。

.container {
  padding: 10px;
}
.container .h1 {
  _color: red;
  color: red9;
  *color: red;
  color: red\9;
}

とはいえ、CSSハックなんてLessファイルに含めないほうがいいと思う

せっかく変数、演算ができてミックスインも書けちゃうLess.見通しがよくてメンテナンスしやすいCSSが書けるようになったのだから、いつまで使うかわからないCSSハックをその中に入れ込んでしまっていいものなのか。
しかもCSSハックをコンパイルするとどうなるのかなんて覚えるのは時間の無駄だ。正規の方法で書かれていないものはいつどんなところでバグを引き起こすかもわからない。IE6対応なんてコピペで済ましてしまおう。

Lessファイルを複数にして@importで1つのファイルにしてしまい、最後にCSSハックだけを記述したcssファイルを@importする。

style.less
  @import layout.less
  @import header.less
  :
  :
  @import ie.css  

外したいときにいつでも外せる。
上記style.lessをコンパイルしたとき、Lessファイルは展開され、cssファイルはそのまま@importで書き出される。

コンパイル前
style.less

@import "test.less";
@import "test2.css";

コンパイル後
style.css

@import "test2.css";
.container {
  padding: 10px;
}
.container .h1 {


CSSハックを使う機会もめっきり少なくなったけど。

styledoccoで"Error: spawn EMFILE"

styledoccoコマンド打ったら、エラーが出て前に進めなかった。
大量のファイルがあると起こる問題だったっぽい。困ったのでメモ。

エラーメッセージ

$ styledocco -n "styleduide" stylesheets/

child_process.js:927
    throw errnoException(process._errno, 'spawn');
          ^
Error: spawn EMFILE
    at errnoException (child_process.js:980:11)
    at ChildProcess.spawn (child_process.js:927:11)
    at exports.spawn (child_process.js:715:9)
    at preprocess (/usr/local/lib/node_modules/styledocco/cli.js:136:10)
    at Object.css (/usr/local/lib/node_modules/styledocco/node_modules/async/lib/async.js:532:23)
    at /usr/local/lib/node_modules/styledocco/node_modules/async/lib/async.js:467:25
    at /usr/local/lib/node_modules/styledocco/node_modules/async/lib/async.js:86:13
    at Array.forEach (native)
    at _forEach (/usr/local/lib/node_modules/styledocco/node_modules/async/lib/async.js:26:24)
    at Object.async.forEach (/usr/local/lib/node_modules/styledocco/node_modules/async/lib/async.js:85:9)

Error: spawn EMFILE

一度に開けるファイルの上限数にひっかかっているっているエラーでした。
ulimit -aで、一度に開けるファイル数の上限がいくつに設定されているかを確認する。

$ ulimit -a
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-v: address space (kbytes)          unlimited
-l: locked-in-memory size (kbytes)  unlimited
-u: processes                       709
-n: file descriptors                256

nの項目がファイル数の上限値。この場合は256に設定されている。
Mac OS 10.9.1(Mavericks)での初期値は256のよう。
ulimit -n 1000で1000まで広げてあげる。-nで設定してもメッセージが何も返ってこないので、-aで再度確認する。

$ ulimit -n 1000
$ ulimit -a
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-v: address space (kbytes)          unlimited
-l: locked-in-memory size (kbytes)  unlimited
-u: processes                       709
-n: file descriptors                1000


ここで$ styledocco -n "styleduide" stylesheets/を実行すると"docs"ディレクトリが作成されて、ドキュメントが生成される。

メモその2 $ styledocco -n "hogehoge"でつけられるのはディレクトリ名ではない

$ styledocco -n [プロジェクト名] [ターゲットディレクトリ]
$ styledocco -n "mogemoge" styleseets

って実行したら、mogemogeってディレクトリが作成されるのかと思ってたけど勘違いだった。
作成されるディレクトリはdocs、プロジェクト名はドキュメントのhtmlのヘッダーに書かれる。
f:id:s12bt:20131225174424p:plain