3/29/2014

[&] CSS Nite LP33 #7

CSS Nite LP33
----------------
問題解決のためのプロトタイピング 深津 貴之(ギルド)

すごいいろんな人のイベントで、最後の話しを仰せつかったのですが、
もう喋ることないんじゃないかと思っていますが。。。。。

自己紹介UIデザイナー @fladdict
スマートフォンのUIを中心とした制作を中心としたチームで、
カメラのアプリ、リブレという日記アプリ、テレビ局キャンペーンアプリ、フリフリTV
iPhoneアプリ設計の極意、モバイルデザインパターン

自社ではプロトタイピングだけでなくツールから作ろう、
定規、ノート、デザインテンプレートも自分たちで作ったりしています。

なぜプロトタイピング?
トレンドの変化、時代のスピードの上昇

アプリケーションをつくっても、すぐにライバルが登場したり、
すぐにシェアが変わってきたり、
ウォーターフォールでは間に合わない
作っている間に状況が変わってきてしまう。

評価と検品が最後だと危険すぎる
自分たちが売れるものを作っているのかわからなくなる。
プロトタイピングを一番最初にやれば、方向転換もできる。

リスクを避けるためのプロトタイピングとは?
よいプロトタイピング
早期にリスク検証。テストファースト

問題を分割したプロトタイピング
 よく作ろうと考えると、データベースにつないでいないだけで、ほぼ完成版を想像しますが、
 もしろ必要なのは、問題を分割した細かいプロトタイプ
ドロワーが良いのか、タブで作った方いいのか?
縦スクロールがいいのか?横スクロールの部分だけをつくって試すとか。
問題ごとに分けて作るのが良いプロトタイピング
下手するとプロト自体が、ウォータフォールにならないように。

●本質に特化。
全部入りプロトタイピングの話し、危険かどうか?ユーザーが欲しいかどうか?
設定画面の中までつくりこんでしまったり、
実際は、設定や画面がきたなくても、プロジェクトが失敗するかしないかにおいては、
どうでもいいところ。
サブ機能にはコストをかけないで、アプリのコア機能のところにプロトタイプを沢山つくっていく。

ダメなプロトタイピング、アンチパターン

●一球入魂
ジャストアイデアみたいな、一個しか作らないのは良くない。
ダメだと解っていても作りつづけるようなことになる。
プロトタイピングする時は、問題を分割して、リスクを分割して小さいものを沢山つくる。

●モニタ上で作業が完結
最近はツールが発達しているので、モニタ上だけでも良いのですが、
PCでプロトタイプで作ったものだと、ボタンが押せると押せないかわからないとか、
最近は技術が進歩しているので、Photoshop の画像を転送したりできるので、
使いやすくなってきています。
モニタだけのプロトタイプは大きな弱点があって、チームで作るとか、
チームでシェアするのが難しくなる。
プロジェクトの最初の段階で、ああでもないこうでもないと考えながらプロトタイプできない。
モニタを囲んで作れない、誰かが作ったのが確認するだけ、
単なるオペレーターになってしまう。

●プロジェクトの品質が他人事になりやすい。
プロトの段階でチーム全体で、
全員で危機感を持つためにも、必要
紙やホワイトボード、できるだけ皆が同時に関われることが重要

●スーパーゴージャス
機能ありすぎ、機能はないのにアニメーションだけが凄いとか。
ゴージャスなものが全部だめなわけではなく、
クライアントプレゼンで、お金をひっぱるために作るのであれば、よい。
偉い人を説得するには良い。
そういうのは、プロジェクトのゴーサインをもらうために必要なもので、
チーム内で作るには時間とリソースがもったいない。

じっさいそいう良いプロトタイプを作るには?

fladdict 式メソッド
プロトタイピングのコツ
一番初期のフェーズに特殊なスキルが無くても皆でできるもの、

●みんなでやる
シンプルであること、ツールが気軽で特殊なスキル無しで使えること、
そういうプロトタイピングが終わったら、それぞれチームの中のエキスパートがやれば良い。

持って帰れるメソッドを。

●プロコン・リスト
UIやUXの教科書に載っているようなことではない。
他の分野から、UI/UX で使えることをそしゃくして使えるようにしている。
長所と短所を列挙したリスト

プロコンリスト

長所
客観的に評価
簡単に行える
チームで共有しやすい

短所
感覚面の評価ができない
正確な重み付けが難しい

つりあいの取れる長所と短所をセットで消していき、
どっちが重いか?

最終的に「チームで共有しやすい」が残り、やる方がメリットが多いということがわかる。
思い込みにブレーキをかけ、客観的評価の機会を作る。
もりあがって、欠点を考えないで、すすめてしまわないよう。
アプローチごとに長所と短所のリストを列挙して、
その後に深呼吸して考えることで、安全弁になるメソッド

思い込みにブレーキをかけ、客観的評価の機会を作る
いろんなメソッドを集めるのが好きで調べているのですが、
詳しく無くても、即実行できるものです。

●プレス・ファースト
これもプロトタイピングに入るかどうかわからないのですが、
商品の前に疑似プレスリリースを作る。
それをメディアに送ったりしないのですが、
そのインチキプレスリリースを見てもらう。

疑似プレスリリースで、ユーザーの反応を見る。
商品無しに商品の需要を計れる。

トリッキーな方法に見えますが、
ユーザー視点の企画書をもう一回書き直しているようなもの。
これも強力なプロトタイピングの手法

●フィッシュボーン図

ふわっとした問題が、具体的な問題になり、
具体的な問題を解決する方法になります。

「ミスタップが多い」という具体的な問題
大問題、中問題を書きこんでいく。

中問題
機能がわからないからミスタップ
ボタンが小さいからミスタップ

小問題
文字のないボタンが多いからミスタップが多い
ボタンが小さすぎてとなりのボタンを押してしまうのでミスタップが多い

これはあくまで問題を分析して解析するためのツール
実際自分でやるときには、問題をブレイクダウンすると、
それらを解決するプロトタイプを作ると、具体的な問題に分析して、解決できる。

プロコンリスト

長所
複雑な問題を単純か
複数のアプローチを探せる
状況を俯瞰できる

短所
枝の精査/評価に時間がかかる

これらのメソッドをよく使っています。
ペーパープロトタイピング

長所
最速
リスク最小
費用が安い
みんなでできる

短所
アニメーションに弱い
遠隔共有に弱い

プロト図は技法なので、絵が苦手でも描ける
まっすぐ線がかけるツールが安心すると思っているかもしれないが、
プロト図は技法だと思っているので、絵が苦手でも描ける

鉛筆で描いたり消したり、書き直したり、わりと雑でOK
細いペンと太いペンで、清書をします。
線を引いただけでそれっぽくなる。
コンポーネントレベルは太い線、細かいところは細い線、
重要なところは太い線、ルールをわけるだけで読みやすくなる。
定規は好みで。

マーカーで、濃いマーカーと薄いマーカーで、
レベルわけして濃くするだけでそれっぽくなる。
絵が上手くなくても、ぱっと見でわかるようになる。
絵が下手な人でも 2-3枚かけばわかる。
描ければ楽しくなってくる。
スタートポイントとしては楽しくできます。
紙でプロトタイプをするのであれば、太い線、細い線、濃いペン、薄いペン、

簡単に綺麗なプロトタイピングが作れるのですが、
同じ要素を何度も描くのは面倒。

常に解決法はありまして、
ポストイットはペーパーの弱点を補完する
同じような画面があったときに、再利用できる。
コンポーネント、アラートとかをあらかじめ用意しておいてます。

周囲にあるものをすべて利用する
Flipboard 的アプリの場合は、
Xcode よりホッチキスを使う
文房具の星形シールとか使ったり。

必ず複数パターンを作る
ATMの送金アプリを考えた時のフィッシュボーン図
お金を送るUIであれば、おこる間違いを解析して、問題を対応するアプローチで
複数案を作る。
お金を送るまえに確認する、ポップアップだと情報が見えなくなる、
タップする代わりにスライドで送金するようにすれば、間違わなくなる。

あらかじめ、プロトタイピングの前にフィッシュボーン図をつくり、
別々の方式で検証していけば、
問題として認識していなかったことも、
解決したと思ったことも、より深い解決にできたりする。

プロコンリストで一番いいものを探す。
プロトタイプは作るだけでなく、比較して検証することが一番大事

検証と比較はプロトタイプの両輪

●紙から先へ
だいたいできたかなとなってから、
チームで共有できないとか、インタラクションがわからないとか。
POPというツールを使っています。
https://popapp.in/

紙で描いたプロとでインタラクティブ性が確かめられる。

長所
コストがきわめて低い
高フットワーク
スマホだけでできる
チームで参加できる

ポップアップも、タブもポストイットを使っています。
実際は設計しているので作ったり壊したりしているのですが、
一回ペーパープロトができれば、20-30分で取り込んでリンクをつけて、
コストパフォーマンスが良いツールだと思います。

POPの人と仲良くなったので、ビデオレターをもらいました。
POPは台湾のスタートアップで、アメリカに行って、YouTube 関連のVCに買われた?

POPからのメッセージ
------------------------------------------------------------------------------
これからの新規を紹介させてくだしい。
もともと5年毎に作り始めて、いろいろ作っていたのですが、
最初に始めたころは大きな失敗を繰り返していました。
作る前に全くテストしないで作っていて、
なんかおかしんじゃないかと思って、問題を解決するために、
いろんなツールを探してみましたら、解決するツールはありませんでした。
2012年ぐらい、簡単に使えるものが部品を組み合わせるだけで、
出来合いのものは作れたが、ペンと紙で作れるツールを作ったのがこの POP です。
ペンと紙でアプリを作り始めて、紙は使いにくいし、共有しにくい、
自分たちでカメラで撮ってiPHoneに入れればいい、と
思いついて開発しました。
その頃はそういうツールが無かったので、友達と2人で作りました。

最近、アップデートして、もうすぐ 2.0 になる、
Dropbox と連動するし、自動シンクするように、
日本語を含む New バージョン、アンドロイドも。

POP からプレゼント
プロジェクト作成上限を無料プレゼント
popaapp.in のリンクと一緒にツイート、support@popapp.in へメール

●手触りのプロトタイプ
手触り専門のプロトはプレゼン以外ではまず必要ない
プロトタイピングはリスクを最小化と、作っているものが良いのか評価するためのもので、
「ふわん」とするとかは、重要ではない。
Flipborad のようなものではなければ重要ではない。
Flash や Xcode ではチーム全体で作れない。
自分は Flash 使えるが、プロトで使うのは封印している。

チームで共有できる動きのモックはどうするか?
豪華なアニメーションのデモ、
キーノートで作ってます。
iPhone のスクリーンサイズでキーノートのアニメーションを活用。
これだけ動けば、いいデモになる。
モーション最強のプロトツールは Keynote.
QuickTime にエクスポートして、その動画を iPhone で再生すれば、
何時間もかける必要がない。
全部アニメーションの検証もできる。

●Xcode を使うプロト、
データが動的なとき、待ち時間の検討をしなければいけないとき
ドラッグやピンチなどジェスチャや複雑な操作があるとき

基本的に紙で良い、遷移は POP, 高度なアニメーションは Keynote
大げさなツールを使わなくてもチーム全員が使える。

●まとめ
プロトの本質は、最初に可能性を模索するのが一番大事。
地雷を外すのが大事、
ビジョンを共有する。
このビジョンを共有するために、高度すぎるツールは使わないように、
プロトの時は、問題を細かく分割して、いろんなアプローチを考え、
長所と短所を比較して、ベストを探す、

紙やPOPはどうでもよくて、自分の使いやすいツールを使う、
ベストを模索する。
それが紙であってもなんでも良く、
紙だって、そのまま書くひとも、切り取って書く人もいる。
皆さんがやりやすい方法でやればよい。

まずはじめてみよう。
30分使うだけで、成果物は大きく変わる。

[&] CSS Nite LP33 #6

CSS Nite LP33
----------------
ディレクター・デザイナーのためのプロトタイプ制作とシナリオ作り 土屋 尚史(グッドパッチ)

グッドパッチ
UIの設計とデザインに特化した会社です。
大企業だと、新規事業開発系、アプリ、サービスのUIなど。
UIの会社ではあるが、サービス企画、サービスデザインから、実行フェースまで。
Gunosy 初期のUIから、バージョン2.0 までのUIを担当
3年前にシリコンバレーで働いていたときに Gunosy の関さんと出逢って、
手伝うことになり、現在はトップベンチャーになって、
最近新しいバージョンが出て、炎上していますが.....
グットパッチがやったの?と言われていますが.....

ちなみに、UIが変わってから、使わなくなった人は?
レビューが荒れてますが、アップデートが入ってから、なんとか..
僕的にもショックだったんですが、彼らはキュレーションメディアではなく、
もっと上に行くということを決断したということで。今も応援しています。

MEMOPATH というブログもやっています。
http://memo.goodpatch.co/

シリコンバレーに、社員全員を連れていきます。
売り上げで1億円こえたら...
利益はそれほどでていなかったのですが、借り入れして、700万かけて
シリコンバレーに行きました。

サービスのプロトタイピングと、ストーリー設計の2つの話しをします。
チャットワークのモバイルアプリも、HTML/CSS/JavaScript で作ってみています。
チャットワークさん、iOSエンジニアが以内ので、アプリが出ないんです。

日に日に高まるプロトタイプの重要性、
プロトタイプの作成は、労力を投入する前にアイデアを検討するための手段

●目的
作ろうとしているサービスのニーズがあるかどうか?
ユーザビリティと設計の問題点の洗い出し
技術的な要件を固めるため
ターゲットユーザーから適切なフィードバックを得るため
チーム内(クライアント)との意識共有

今までのアプリ制作フローの問題点
社内に iOS エンジニアが居ない。

今までのアプリ制作の問題点
エンジニアがいないと動くプロトタイプが作れなかった

●ディレクターが動くことを想像せずに設計/デザイン
●動くモノになってから使いづらさに気づく
●エンジニアに意図が伝わらない

動くイメージできずにデザインするので
何度も手戻りが発生し、ユーザーテストの時間が削られ、
劣悪な出来のアプリがマーケットに。

各フェーズでプロトタイプを作成して
ユーザーテストを重ねればクオリティは上がる

非エンジニアでコードが書けないディレクターやデザイナーには
使うのが難しい。

グッドパッチで主に使われているプロトタイピングツール
POP
Flinto (作っているの日本人)Ecofone の人
Invision(Webのプロトタイプ、チームでコラボレーションする時)NYの会社、2年くらい。11億円VC調達
Prott (グッドパッチで作成中、来週中からクローズドβ)

設計段階からワイヤーフレームを Invision で管理して、
Invision ではリンクを設定することができる。
かなり情報共有の効率があがった。
コメントがつけれるのが便利
モバイルの方は使いづらい....

Prott も簡単に説明します。
スケッチのノートも、モバイルのアプリも出します。
最初もっと予定していた機能があったんですが、全然実装できなくて、
とりあえずプロトとして出すバージョンです。
チーム内でコメントがつけれるようになっていたり。
Flinto と Invision のいいとこ取り
Web アプリとして使えるようになる。
実際に動くモックが、簡単に作れるようになりました。

プロジェクトのフェーズごとに作るプロトタイプは変わる
サービス設計フェーズは、ペーパープトロタイピング MVP

要件定義フェース、ワイヤーフレームモック
どういう情報が、どういう要素、APIの設計ができるくらいまで、

ビジュアルデザインフェース
デザインプロトタイプ、ユーザーにヒアリングしながら、テイストを決めていく。

ここまでのフェーズは Prott, Flinto, Invision
などのツールを使えば充分伝わる

単純な遷移は少なくなってきて、より、アニメーションが入ってきて、
インタラクションをゴリゴリやっているアプリの方がうれる。
一番難しいのはインタラクションの部分、
インタラクションプロトタイプになると、一気に難しくなる。

Framer.js アニメーションを作る
Hype http://tumult.com/hype/
Origami 柔軟に作れるけどハードルが高い

After Effect で映像を作る
「ポンポンポン」と言われてもエンジニアがわからない。
Flash でアニメーションを作る

CAPPTIVATE.co いろんなアプリの動きのパターン、かなり勉強になります。

あとはひたすらコミュニケーション「ギュインとして、もっとヌルヌルに」

単純な遷移ではない、インタラクションデザインのスキルが
UIデザイナーに求められている。

全体のユーザーストーリーを考えてから、プロトタイピングしましょう。
カスタマージャーニーマップ、結構ハードルが高い
ラフマップから作ろう

ストーリーは一回考えて終わりではない
ユーザーが実際どうでしょう?というのをターゲットユーザーに聞いて
ストーリーを見直したり、ラフなマップを作って、
ストーリーを見直すのをひたすら回していく。

全体のストーリーを
段階的ストーリー、

ユーザーオンボーディング、
ユーザーが最初にサービスにおとづれた時に、
いかにサービスの最初の体験をさせ、ユーザーを優良顧客にしていくかのプロセス

User Onbord というサイト
http://www.useronboard.com/
ひたすらコメントとともに紹介しているサイト

uxarchive.com/
アプリのオンボーディングのプロセス

こういうプロセスを考えるのが重要。
スタートアップや新しくサービスを作るばあい、
最初からフルフルで機能を作ることはなく、競合よりも劣っている場合がおおい、
チュートリアルだけを考えるのではなく、サインナップをしてから、
どういうメール、メッセージがでるのか? というところまでデザインする。
ユーザーが離れて戻ってこないのではなく、

Square Cash のプロセスが面白くて、
メールアドレスを入れて、メールを送ると、
スクエアが $1 あげる、
$1 を上げるので、デビッドカードのナンバーを入れると、会員登録を完了させる。
すごいシンプルな作り、

Design Better
Finto も良く考えられていて、
当然最初に画像を持っているわけではない、
プロジェクト作っても何も素材がない、
お試し画像をあらかじめ用意してある。
最初の素材がそのまんまチュートリアルになっていて、
競合サービスなのですが、パクろうと思っています。

パクるの大事です。

グッドパッチのUIデザイナーは全体を俯瞰してデザインをするために、
モバイルアプリは、Photoshop ではなく、Sketch を使用
http://www.bohemiancoding.com/sketch/

プロトタイプを作るのが前提ではない、
作っては壊して、
考える時間を多く作らずに、なるべく早く、動くプロトタイプを作る

今 30名、専任はエンジニア3名

[&] CSS Nite LP33 #5

CSS Nite LP33
----------------
実例に学ぶ、“失敗しない”UIデザインのコツ 新免 孝紀(ChatWork)

チャットワークは、チャット/タスク/ファイル/ビデオ通話
Tokyo 15名、Osaka 13名、USA 6名
エンジニア 15名、デザイナーが 4名
社内のやりとりはすべてチャットワーク、
取り引き先もチャットワーク

ChatWork はもともと社内向けツールとして開発
自分たちが使いたいツールをエンジニアが作成
欲しい機能をどんどん追加
デザインが破綻

ビジネスシーンを楽々に

開発フローについて
UIパーツのガイドライン化
ユーザーの声への対応

ワークフローの改善
企画>UIデザイン>機能実装>検証>リリース

リニューアルの目的
ターゲット
仕様書
デザインカンプを作成

実際のデータを入れると印象が異なる

本番のデータを入れると、いろんな名前があって、見にくいものになって、
情報が詰め込まれていて、色も見にくい
よく使う機能のクリック数が増えてしまった。

すべてムダに....

●実際のデータを入れてみると印象が変わる
●インタラクションの確認ができなかったので、実際に触ると使いにくいものになっていた
●静止画でUIデザインを繰り返し調整しても根本解決につながらない

UIデザイン、実装、検証をまわしながら開発
無事にリリース!

早い段階でのプロトタイプでの検証が必要
触れることで、静的なデザインでは気づかなかった問題点に気づくことができる
本番に近いデータやインタラクションを実装することで、精度の高い検証を行える

●UIパーツのガイドライン化
デザイナーだけでなく、エンジニアも画面設計をおこなっている。
それぞれ独自のルールでやっているので、統一感がない

似た形のアイコンでも意味が異なる
一貫性のないボタン
スタイルガイドを作りました
用途やコードも一緒にガイドライン化、コピペで使えるように

ユーザビリティーの向上
開発効率の向上

問題のあるところを明確にし、ガイドライン化する
ガイドラインは共有する
ガイドラインは一度作って終わりではない

ご意見/ご要望を集める
Twitter からも集めている。
リアルタイム検索からも集めています。
参考になる声が非常に届くのですが、
すべての要望を入れるとデザインが破綻

チャットワークのコアコンセプト
仕事上の様々なコミュニケーションを楽しくする

メッセージキドクの表示
入力中の表示
オンライン/オフラインの表示

なぜ追加しないか?
キドク、オンライン状態が常に伝わってしまうと、プレッシャーやストレスを生む原因
キドクがバレないように

「ビジネスシーンを楽々に」?
コンセプトに沿って改善したが失敗した例も。
入力エリアのサイズ変更、(手動)でドラッグして広げたりできるようにしていました。
楽に出来るようにできないか?

入力エリアのサイズを文字量にあわせて自動変更
非常に不満になった。
もともとあった機能を削ると、不満につながりやすい

●一度追加した機能は不満や批判につながりやすい
●すぐにユーザーの声に反応するのではなく、コンセプトを元にするしないと判断する
●製品のコンセプトを明確にし、共有するのが重要

●プロトタイプを用いた開発フローで早期に検証を行い、大きな手戻りを防ぐ
●UIパーツのガイドライン化で、一貫性のあるデザインを提供
●製品のコンセプトを明確にし、共有するのが重要

[&] CSS Nite LP33 #4

CSS Nite LP33
----------------
人間だからこそできる、気配りデザイン 秋葉ちひろ(ツクロア)

今日、気配りデザインということで、ググっても出てこないです。
普段デザインする時に考えていることを突き詰めると「きくばり」になるかと。

普段、Webサイトのデザイン、設計、プロトタイプの作成、
フロントエンドのコードを書きながら、デザイン全般をやっています。
執筆や講演も、FireFoxOS, Effective Android, 日経 Linux でも連載しています。
デザインに関するところを幅広くやっています。

気配りデザイン?
アプリ、普段作ったり、使ったりしていると思うのですが、
使いやすい、使いにくい、そのニクイの判断基準はどこにありますか?
何で?つかいやすいと思うのですが、
ちょっと考えてみると、答えは凄く難しいと思います。
設計とかを見るようになってきて、基準が何だろう思ってきて、
その判断基準として、こういう学問とか、上流の設計に必要な知識は
あると思うのですが、これって、ぶっちゃけ専門的すぎるので、
ちょっと壁が高いと思うのですこれを「気配り」に考えてみれば良いと思ったのです。

人と人の例をだしてみたいと思います。
女子がカフェでお話しをしていると思います。
ウェイトレスさんを目で追って、気になる感じで見ていたと思います。
青い人が気づきましたが、きになりながら話しを続けてしまいました。
あ、今日たばこ吸ってない!灰皿がないんだ!と気づいて、
店員さんを呼び止めるわけです、すいません灰皿下さい!

ユーザーとアプリの関係に置き換えてきます。
アプリの人が何かをしたいということに気づいて、
ユーザーが何をしたいんだろうとアプリが考えて、
ユーザーがわざわざ頼まなくても、いいように気配りする。
気配りに落とし込めるんじゃないかな〜と思っています。

ユーザーが快適に過ごせるために

要求をまとめてみると、
 どんなときに
  たばこを吸いたい時に
解決:なにができるか?
  灰皿を頼む

●気配りデザイン
 ユーザーが快適にアプリを使えるために施すデザイン

なぜ?気配りデザイン
ごちゃっとしていたら、何を選んだら良いかあわからない。
見るだけでもきついのに、操作すると、もっときつい。
ユーザーが「ごちゃ」と思った時点でダメ。
ひとと人との気配りに落とし込んでいくと、誰でもわかる。

誰でもできる気配りデザイン
専門の人がいない場合、デザイナーやエンジニアが気を配って作らなければいけない。

3つの気配り
1) ユーザーの手間を省く気配り
2) 操作を予測させる気配り
3) 気持ちよく操作させる気配り

●ユーザーの手間を省く気配り
デンシカルテ的デザイン、歯医者、歯科衛生士、歯医者の受付の人が見るようなサービス
もうすこし掘り下げて使いやすくするには?

要求:どんな時に?
 患者さんと会話するとき
何をしたい?
 来院頻度
もう一工夫欲しくは無いですか?

解決:何ができるか
 今を起点にする時間の計算をする
 タイムライン系ではあたりまえになっている。2-3年前はそういう概念が無かった。
 日付と時間ではなく、1時間前、2日前、1ヶ月前で表記すれば良い

●回数や時間の尺の表示に関して
乗り換え案内、所要時間/金額/乗り換え回数
読まないと理解できない、もうちょっと良い見せ方があると思っている

要求:どんなときに?
電車の経路を調べるときに
早くて安くて楽な経路を知りたい

乗り換える回数/場所を見やすくする
 乗り換え回数が一目瞭然
 どこで乗り換えしたいかも出ている、考えなくていい
 実際こういう風なアプリがあって、Expedia トランジットの時間が書かれている。
 横に長いと滞在時間が長いことがわかる

●URLをシェアしたいとき
Google+ のアプリ、リンクを押すと、何もしなくても、ペーストが行われる。
ユーザーがいちいち長押しして貼付ける手間を省いている。

要求:URLコピー
URLがコピーされていたら自動で貼付ける
この手間を省くだけで、アプリは格段に使い勝手が良くなる。

●スマホでカッコを入力するとき
Simeji の開発をしていたとき。
両括弧を表示して、その『』の間に、カーソルが間に入ります。
Simeji になれると、iPhone では辛すぎる

●ユーザーの手間を省く気配り
 ユーザーが頭をつかわなくてもよい
 ユーザーの手間を減らし目的のことが早くできるようにする

●操作を予測させる気配り
どうしたらいいの?
アプリの方で操作をうながす

●一瞬出てきて消える
Moldiv というアプリ、一瞬ポヨンとなって、メニューが左側にあることで、
ユーザーの操作をうながしている。

●タップするとその方向に動く
右から左に出てくることがわかる。
iPHone のロック画面から起動するカメラアプリ

●ページ送りを予想させるようなデザイン
Google+ のコメント表示、重なって表示される。5件表示される。
奥行きで重ねるので予測させる。

●操作を予測できる気配り
チュートリアル無しでもユーザーが自然に操作を取得できる。

●気持ちよく操作させる気配り

●スライドショーの動きを考える
ページ送りの際のトランジション、
スワイプしていると、次の写真が半分でてきて、次の写真に移る
Android のホーム画面、次のものが奥から出てくる、
Android のような動きだと、三半規管が弱い、目の負担が少ない、
目の動きが動きすぎなくて、負担がかからない。

●タイムライン
Google+ でタイムラインを送っていきますよね。
普通に次のタイムラインがちょっと遅れて出てきます。
微妙に深度をもって表示されます。
この意味は?

 次のカードが出てくる遊び心
 常に一定で動かすより、わくわくした気持ちにすることができる
 
●画面が大きな端末での動き
 Facebook アプリのリンクを開くところ。
 真ん中から分かれて開く。

真ん中から割れることで、あたかも自分たちのアプリ内でのコンテンツであるかのように思わせる体験
違うアプリにいったのかな?とユーザーが思ってしまうかもしれない。
FB内のコンテンツ

●気持ちよく操作させる気配り
 身体的に負担がかからない
 人の感情に訴えかける

誰でもできる 気配りデザイン

●待ちで見かける気配りデザイン
ユーザーの手間を省く街の気配り
 駅の行き先表示
 駅の電光掲示板 乗り換えや通過駅
 井の頭線、どこで接続するのかが行き先表示のところに表示される

●ユーザー体験
野菜の売り方、焼き野菜、炒め物、
透明じゃないレジ液晶だと圧迫感が出る、安心できる。

●音による気配り
扉が開く時と、締まる時の音、
レジ、右と左のレジで音の高さが違う。
自分の音だということがわかるように。

気づくこと、しっかり観察する
他と違う点に気づく

人に体する気配りと同じ
いったん人に置き換えてみる

理由を考えること、しっかり言語化する

気配り上手になろう!

[&] CSS Nite LP33 #3

CSS Nite LP33
----------------
アプリケーションのイディオムデザイン 上野 学(ソシオメディア)

普段、コンサルタントとして話すことが多いのですが、
会話する相手はネクタイしているおじさんなので、
自分より若い人の前で話すのはあまり無いのですが、

UI/UX ということで、専業系で15年ちかくこういうことをやっています。
UXの良いものを作ろうというと、ユーザーを観察しよう。
好きな観察スポットがあって、某牛丼チェーンに行きます。
何ヶ月か前に、チケット販売(食券)の画面があります。

[店内] [お弁当] の選択肢がありました。
[店内] を押すと、メニューらしきものが出てきます。
[牛すき丼] を押します。
もう一画面でてきます。ごちゃごちゃしていてわかりません。
その中で一つを選びます。
やっと買えましたと思ったら、
その瞬間、この機会は「お金を先に入れてください」と
大きな音が流れます「えっ?」となります。

非常にこれは悪いデザインだな〜と
初めてこの機械を使った人は、95% 機械に怒られると思います。
プロトを作れば一瞬で問題が解るようなものです。

外国人のお客様が大量に来た時、「お金を先に入れてください!」と
言われても、日本語が解らない。「どうやって買うんだ?」となった。
今のところ改善されていません。

こういったことは、テストすれば解決するのではないかと?
そもそもアンチパターンとして避けるべき。
設計するときの基本的の、よくやるやり方をお話しできれば。

@manabuueno
ソシオメディア株式会社
90年代後半から、Apple Japan の Webサイトの構築でした。
基本のフォーマットはアメリカのもので、日本のローカライズで、
Apple ガラモンドを日本でのデザインガイドラインを作っていました。
ソシオメディア、UXデザイン戦略コンサルティング

われわれの仕事のほとんどは見せられない。
初期の段階のコンサルティングなどだったりして。

国立国会図書館サーチ
学術系、
法律関係のデータベース、複雑なものが100画面あっり、
フジテレビオンデマンドの設計デザインをしたりしています。

Testwell というエディタ、JavaScript でアクションを追加できる。

ウェブ
ビジネス
モバイル
タブレット
デスクトップ
専用端末
ウェアラブル

ウェブ戦略としての「ユーザーエクスペリエンス」
Web情報アーキテクチャ
デザイニングインタフェース

MacOSメタファー、
ちょっと前の Podcast アプリ、オープンリール風、バカバカしいところで凝ったものを作るのがいいところ、
フラットデザインみたいな話しになってきて、
Window8 も、Google Now も、
iPhone も。
この時に、前のメタファーみたいのからフラットになって、
スキュオモーフィックから、フラットになりました。
アドレス帳、装飾が減りました。ゴテゴテしたところが減りました。
それだけじゃないと思っています。

アドレスブックみたいなメタファーがデザインされています。
ページをめくる操作とか、
ブックマークとか、
それがべたっとしたわけですが、
情報の見せ方が変わっています。
3階層、スクロールも面積が増えました。
単純に現実のものっぽいグラフィックよりも、
情報の見せ方が変わっています。
非常に前のものと、最近のものと、見た目も変わっています。
画面構成要素はかわっていないのですが、
月を跨いでスクロールできるようになっている。
メタファーとしてカレンダーは月ごとにめくるものだったのだが、
コンピュータの動きを考えると、エンドレスでスクロールしても良いという
気づきがあって、単にフラットになったというか、
ソフトウェアならではの情報操作に変わってきている。

スキュアモーフィック → フラット
メタファ → イデオム

イデオムに変えていく。
我々がパソコンを使うとき、インタラクションの階層があると思います。

マウス移動。マウスダウン、マウスアップ
テキスト表示、四角、丸、
OSが持っている機能があると思います。

押し下げて離すとクリックになります。
ダブルクリック、ドラッグ&ドロップ
アイコン、チェックボックス、メニュー

イデオム
ビジュアル言語として、あるいはインタラクションのパターンとしての慣用表現
プリミティブの組み合わせでアプリの概要を示す
ちょうど良いメタファを探すことよりも、学習しやすいイデオムを作る
インタラクションの記号性や規則性から、ユーザーが自然にその意味や扱い方を学習できるようにする
すべてのイデオムは学習を必要とするが、優れた井でオムは一度学習すれば身に付く Alan Cooper

iPhone 、コンテンツを触ればスクロールする、スクロールバーではなくて、

抽象度がいろいろありますが、
フォームが整然と並んでいると、入力フォームだと、なんとなくわかる。
モーダルシーケンス、ウィザード、これはモーダルシーケンスだなとわかる。
文字のスタイルを変えるボタンが上部にあれば、エディタだとわかる。
ツールパネルみたいのがあれば、これはグラフィック系のキャンバスだなとわかる。
格子状に線がはいっていれば、スプレッドシートだなとわかる。
Webブラウザだなと解る。
メディアプレイヤー、再生/ストップ/ポーズ
全画面でグラフィックが表示されていればゲームだと思う。
人のアイコンが並んでいればタイムラインだとわかる
マップっ報じ

一覧と詳細
マスター&ディテール
アプリケーションを作る上で基本です。
一覧の中から選ぶと、詳細が表示される。
カレンダー、ファイルマネージャー、ビデオ/サウンドオーサリング
チャットみたいなもの、
スプリングボード、アイコンが並んでいるものがあればホーム画面だとわかる
スライド、タッチパネルデバイスで、指で横になぞると、次の画面に移るイデオム
古いiPHoneを見ると、前後の矢印がある。最近は前後ボタンが無くなってます。
イデオムを学習したのだから、余計なものとしてボタンをがなくなった

イディオマティック・デザイン
それをどうやって作るのか?

まずアプリケーションを作るとき、
ウィンドウという概念、GUIの基本的なもの、
iPhone にも ウィンドウという概念はあって、
ドキュメトウィンドウ、ドキュメントごとにウィンドウが開くもの、
アプリケーションウィンドウ、アプリケーションが1画面で全て含まれるもの、
ダイアログ、パネル も一種のウィンドウ

ブラウザ、モバイル、もアプリケーションウィンドウです。
それぞれに共有して、ボタンや機能がついている。
ブラウザならではの機能があったり。

オブジェクト VS タスク
ユーザーに何を最初に見せるのか、
例えば、タスクを最初に見せるケース、
同じみの ATM , やることがボタンとして並んでいます。
タスクが最初に見えています。
オブジェクトベースのものもあります。
もの、対象物が最初に見えているもの、写真ギャラリーなど。

まずここでの考え方、

オブジェクトベース
 同じ性質の対象物が複数あり、共通のアクションがある
 一覧と詳細
 ドキュメントウィンドウ
タスクベース
 タスク同士が独立している、あるいは対象物が一つしかない
 モーダルシーケンス

●顧客管理システム
ある顧客管理システム CRM, ここで何をやるかというと
左にメニューがあります。顧客がどういうステージにいるかというステージで
分けられています。
ある顧客の情報を見たいと思えば「顧客情報」メニューを押します。
「これはいけませんね〜」と作り直したのがこういうものです。

水平のグローバルナビがあって、

●コンテンツオーサリングシステム
ページの追加と削除/内容編集/ページ設定/サイト設定
ページの追加
ページの移動
ページの削除

サイト設定があって。

ここで何をやったのか?
基本手順。

●デザインパターンを知っていること
●オブジェクトベースの場合
 ユーザーにとっての主要オブジェクトを抽出
 オブジェクトの階層に応じてペイン/ドリルダウンを作る
 オブジェクトの選択 →アクションの選択

●タスクベースの場合
 タスク(業務)を把握
 作業効率の高い順序でモーダルシーケンスを作る
 タスクの選択 →必要なパラメーターの入力

先ほどの顧客管理システム。
オブジェクトベースに作り直しました。
案件検索はタスク、ごちゃごちゃになっていたこと。

主要オブジェクトはスケジュール、案件、顧客、営業資料
これを整理して、案件とか、オブジェクとのグループ名を分類項目として持って来て、
レイアウトは当然、上の方にあるものが階層が高い。

ページというオブジェクトがあって、
ページの内容というオブジェクトがあって、
サイトという概念がある。

サイト、ページの一覧、ページ設定、メタデータ、内容、

●コツ

タスク選択ではなく、オブジェクトグループの選択から操作が始まるようにする
処理対処オブジェクトの一覧をできるだけ早く見せる。
エンティティアイコンをつけるといい。(ページアイコンとか。目印になる)
同じ性質ものがならぶところにアイコンを作る
タスクをタスクの数だけでなく、

通過換算
1 ドル を 円で。
左側と右側が=になろうとする、線形の流れはなく、どこから操作しても良い

直進/左折/右折
ハンドルという新しい世界観、新しいイデオムを発明していくことが求められている。

イデオムオリエンテッドなプロジェクト
上流工程でちゃんとやります。

What - What - Gap - How
プロジェクトの開発プロセスの中で、上流でデザインする
物として成り立つのか?意味があるのか?初期の段階で作らないといけない。

企画の始まりはデザインの始まり。
仕事でも要件定義とかRFPが出来る前、の支援をすることもあるのだが、
その段階でデザインを作ってしまう。
プロジェクトによっては許されないこともあるのですが、

イディオム、プロト、リファレンス実装
本番と同等のコードを書いて、検証する。

イディオムデザイン
プロトタイピング&テスト
リファレンス自走&テスト


[&] CSS Nite LP33 #2

CSS Nite LP33
----------------
UIデザインのパターン化と効果的な実践方法 池田 拓司(クックパッド)

クックパッドだけじゃなくて、いろいろなアプリのスクリーンショットを見ながら
みなで考えながら見ていきます。
http://tikeda.net

サービス全体のデザイン、ユーザー体験の責任
フロントエンド基盤
サービス

●UIデザインのパターン化とは
●スマートフォンの基本UIパターン
●メッセージUIの比較と特徴
●アイコンのパターン
●パターンを使ったプロトタイプ
●終わりに

UIデザインのパターン化とは?
画面をコンポーネント単位に分割
設計していくなかで使うものを選んでいく。
機能やユーザー体験に合わせて各コンポーネントをチョイス

こんなことに使える
いろんなものを見て、知ることができるので、
引き出しを増やす
パターンを使って考えることで、早くプロトタイピングすることができる。

「なんか横からシュッと出てくるやつ!」
「タップしたら、ポワンて開いてしばらくしたら閉じる感じ」
「トグルになってて切り替わる感じ」

メンバー間の共通言語を作る

パターンを使うことで、いつも同じような、
だいたいこういう時にはこういう動き、
自然な操作を提供することができる。

●デザインの引き出しを増やす
●素早くプロトタイプができる

●スマートフォンの基本UIパターン
いろいろなタイプの画面があります。
いくつかの種類に分けられます。

導入画面/トップ画面/一覧画面/詳細画面/入力.管理画面

画面のパターンによってよく使うUIがある。
プラットフォームに最適なもの

iOS Human Interface GUideline
Android Design

プラットフォームにガイドラインがある
プラットフォームに最適な UI

iOS
画面中央に画像タイトル
左側に前の画面のタイトル名を入れたバックボタン

トップバーと、タブバー
スピナー、セグメンテッドコントロール

ユーザーの動線
 検索
 具体検索
 お気に入り
 メールのリンク

バルーン・ツールチップ
ダイアログ・アラート
トースト

どれも正解も間違いは無いのですが、
どういう文脈か、どいう特徴かで使い分けができる。

●ダイアログ
確実に伝えられる一方、画面が増えるため乱用するとストレス
危ないアクションを事前に確認するのに有効
iOSもAndroidも標準のものがある

●トースト
確実に伝えられない一方、ユーザーの行動を妨げない
想定どうりのアクション完了後に表示するのに有効
Androidアプリでは標準のものがある。

●バルーンツールチップ
ユーザーがアクションを行った場所を的確に示していれて気がつきやすい
標準のものは無い

●アイコンのパターン
さまざまなアイコン
どれが何のアイコンかわかりますか?

http://www.slideshare.net/mobile/schoowebcampus/20131225schoo

●似通ったアイコン
更新・リリード、右か移転、同期/更新、リプレイ・リトライ

パターンだけを使っていても、新しい試みができない。
新しいアイコン、
「送信する」アイコンが紙飛行機に
紙飛行機は、中国発祥で、世界中で使われる

Androidオフィシャルのデザインデータ
クックパッドの事例、
一つの共有ファイルにして管理しています。
サービス全体でアイコン、iOS, Android ではと異ならないように、
一つのリソースを複数人で共有することで誤解をうまないように。

アイコンの期限を知る
readymag.com/shuffle/ui-symbols/

パターンを使った実践
CSS Frameworks
cssnite.jp/archives/post_2503.html

デザインデータ作成の効率化
Phootshop でデザインデータを読み込めるようになった。
既存のコンポーネント集の活用

Flinto のパターンを使って検討
http://www.flinto.com/
トラジションのパターン

[&] CSS Nite LP33 #1

CSS Nite LP33
----------------

ブリッジビルダー (Bridge Builder) 坂本 貴史(ネットイヤー)

IAをご存知ない人もいるかもしれませんが、
役に立つ内容をお伝えします。
私はグラフィックデザイナー出身です。
ネットイヤーに所属しています、マーケ主体です。
制作会社の人であれば、オーバーラップしている部分があります。
どちらかというとマーケよりの話しです。

IAシンキングという言葉、2011年、本を書いて、
その中で使った言葉です。
デザインに関する話しは、無くならない話しですが、
情報設計、情報アーキテクチャ、解決方法を生み出す手法として、
IAシンキングという言葉を使っています。
IA, UX 、解決手段としての IA.

●ブリッジビルダーとは
●ジャーニーマップの要求整理
●タッチポイントのデザイン
●デザインパターンの活用

たぶん、話しがカブルかもしれません。
少しつづ捉え方が違うので、業務と重ね合わせてとらえて頂ければ。

●ブリッジビルダーとは
IAの中で、有名な絵、大陸と大陸をつなぐ橋が IA
バズワードだけでは?
視点が存在します。
IAの話しのなかで、とらえかたが存在します。
サイトマップ、ワイヤーフレームの視点と、
社会環境、情報、学問的な分野から話すこともあります。

ユーザー - コンテンツ
戦略 - 戦術
プラットフォーム - チャネル
研究 - 実践

「お見合い」になりがちなさまざまな間を取り持つ役割。
その関係性を構築すること。

伝え方、伝える方法の問題でもある。
IA, UI と UX の共通言語としての IA, ブリッジビルダーとしての IA

UX と UI の間にもブリッジが必要です。
UXって結局なんだろう?
UXを研究しているのであれば、最終的にはUIデザインになるのだろう。

気をつけなければいけないのは、
現象/研究分野/実践

昨夜衝撃をうけた「おっぱいUX理論」
ながなが説明するよりも、おっぱいUXを見た方が早いです。

それはそもそも、今起きている現象のことか?
なぜ起きたのか、科学的な解明なのか?
どうやって提供し続けられるのか?

研究者や学者の話しをしても仕方が無い、
何かを創り出すことの方が重要。

観客:デザイナーの人が 80%ぐらい。

作っていく取り組み自体は UXD と呼ぶ
単なる現象なのか、根拠なのか?
作り方の問題、作るプロセスの問題になる。

What do you make ?
あなたは何をつくりますか?

この中で Web サイトを作っている人の中で、
コンテンツプランを考えている人も居ると思います。
例えばファイルリストを作っています、マークアップしています、
最終的にあなたが作っているものは何なのでしょう?

プロダクトデザイン
サイトやアプリ、広告
サービスデザイン
ステークホルダーマップ、ジャーニーマップ

プランニングしています!という人も、
きりわけ、視点が存在します。
プロダクトデザインは、サービスデザインの中に包括されます。
Webを含めたサービスもデザインしていることになる。

PX - SX
プロダクトエクスペリエンス - サービスエクスペリエンス

体験をデザインするというのはどういうことを言っているのか?
PXをデザインするということ、効果測定などは関係無い。
Webサイトをどこで見る?どこでリアルな店舗に行くのか?
そうすると SX となる。
必ずどっちがどうということではなく、二つの視点があります。

あなたは何視点を持っていますか?

●ジャーニーマップの要求整理

ジャーニーマップはどういうものを差すのか?
企画:仮説シナリオの開発
分析:チャネル横断の動線分析

企画に使う場合があります。
現状がどうなっているのか?
使い方、方法についても二通りあります。
サービスデザインの文脈でいうと、
使うことによって、クロスチャネルの状態が検討できます。

現状課題の可視化 -> 制作者
インプットになる場合があります。
例:製薬会社のエクスペリエンスマップです。

------------------------
ステージ
エモーション
ステークホルダー
ユーザーフロー
------------------------

例:住宅ローンのジャーニーマップ

-------------------
ステージ
ユーザーフロー
コンテンツ・機能
ユーザー課題
ビジネス課題
改善点
-------------------

例:ジャーニーマップの例

--------------------
ステージ
ユーザーシナリオ
エモーション
デバイス
要求事項
--------------------

提供するアウトプット先がどうなのかによって変わります。
課題分析なのか?

クロスチャンネル
タッチポイント
マルチスクリーン

網羅性は重要ではない
3つを抽出することで、課題を見いだすことができる

要求事項を整理するためのツール
仕事をしていくなかでジャーニーマップが作るのが仕事にならない
要求事項として伝える話しなのか、単純に共有したいだけなのか?

●タッチポイントのデザイン
具現化しなければいけない。
マーケティング視点において UIの解釈も変わってきます。
タッチポイントはどこなのですか?
一つの接点をタッチポイントと読んでいます。
ジャーニーマップに書かれていることを抽出します。

登録ベージ
イシュー:登録に時間がかかる
エモーーション:登録メリットの説明
KPI:会員登録数

これからはこのタッチポイントをデザインするという仕組みに変わってきます。
リニューアルの考え方とは全く違う、
一つの例ですが、3つのポイントがあり、これをクリアしているかが
要求事項になります。

タッチポイントのデザインは? ユーザーテストをします。

プロトタイピング
ユーザーシナリオにある画面
その画面の目的は的確
全面リニューアルとは異なる

表層→骨格→構造→要件→戦略
逆工程でみていきます。

●IA Thinking
現状を調査し、情報を可視化した上で、目的や課題を
明らかにし新たな情報の提供方法を構築すること

現状の課題
モバイル向けレイアウトになっていない
文字が多く読みにくい
読んだら終わりの利用方法

プロトタイピング
モバイル向けレイアウト
文字サイズを読みやすく
ブックマークや共有の利用方法

Prototyping
デザインは仮説です。その仮説が合っているか間違って
いるかを見極めるのが評価であり、分析につながります。

●デザインパターンの活用
ノンデザイナーの仮説を手助けするツール
「デザインパターン」があります。アイデア具体化の助けになります。
IAパターンと、UIパターンがあります。

IAパターン
タブビュー
フィルタービュー
ハブ&スポーク
弁当箱
マトリョーシカ
階層型
UIパターン
ナビゲーション
フォーム
テーブルリスト.....

Mobile Design Pattern Gallery
書籍もあり

RWD レイアウトパターン
ナビゲーションの処理に集中する
今あるものをスマホ用、タブレット用にする情報デザインができる

現状をどうやって変えていくのか?
どうやって要求として伝えていくのか?

IA Thinking
現状を調査し情報を可視化したうえで
目的や課題を明らかにし新たな情報の提供方法を構築すること

Just in type ; prototyper を使っている。

3/20/2014

[&] Design Principles of Android Wear (Japanese Translation)

------------------------------------------------------------
Android Wear のデザイン原則(日本語訳)
------------------------------------------------------------
Design Principles of Android Wear(原文)
http://developer.android.com/wear/design/index.html


Android Wear デバイスは、ネットの世界に接続されたり、現実世界に存在したりできるように、ちょうど適切な時にだけ適切な情報を提供してくれます。

ここに Android Wear プラットフォームにおける、素晴らしいユーザーエクスペリエンスを設計するためのガイドラインを示します。Android Wear を設計することは、携帯電話やタブレットを設計することとは実質的に異なります。あなたのコンテンツを Android Wear の世界と連携して動かす方法を説明しましょう。


Android Wear の体験は以下のようなものです:


●状況に応じて対応でき、洗練されていること

これらのデバイスは、コンピューティングに対する新しい認識レベルをもたらします。ユーザーからの注目や入力を要求するのではなく、Android Wear デバイスは彼等の状況と状態を認識し、適切な時に適切な情報を役立つ方法で表示してくれます。それらはタイムリーで、関連性があり、限定的なものです。

●一覧的であること

我々の視野に入らない時でさえ、ウェアラブルデバイスは一日を通してずっと使用されます。効果的なアプリは、なるべく手間を省き、一日中、関連する情報の小さな断片を提供するために、最適化され、情報負荷を最小限にして提供してくれます。短く、機敏で、即時的なものです。

●全く操作無し、または少ない操作ですむこと

小型の外見によりもたらされる強みに忠実でありながら、どうしてもユーザー入力が必要な場合にのみ、Android Wear は簡単な操作で実現します。ほとんどの入力は、タッチ、スワイプや音声に基づいているので、細かな入力操作を必要とする入力が回避されます。身振りや、簡単で、素早く操作できるものです。

●有益であること

Android Wear は、優れた個人秘書のようなものです:あなたとあなたの好みを知っているので、どうしても必要な場合にのみ、あなたの操作を中断させます。そして、予め準備された答えを提供するために常に手元にあります。効率的で、丁寧で、俊敏な反応をもったなものです。

ユーザーの注視を大切にする一方で、世界の残り部分へのスマートな接続を提供することにより、Android Wear は個人的でありながら世界的で、シンプルで洗練され、目立ちませんが、常に準備万端で用意されていることが感じられます。これらの原則を尊重する「通知(ノーティフィケーション)」は、全体的な Android Wear エクスペリエンスの中でもホーム画面で最も有益さを感じることができます。

■通知の UI パターン


Android の通知は、メインストリーム内でカードとして表示され、Android Wear 体験の中核を形作ります。 通知用の主要な Android デザインガイドラインの多くは、Android Wear でも適用されます。ユーザーの関心を大切にし、不必要な中断があなたのアプリケーションの評判にどのように影響するのかに気をつけてください。

通知から、必要の無い文字を省いて下さい。グランサビリティ(一目瞭然であること)のために、文章を読まなくて済むようにしてください。文章ではなく、単語やフレーズを使ってください。ちらっと見るだけで充分で、読まなくても済むようにするのが重要です:あなたのメッセージを伝えるために簡単なアイコン、絵文字、及び映像化表現をうまく使ってください。

いくつかのケースでは、特にメッセージ系のアプリと一緒の場合、カードは1つの画面に収まり切らない動的なコンテンツを含むことがあります。これらの場合では、コンテンツは自動的にカードに収まるように切り取られます。その際はユーザーがタップして拡大した時に、完全なメッセージが提供される必要があります。

通知の優先度は、優先度の高い処理をしながら、唯一時間制限のある通知で、あなたの通知の緊急性を反映させるべきです。アクティブ通知は - すなわちデバイスを振動させるものは - ユーザーへの緊急の通知や行動を起こさなければいけない状況(例えば、設定した時間のリマインダー、親しい友達からのメッセージ)を必要とする場合にのみ使用されるべきです。緊急ではない時の通知(例えば、乗り継ぎ時間、毎日の歩数カウント、ソーシャルネットワークの更新)は、カード表示の流れに静かに追加されるべきです。

●Actions


アクションは、ユーザーがあなたの通知に基づいて行動できるように、あなたの通知の右側に表示されます。最大3つまでのアクションが許可されます。最も頻繁に使用されるアクションは最初に配置されるはずですから、あなたのコンテンツからたった1回のスワイプ動作で次に移ることができます。

アクションは、アイコンとキャプションで構成されています。アイコンは、PNGファイル、透明の背景に白色、64 × 64 DP でなければなりません。キャプションは、動詞的な表現で、短く、自動的に1行に切り縮められます。

アクションは、オプションです。多くの有益な通知がアクションを含める必要は全くありません。

アクションボタンに関する開発者の詳細につきましては、Android Wear用の通知を作成する
[ Creating Notifications for Android Wear ] を参照して下さい。

●Images


画像は、コンテキストと追加のグランサビリティ(一目瞭然であること)を提供しながら、ストリーム内のカードの後ろに表示されます。あなたの画像は、通知の主要メッセージをサポートする必要があります;例えば、スポーツチームに関するカードは、そのチームカラーとロゴを含めることができます;連絡先からのメッセージは、その人のプロフィール写真を表示させるはずです。

カードが部分的に画像の下の部分を覆ってしまうこと考慮に入れておいて下さい。画像は、少なくとも hdpi の 320 × 320 ピクセルでなければなりません。水平方向にスワイプされる際に画像背景は移動しますから、ページやアクションを含む通知上で、横長の画像の方が上手く表示されます。

Android Wear 用の通知を作成する [ Creating Notifications for Android Wear ] の中で示されていますように、大きな画像を追加するためには、任意の通知と共にsetLargeIcon() を使用します。

●Application Icons


アプリケーションのランチャーアイコンは自動的に通知の印として、カード上に配置されます。あなたのアプリケーションで通知タイトルや背景画像をアイコンに使用しないでください。その代わりに、あなたのアイコン自身を識別しやすいものにして、カードや画像で明確で簡潔なメッセージを提供することに集中できるようにしてください。setHintHideIcon() を使用して、このアイコンを表示しないように設定することができます。

■ページ

Pages は、ストリーム内のあなたのメインカードの右側に表示することのできる追加のカードです。あなたの主要メッセージが短い断片に収まらないくらい長い場合には、あなたのメイン通知に多くの情報を詰め込むことでグランサビリティ(一目瞭然であること)を犠牲にしないで下さい。その代わりに、追加のコンテンツを提供するために Pages を使用して下さい。

  

Pages は、メイン通知カードのすぐ右側に表示されます。一般的にそれらは、メインカードのコンテンツの詳細情報や代替ビューを提供するために使用されます。例えば:

現在の気象カードが、その後3日間の予報を表示する追加のページを提供するかもしれません。
次の列車の発車カードは、その次の発車時刻を表示する追加のページを提供するかもしれません。
毎日の歩数カードは、カロリーと距離の関係を表示する追加のページを提供するかもしれません。
あなたが追加するかもしれないページ数に特に制限はありません。
しかし、操作を必要とする通知は、操作が簡単にできる状態であることを確認するために、3ページ分だけを表示するべきです。

Pages は、あくまでオプション機能です。多くの有益な通知機能が必ずしも Pages を含める必要は全くありません。

Pages に関する開発者の詳細につきましては、通知にページを追加する [ Adding Pages to a Notification ] の中で説明を参照して下さい。

■通知スタック

 

Stacks は、同一のアプリケーションからの複数の通知をひとつのカードの束にまとめることが出来ます。ページはひとつの通知についての追加詳細を提供し、Stacks は複数の同種の通知をまとめます。Stacks は、ユーザーが、中に含まれている個々のカードにアクセスできるように拡張することができます。

Stacks は、ユーザーのストリームに負担をかけずに、複数の役立つ通知を追加する方法です。アプリケーションが複数の同時に通知を出すのであれば、それらを Stack にまとめることを検討してください。

Stack 内にある各通知には、別個のページと別個の動作が含まれており、それらはその特定の通知に関連しています。ユーザーは、Stack 内の通知カードを拡張すると、これらの動作にアクセスすることができます。

Stacks について、開発の詳細は、スタック通知 [ Stacking Notifications ] の項目をご覧ください。

■音声応答

 

音声応答は主に、ショートメッセージを音声入力で記述したり、ハンズフリーでの利用を提供するメッセージアプリケーションで使用されます。最大5つまでの提案型返信、或いは広範囲な状態で有用である「自動返信機能」も提供することができます。これらの自動返信機能はユーザーがタップすることで、話すことが望ましくないかもしれない場合でも、簡単な返信を素早く送信する方法を提供できます。

選択肢の中に、シンプルなものだけではなく、あいまいな返答も含まれるようしておいた方が良いでしょう。長めの音声応答は、自動的に音声応答UI で切り詰められるかもしれません。

音声応答の作動に関する開発者の詳細については、通知から音声入力を受け取ること [ Receiving Voice Input from a Notification ] に関する記載を参照して下さい。

Except as noted, this content is licensed under Creative Commons Attribution 2.5.

3/11/2014

[&] Sociomedia UX forum 2014 spring (vol.1) - Marc Retting



Sociomedia UX forum 2014 spring
Marc Retting
http://www.fitassociates.com
@mrettig
--------------------------------------
■UX入門 - カーネギーメロン大学のUXコースより

参加ありがとうございます。
質問等ありましたら、ぞくぞくお知らせください。

Fit Associates では、
組織のリーダーや、組織のチームに対してサービスを提供しています。
企業と顧客へ深い関係を築く方法や、
クリエイティビティへのサービスを提供しています。
企業と、顧客とのクリエイティビティをつなげていくサービスをしています。

沢山の企業の人びとと関わってきました。
ここに書いてありますが、大小かかわらず、トピックを列挙しています。
本日は、ここから私たちが学んできたこと、
米国の大学で教鞭をとっているのですが、そこで話している内容をお伝えします。

第一部は、全体像に対して、
第二部は、特定の分野にしぼった手法に関してお伝えしていきます。

本セミナーでは UX という言葉を使うのではなく、
Design for Experience という言葉を使いたいと思います。
ユーザーという言葉を使ってしまうと、それを図表にする傾向があるので、
あえて、Design for Experience という言葉を使います。
また、UXという言葉を使ってしまうと、デザインの重要なプロセスを
逸脱してしまいます。



■PART ONE

デザインとエクスペリエンスに対して解説していきます。
デザインは物の見た目、スタイルだけではなく、デザインに
含まれている意図が大切です。
すなわち、そのデザインをすることによって、世界が
どのように変わっていくのかという意図です。

そして、そのデザインの原動力になるのがイテレーションです。
大学の教員や、生徒とデザインについて話すと、さまざまな定義があります。
ここでは私が考えるデザインをお伝えします。

デザインには二つのステップがあります。
理解することと、想像することです。
デザインするこは理解から始まりますが、
まずは、物事を理解していないんだということから、
デザインは始まります。
ものごとに対して部分的にしか理解していなかったり、
家族のことさえも完璧に理解することはできません。

ナショナルジオグラフィクという雑誌をご存知でしょうか?
雄大な自然のように、複雑なものです。
ですから、まずは物事をしっかり見極めて理解し、
その後に、想像の世界に入っていきます。
そして、想像したものをもう一度世の中に出していくことで、
理解して創り出したものが間違っていたこと、
正しく理解できていなかったことがわかります。

ですから、自分の理解や、作っていたものが間違っていたことを
認めて、それを繰り返していくことでデザインをしていきます。
理解する、想像するプロセスにも沢山さまざまなことをしなければいけません。
理解したことを一つの形にして、それを想像に活かしていくプロセスが必要です。
そして、作り上げたものを世界に提示して、人々がどのように使うのかを観察します。

ここに、理解と想像のプロセスが沢山ならんでいるのですが、
このプロセスを繰り返し実施することで世界に有益なものをつくりあげていきます。

ときどき比喩として使うのですが、デザインは夜中に森の中を懐中電灯を持って
歩くようなものだと言っています。
森の中を歩いて抜けたいのですが、よく見えません、懐中電灯で一つ一つ照らしながら進んでいきます。
懐中電灯で道を照らす時、足下しか照らしていなければ、蛇に噛まれるかもしれませんし、
先にある落とし穴に気づかないかもしれません。
一歩一歩、歩く道を照らしながら、進むのです。
一歩一歩前にすすんでいけば、森の向こう側に出る事ができます。
ですから、デザインというのはマネージャーが意思決定するために
有益なツールです。

では、ここまで、デザインについてお話ししました。
ここからはエクスペリエンスについてお話しします。
エクスペリエンスは人のことです、テクノロジーは経験を持っていません。
経験を持っているのは人なのです。

デザインやUXに関して活動していくには、世界と世界をつなぐ必要があります。
アダプティブパスの Chris Risdon が作成した図です。



この図の中で、マーケティングで使われる「タッチポイント」という概念を用いて
この図を説明しています。
タッチポイントは、組織である企業と、顧客をつなぐ接点のような部分です。

映画館のチケットを買いたい人と、チケットを売りたい企業をあらわしています。
例えば、企業に属している人なら、会社の中からお客さまに対して目を向けるので
Webサイトを通してしか、目をむけることができます。
Webサイトからしかお客様を感じる、分析の対処としてしか見ることができなくなります。
しかし、企業のサービスを受け取る側のお客様は忙しい生活をしている場合もあります。



家で赤ん坊を育てていて、夕食の準備をしているような場合もあるでしょう。
ですから、お客様視点から見てみると、自分の欲しいものだけを見ているわけです。
私達の仕事は、お客と企業をつなげていく作業です。
求められるものは、経験なのです。会社の経験ではなく、お客様が体感する経験です。
また、その経験はお客さまのニーズにあった正しい機能でなくてはいけません。
意味のあることでなければいけません。



また、チャーミングで喜びを見いだすものでなければいけません。
しっかりと顧客とつながっていかなければいけません。
Webだけではお客様としっかりとつながることはできません。
しかし、お客様からしてみると、チケットが欲しい、チケットを予約したいだけなのです。
お客様が経験するものはシームレスな状態でなければいけません。

企業向けのセミナーで強調していることは、
お客様が欲しているのは実際には「モノ」です。
モノを求めているユーザーがいます。
そして企業は、専門家とともに、提供するモノを作っています。
こういった状況は私達とお客様、お客と企業の棲み分け、
繋がりが持てない状況になってしまいます。

ですからUXに関わる仕事は、商品をつかって、企業とユーザーとの繋がりを
修復していく、それらを提供していきます。
しかし世の中は複雑なものです。
ですから、私たちにとっても、お客様にとっても、簡単な世の中では無いということです。
それから、映画のチケットを販売している企業、Webの会社も、社会の一員なのです。



現在、UXの実戦、現場では、図のような状況です。
会社という非常に大きな「泡」にたいして語りかけています。
その隣りには小さな「泡」があり、家族など一般の人がいます。
UXデザイナーは二つの泡の間にたって翻訳する、通訳する仕事をしているのです。
フェアな仕事ではありません。他にもするべきことは沢山あります。
私達と彼らとの隔たりを残してしまうことにもなります。
どのようにすれば二つの泡をつなげて、別の世界を作ることができるのでしょうか?
会社は意見を交換して関わりを持とうとしています。
小さな泡、家庭、一般の人々が、企業の泡のなかに含まれていく状況になっています。



ですから、どのようにすれば私たちデザイナーをつなぐことができるのでしょうか。
非常に高度なレベルですが、高度なことをしていかなければいけません。



企業のデザインは、1-6までのステップがあります。
一番最初の段階では、UXが認知されていない状況です。
この状況では UXは需要な意味を持ちません。

2の段階では、企業に資金があれば、UXに資金を使ってもいいかな〜と
思っている、少しだけ興味を持っている状況です。

そして、ステップがあがるごとに、企業の一部として活用されていくわけです。
皆様の会社で、UXがどの段階にあるかわかりませんが.....
私の会社はレベル2でしかないという話しを良くききます。
ですから、そういったお客様は、一つ上の段階に行くにはどうすれば良いのですか?
と考え、アドバイスするようにしています。

アジア、北米、一番上の6番に位置する企業は実は無いのかもしれません。

■PART TWO : methods

ここでお話しするのは、導入のパートです。そのメソッドについてお話ししていきます。
他のセッションではもっと具体的にお伝えします。
まず、理解のためのメソッドに対してお話しします。



Awareness Test
アウェアネステストというものです。

このビデオの中で、白い服の人が何回パスしたか数えてみてください。
その中で「クマ」が通り過ぎたのに気づきましたか?

デザインの課題です。世界では目に映ってくるものが多すぎるということです。
人間の目は注目しているものにしか、目にはいってこないのです。
先ほどのビデオでクマは実はビジネスチャンスだったのかもしれません。

二つ目の課題は、人々の生活は目に見えないものだということです。
私がティーポットを作るとすると、様々な種類のティーポットが可能性として存在します。
この絵を見ただけでは、どうして違った種類のティーポットが作られているのか
理解できません。生活を理解してなければいけませ。そのために時間を使わなければいけません。
マーケットリサーチとデザインのリサーチが違う点なのです。

そして、実際にあるもの、それぞれによって、意味が変わってきます。
もし、私がポケットからナイフを取り出したら、皆さんがみたら、ナイフと思われるかもしれませんが、
護身のためのナイフを持っていると思うかもしれません。
しかし、もしかしたら、父親から譲り受けた意味のあるナイフなのかもしれません。
さきほど泡のスライドを見せましたが、小さな泡の中にいる人の声に耳を傾けるのが重要です。

人々の生活を理解するためには様々なメソッドがあります。
これはシカゴのデザイン組織のパンフレットから抜粋してきたものですが、
ここで見るだけでも沢山のメソッドがあります。



メソッドの一つ、人々の生活を観察してインタビューしていくことにあります。
このメソッドを使うことで、実際のユーザーと親しくなることもできます。
私が実際に担当するプロジェクトで、マスクのプロジェクトの時の写真です。
インタビューで聞いた時、研究所でインタビューすると思われるかもしれませんが、
実際の家でカジュアルな状況でインタビューしました。
マスクを使用している人の家でインタビューしたので、詳しい状況がわかりました。
しかし、ずっと一緒にいるわけにはいきません。1〜2時間程度です。

その他のメソッドとしては、道具をわたして、さまざまな記入をしてもらいます。
時にはグループ全体、家族全体とプロジェクトを一緒にして、家族の関係、
グループの関係なども観察します。
こういった人たちは、自分たちが語りたいストーリーをキルトにしたためています。

それではこういったインタビューをどのように活かしていくのかというのをお話ししていきます。
データから私たちに語りかけてもらえるように、データを集めて小さく区切って、グルーピングしていきます。
するとデーターのパターンが見えてきます。沢山のポストイットを使用します。
エクセルを使ったものですが、このようにまとめていくこともあります。
家族の関係とテクノロジーとの関係に関するストーリーです。
横の軸が家族で、縦の軸が家族がもっているストーリーになります。
しかし、表は便利で活用でき、まとめあげることで、関係性がわかります。



同僚が撮った写真で、図書館で利用者の後をつけてとった写真です。
歩き回っている後ろについてまわって写真をとりました。
写真をとった後で、そのシーンでどう思ったのかというのをコメントとして追加しています。
こういう手法をとることで、どのような体験をしているのかがわかります。
こうすることで、企業がお客様の経験を理解するための手助けになると思います。

人型のボードに、人の特徴をポストイットで貼っていったものです。
ですから、沢山分析をしていくことで、人型のボードが沢山うまれていきます。
最終的に、人型の紙に囲まれる状況になります。



クライアントがセオリーとしてもっているどのように時間を使うのかという図です。
右側は、実際にどのように時間を使ったか?というグラフです。
非常に驚きました。なんどかクライアントの働きぶりを見ると、
実際にはセオリーどうりにはいっていないことがわかります。



想像に関してのメソッドをお話しします。
皆さん、ブレインストーミングはご存知かもしれませんが、
実際に自分たちの考えを反映している写真です。
先ほど紹介したマスクのプロジェクト、それを反映したのがこの写真です。



ですから、ここに貼ってあるポストイットは想像したものではなく、
実際の体験をポストイットで張ったものです。
これがユーザーにとって良い経験をもたらす試作です。
これが試作です。書いたものと、実物とでは違った側面が沢山見えてきます。




実際、手で触ってみると、思い描いたものとは違うことがわかります。
考えたデザインのアイデアを体を使って試すことで、インスピレーションが得られます。
これはお客様が体験する経験をロールプレイでデザイナーが体験する例です。
プロトタイプを作ることは実は簡単です。

ここに見えているのはインターフェースの課題にかんするもの。
9つのプロトタイプが、一つの課題に対して提示されています。


紙で作ったプロトタイプの写真....

これは、美術館での新しい体験のプロトタイプです。
美術館では何かを建設することはできません。
そのかわりに壁にプロジェクタで投影することができます。
そして、あたかも新しいテクノロジーとインタラクションしているかのように振る舞うことができます。
現実味を出すために、音を追加していきます。

プロトタイプは、システムの全体像を作ることもできます。
あるコミュニティでどのように食料が運用、運搬されているのかをしめしたプロトタイプです。


■まとめ



お話ししたいのは、スピリット(精神)についてです。
スピリットの一番上にある概念は、人々がどのように物を使っているのか、何を語っているのかです。

ものはどこから生まれるのか?会社の組織?
私たちが働くことで、実際のものを作っていくのです。
そして、なぜ組織が、なぜそのような決定をしたのか、違ったところかわやってきます。

それは、ビジネスの世界ではあまり語られないところからやってきます。
それはアイデンティティや目的、どういった人間なのか、組織がどういったアイデンティティを
持っているかできまります。
組織や人が何を気にかけているのかによります。
こういった目的があるからこそ、企業をこのように組織するのだ!という形になります。

design for experience は会社を開く、体験だけでなく、組織の目的やアイデンティティに
お客様が関わっていけるようにするのです。
その結果創り出されるものは、会社のアイデンティティを具現化したものになっていくのです。
それは、組織にとって珍しく、パワフルなものです。

ようこそフロンティアへ!
広大なので、その先に何があるのか解らない世界へようこそ。
そして、今日ここに来ている皆さんは、フロンティアのリーダーです。

3/08/2014

[&] UX of the Exhibition


(photo by Thomas Hawk)

「展示のUX」
ArtTech LT 安藤幸央 @yukio_andoh

メディアアート系の作品を展示する際の注意事項集
(ここでいうメディアアートは、コンピュータやプロジェクタを活用した狭義な意味でのデジタルアート作品を示します)
設置/設定/トラブル対処/展示/審査

■設置

□あたりまえを疑う(天井高さはあるだろう、電源は近くにあるだろう、音は静かだろうなど)
□何事も試しておく(初期不良を疑う)
□リカバリが難しいものから手をつける
□電源の安定、電源の位置の確認、電源容量、電源の質の確認
□電源やケーブルが抜けないようにねじってロックするタイプのものか、布ガムテープとめ
□電源系のケーブルと信号系のケーブルを束ねて一緒に引き回すとノイズが乗りやすいので、離す。
□複数の機材がある場合、電源を入れる順番に注意(マイク等、インプット側からONして、出力側は最後にON)
□いろいろな機材は、なるべく隠す。技術を見せないと驚きやすく、魔法っぽくなる
□VGAや、USBケーブル、ケーブルの長さがあるからといって延長のしすぎに注意(イーサで延長可の機材あり)
□再起動の時のプロジェクタの自動調整が勝手に働かないように注意
□セットアップ時間が少ない時、余計なものを持っていかない
□バックアップ機材は多すぎず少なすぎず適切なものを最小限に
□予備の物資、予備の機材は替えの効かない、現地で購入できないものを重視する
□ホコリ、換気、排気に注意(特にプロジェクター)
□余裕を持って、実力の数割で充分実現できる範囲で考える
□プロジェクタの場合特に周りの照明や、日光の様子、昼夜の運用に注意しておく
□設営作業時間を予測、撤収時間を予測する(出来れば一度全部ばらして)
□時間のある限りクオリティを追求する

■設定

□電源がエコモードにならないように(PCもプロジェクタも)
□ブートとシャットダウンをスケジューリングして自動で
□スクリーンセーバーを OFF、スリープを OFF
□デスクトップアイコンを整理整頓
□デスクトップ背景を作品/ブランドイメージに合わせる。Windows標準は止める。
□ドックやメニューは極力減らす、見せない
□ゲストアカウントを作り、パスワード無しで自動ログインするよう設定しておく
□マシン起動時に必ずデモアプリが起動するように
□ネットワーク設定が変わらないように
□必要の無いネットワークは切るように (WiFi, Bluetooth)
□音量の調節(リミッター、最大音量/最小音量)、ダミーのミニプラグを刺しておいて音を切る場合もあり。
□ユニバーサルアクセスを切る
□画面を最大限明るくしておく
□GPUが最大能力を発揮するようにしておく(切り替わる機種の場合)
□ファイル検索できないようにしておく
□ブラウザを利用した作品の場合は全画面キオスクモードで起動するように
□ブラウザを使わない作品の場合は、ブラウザを含む、余計なアプリが起動しないように
□OSのアップデートが勝手に走らないように設定で止めておく
□コンテンツやデータ、設定値は差し替えられるように
□ツールやプログラムは現場で再利用できるように
□何かあった時にビルドし直せるように開発環境を現場に持ち込むように
□設営中のメイキング映像を残すよう心がける(意識的に残さないと設営に必死で、何も残らない)

■トラブル対策

□直前に OS やアプリ、ツール、ドライバ、ファームウェアをアップデートしないように
□正常に動いていた時のバージョンのファームウェア、ドライバに戻せるように
□全てを疑う、どこまで動いているのか、どこが動いていないのか見定める、闇雲に予想で対処しない。
□過酷な現場ではいつも使えているケーブルが切れていることもある。切れたものは間違って使わないようすぐ捨てる
□リモートでメンテナンス、起動等ができるように設定しておく(Wake up LAN の設定も便利)。
□ログを見て、正常運用を日々確認する
□展示内容によっては、食品アレルギー、ペースメーカー注意の掲示など安全面への配慮も
□設置の手間や物の数、移動の手間を減らすよう考える(一般的なものであれば、現地調達も)
□まずは1日動き続けるのに立ち会う、観客の様子、予想外の使われ方を観察する
□メンテのしやすさ、不具合時の交換のしやすさも配慮しておく
□壊れる可能性のあるものは、正常時の2倍から、3倍の代替品を用意しておく
□リモート監視、リモート操作できるよう設定しておくと安心
□電源再投入で全ての設定やアプリが起動し、環境復活するように。必ず一回再起動して確かめる。
□監視用webcam があると便利
□何か足りないものを買い出しに行けるように近くのホームセンター、家電量販店をチェックしておく
□お金で解決できることは、誰かに頼った方が良いこともあり(運搬、造作、廃棄物処理など)

■展示

□1回の展示やライブ、1000人に体験してもらう展示は大きく異なることを認識
□学芸員がいる、いない、説明してくれる人がいるなど状況を考慮する
□子供が触る、触らないで、展示のわかりやすさ、要求される頑丈さが大きく異なる
□長時間の展示の場合、誰も触っていない時間があることを考慮する(自動再生する機能などを考えておく)
□1人で体験する作品の場合、その体験を観察している人、待っている人が居ることを配慮する
□作品の体験者の身体的特徴が異なることを考えておく。背丈は人それぞれ、顔も違う、目の色も違う、器用さも違う
□どの方向に心を動かさせるかを考えておく(驚き、違和感、楽しさ)
□一回の驚きか、違和感や、社会的問題を提起したり、何度でも楽しいものなのか。
□キーボード、マウスを触らせない。トラックボール、Bluetoothダイアルなどで、自由に操作できる要素を減らす
□説明しないでも解ってもらう工夫をしておく
□音、音量、音楽重要
□隣の展示の音、自分の展示の音量に注意
□香りの展示の場合、嗅覚をリセット方法を用意しておく
□視覚に訴える作品の場合、作品を見る前、見た後に視覚をリセットする方法を用意しておく(白い壁を見るなど)
□ある感覚に訴える作品の場合、作品を見る前、見た後にその感覚をリセットする方法を用意しておく
□予想を越える驚き、センスオブワンダーをもたらすことを考える
□サンフランシスコの科学館が出している展示ガイドブック Exploratorium Cookbook お薦め(入手困難)
□書籍「DISPLAY & SPACE 商品を魅せる展示ディスプレイと空間デザイン」
□書籍「みんなに伝わる! ガイドサイン グラフィックス」


■審査対策

□審査員のバックグランドを調べて、適切なアピールをする
□過去の傾向と今年の傾向を把握する
□社会性、テーマなど、単に「美しい」だけではない、意味を込める
□審査基準を把握する。違反は論外。
□タイトル(名前)重要。覚えやすい。読み方が解りやすい、発音しやすい名前に。
□作品の特徴を一言で伝えられるか?(バイラル効果を生みやすい)
□一人で体験する作品は観察者がいることも配慮する
□観察と、体験のギャップを生むか、逆にその差異を少なく保つか考えておく
□デモビデオ重要(短時間で見られるもの、楽しんでいる人の様子を映したもの、できれば子供)
□審査によっては、実際に現物を見ずに書類審査、ビデオ映像のみで審査する場合もあることも配慮
□専門のカメラマンに作品写真を撮ってもらい、取材写真として使ってもらう。メディアに取り上げてもらいやすくなる。

■追記
□ドラム式の電源ケーブルは、長さに関わらず全部巻きを出しておく、巻いたままだと熱を持つため
□缶コーヒーなどこぼす可能性のある飲み物は機材の近くに置かない。キャップの閉められるペットボトルのみとする
□各種ケーブルを巻く時は、ケーブルに負担がかからないよう、八の字巻きで
□ケーブルや配線は、見えないよう隠せるのがベストだが、隠せない時も極力目立たないように
□3ピンの100Vコネクタの場合、受け口が3ピンか確かめておく。合わなければ変換コネクタ用意
□プロジェクタのランプ寿命は 2000時間から3500時間くらい。設定画面で動作時間を確かめて必要ならランプ交換
□複数のPC, 複数の画面を扱うときは、どのPCのどの画面が映っているのか解りやすいようにデスクトップに数字を書く
□音系でノイズが載る時は、電源の極を逆にしてみる、アースをとってみる
□音系でノイズが載る時は、何がノイズの発生源なのか、周りの電化製品等ひとつひとつ電源を切ってみる
□WiFi接続を過信しない。可能であれば、有線でネットワークを組んだ方が良い場合もあり
□フライヤーや名刺/カードなど、気に入った人が何か持って帰れるものを用意しておくと可能性が広がる
□搬出口、搬入口、搬入可能時間、駐車場などを把握しておこう。守衛のおじさんとは仲良くなっておこう。
□バージョン管理は念入りに。最新版をトップディレクトリに置いて、他は常にアーカイブディレクトリに移動しておく
□現場で急に何か直したら、不具合を見つけた人が、直ったかどうかを確認しておく。
□焦って何か直すと、他の箇所に影響を及ぼす場合があり。影響範囲を把握しておく。
□観客が全く入っていない会場と、たくさん観客が居る状況では異なる事柄を把握しておく(音の反響、温度、湿度など)
□短時間でも良いので、事前に現地設置場所を見ておく。どうしても無理な場合は平面図と写真をお願いしておく。

□ネットワークを活用するシステムの場合、firewall の設定を充分に確認し、特定アプリの許諾設定をしておくこと
□どんなに一般的な機材でも機材構成が変わるとうまく動かない可能性があるので動作確認を忘れずに。特にUSB周辺機器に注意。
□撤収の後すぐ次の現場がある時には、忘れ物が無いよう、チェックリストを作ること。大丈夫と思っていても忘れます。
□電源が不安定なところは UPS(無停電電源装置)必須。ただし数分しか持たないのと、停止時に警告音が鳴るのに注意。

■安全面
機材の落下、転倒、鋭い部分で手を切る、足がつまづく、背の高い人が頭をぶつける、
熱をもつ、燃え易いものが近くに無いように。火災の際の避難動線を塞がない、
短時間では大丈夫でも長時間だと排気が充分で無いなど、
充分に注意。解らないときは、経験者、資格保持者にチェックしてもらう。

こういうことも準備して注意しておくといいよ!という事柄があれば、是非お知らせください!


"The art challenges technology. Technology inspires the art." —John Lasseter
「アートは技術に挑戦し技術はアートにインスピレーション与える」Pixar ジョン・ラセター

「なんとかなる。それは、やることをちゃんとやっている人のセリフ」ムーミン谷のリトルミー