■schoo で 1/29 に頂いた質問への回答です。
http://schoo.jp/class/346
環境や状況によって必ずしも最適な回答では無いかもしれませんが、
一つの方策として、生かせる部分を活用して頂けると幸いです。
■----------------------------------------------------------
Q.
UXのアウトプットはどのような形なのでしょうか？ エクセルに届けたいユーザー体験をまとめてるのか、プレゼン資料のようにしてまとめるのか？どのようなUXであれば、チームへの共有がしやすいのでしょうか？
A.
大きな企業はプロジェクトでは、UX担当はUX分野に注力しますが、
小さなプロジェクトや小さなチームの場合、UX以外にも、UX以外の事柄を色々と担当することになると思います。
一般的には、ユーザー人物像を想定したペルソナ設定、
サービスを使うポイントポイント（タッチポイントと言います）の体験を全方位で描いたカスタマージャーニーマップ、
などいくつか資料を用意することになります。
場合によっては画面設計やワイヤーフレーム作成までも担当する場合もあるかもしれません。
一番重要なのは、
メンバーやクライアントを含めた関係者全員の意識と目的の共有です。
解りやすく作りやすく、クライアントを含め、
チーム全体の意思を統一できる良い方法は、
アプリを作り始める前に、Apple Store や Google Play Store に掲載される、
宣伝文句や、アプリの紹介文、アプリ紹介のためのスナップショット風のものを
あらかじめ作ってしまうことです。
そうすると、完成イメージや目標がはっきりとします。
ブランドイメージとして、色がはっきりしている場合は、
マテリアルボックスや、コンセプトボックスと呼ばれる、
アプリの雰囲気を集約した現実世界にあるモノを箱に詰め込んだものを作って、
色合いや質感、世界観を共有すると、イメージがぶれなくて良いです。
また、UX担当は何か資料としてアウトプットを出したから終わりということではなく、企画から、実装中、テストや品質管理の段階など、
どの段階でも常にプロジェクトに深く関わり続けているのが理想です。
■----------------------------------------------------------
Q.
ペーパープロトタイプでアイデアが固まるまでは、モックアップ作成はしない方がよいですか？
A.
はい。モックアップの制作はペーパープロトタイピングの後の工程です。
モックはインタラクション、動きを考えながら作ります。
動くモックの場合もあれば、動かないモックでも制作の意味があります。
モックを作っては、やり直し、気づきがあれば、ペーパープロトタイプ作業に又戻ってくるのです。
モックとペーパープロトを見比べて、違いを見つけ、
その差分が良くなってきているのかチェックしつつ、モックアップを作ります。
ペーパープロトタイプでやることやらないこと。
モックでやること、やらないことを明確にしておき、
あまり時間と手間をかけないのが理想です。
モックでは動きは、一連の操作の流れを検証することに注力し、
細かなビジュアルデザインは、モックを元に、後から細かなところを調整していくのが得策です。
■----------------------------------------------------------
Q.
美しいUIにブラッシュアップするために、使いやすさ以外に注意した方がいい点はありますか？
A.
ここでいう「美しい」は、グラフィックデザイン的に美しいということです。
アプリの良さは必ずしも見た目だけではないですが、
第一印象は大事です。さらに美しさを気に入って使ってもらえればうれしいです。
ブラッシュアップの観点としては以下のような点があります。
●色とコントラストとフォントの選択が重要です。
●位置も重要ですが、空き（隙間）がとても重要です。
●色もフォントも種類を使いすぎないことが重要です。迷ったら白黒で確かめる！
●グリッドデザインに則っているか、配置がずれているものがないか？
●にじんでいるもの、ずれているもの、歪んでいるものが無いか？
●画面の中に配置しているものの重心は安定しているか。不安定な配置は無いか？
●色味は実際に画面で試し、調整するのが良いです。
●配色のルール、ブランドカラー、基本色とプラスする色を考える。
●ブランドイメージにあった共用カラーパレットを作り使い回す。
また、あなたが思う「美しい」とは何か？を自問自答してみてください。
美しいと思うアプリがあれば、そのアプリがなぜ美しいのか、
細かく分解して考えると、
良い意味でエッセンスを真似することができます。
実際のアプリで美しいものを分析する他に、
Dribble や Pinterest で似たものを探して、その似たものとの差分を見つけるのも良い手です。
完成に近づいている段階では、パソコン上で画面のスナップショットを2倍、4倍のサイズに拡大して見て粗を探したり、
逆に 1/2 に縮小して見て印象が弱まらないか、確かめるのも良い手です。
■----------------------------------------------------------
Q.
仕事として取り組んだ経験がない初心者、いちから始めたいと思っている人は何からすれば良いかアドバイスをください。
A.
よく使うアプリの画面を真似してスケッチするのが効果的です。
画面を見ながらペーパープロトタイピングするつもりで描いてみるのが良いです。
始めのうちは無駄なことしているように思えるかもしれませんが、
ある程度数をこなすと、何も見なくてもスラスラと描けるようになるでしょう。
気に入ったアプリ、新しくリリースされて話題になったアプリなどの、
画面の移り変わりを全部書き出してみるのも良いでしょう。
iOS ユーザーインタフェースガイドラインや、
Android Design ガイドラインを熟読し、
UIとしてどんな部品があるのか、把握し、調べてみる、
それらの部品が使われているアプリを探して、どのような場面でどのように使われているのかを調べる。
主要なアプリがバージョンが出たら、どこが変わったか違いを調べ、どこを改善したのかを把握する。
いいアプリ、良いデザインを感じたら、そこで終わらずに、
なぜいいのか、どの部品が良いのか、どの要素が良いのか、細かな要素に分解して考えてみるのが良いです。
■----------------------------------------------------------
Q.
特に自分ではプログラムを書けないのですが、トランジションをうまく開発側に伝えるにはどのような手法があるのでしょうか？ペーパープロトタイプが有効になるのでしょうか？
A.
よくあるタイプの動き（トランジション）であれば、
例となるアプリを見つけておいて示すのが良いです。
これ風な動きで、これより速い、これより遅いとか。
擬態語擬音語を駆使する。
言葉の定義を合わせる「シュっと」とは？
「びよーん」とは、言葉の定義を正確に共有します。
例えば「シュッと」は最初素早く動き始め、そのままスピードを保ったまま目的の位置に移動するなd.
動き始めから、動き終わりまでのスピードの遅い速いをグラフで示すと正確です。
予算や時間が潤沢にある時は、
いくつか単機能の動きの部分だけを確認するサンプルを作ってもらって、
パラメータを調整できるような仕組みで追い込むと良いです。
参考となるサイトとして、
下記のサイトにあるサンプルで動きを確認するのもおすすめです。
http://www.ui-transitions.com/
これら、さまざまな動きは、ディズニーの10のアニメーションの法則に沿っており、
書籍「モバイルフロンティア」のアニメーションの 10パターンで詳しく紹介されています。
■----------------------------------------------------------
Q.
僕はpg（プログラマ）なんですが、uxデザイナと作成物がずれることがよくあります。
特に動作部分なのですが、そういった部分の共有にはどういった部分を意識するとよいですか？
A.
一口にUXデザイナといっても色々あって、ユーザー体験を考えるUXデザイナーと、
動きや動作、操作を考えるインタラクションデザイナー、
ボタンや部品の色を調整したり、作ったりするビジュアルデザイナーの仕事があり、
一人のデザイナーが全部をかねている場合もあります。
制作物がずれない方法の一つとしては、
画面表現をピクセル単位で指定してもらう、指定するのが一つの方法です。
その際、目的のデバイスで最適な画面解像度を考え、2の倍数、4の倍数単位での
ピクセルを考えた方が良い場合もあります。
実装の都合で、想定どうりの見栄えが難しい場合は、単に「出来ない」ではなく、
理由や効率も含めて相談しましょう。
構造が複雑になって遅くなるからとか、機種ごとに見栄えが変わってしまうとか、
描画スピードが遅くなるとか、アプリのファイルサイズが大きくなってしまうとか。
（実際に触ってみて、指で隠れるところに気づいたので、修正しようとかも）
それらの理由を含めた上で、最適な調整をしていきましょう。
始めのうちは対立したり納得してもらえないことがあるかもしれませんが、
経験を積むうちに双方とも、何が最適解なのか肌感覚で解るようになってきます。
それぞれの部品が、どういうパラメータがあって、どういう調整ができるのか解ってもらうと良いです。
また、ビジュアルデザインを担当する人に、出来るだけ使いやすい形で
デザイン部品のファイルを用意してもらえるよう、あらかじめ調整しておきましょう。
ファイル名の付け方一つでも、双方の効率が大きく違います。
いろいろ工夫して作業を進めても、
どうしてもズレる部分はでてきます。
ですから、修正して意識合わせする時間を作るのも大切です。
その際、譲れるところと、譲れないところ、優先順位をはっきりしたうえで
全部かなえる、全部を理想形にするよりも、素早いスピードで優先順位の高いものに対応するのが効果的です。
■----------------------------------------------------------
Q.
ユーザは、現在のデザインに慣れていると思われますが、斬新的なデザインは、どのように作れますか
A.
一つの方法として、一般的なユーザーを想定するのではなく、
エクストリームユーザーを設定する方法があります。
エクストリームユーザーとは極端な使い方をするユーザーのことです。
例えば、一日中そのアプリを使い続ける人とか、
○○のプロの人がこのアプリを使ったらとか、
全く初心者の人がこのアプリを使ったらとかを想定します。
また、デザイン会議と、実装会議をわけるのも良い方法です。
実際に作ること、いまあるライブラリやAPI、今ある技術を知っていればいるほど、
その範疇で簡単にできること、
実現できることしか考えなくなってしまう場合があります。
アイデアはアイデアとして、実現性はいったん無視して、発想を膨らませ、
その中で良かったアイデアを実現する方法を工夫したり、無理してやりくりしたりするのが良いです。
他分野の人、その分野の専門家を連れてくるのも良い手です。
また Pinterest で、UI デザインではなく、その分野のデザインを見るのも発想を広げるのに良い方法です。
例えばスポーツ系のアプリを作ろうとしているのであれば、
スポーツ系のアプリを調べるだけではなく、
スポーツしている画像、スポーツグッズなどをたくさん見てみるのです。
一方、斬新だからといって必ずしも良いものでは無い場合もあります。
斬新さと、慣れとが両立するのが大事です。
斬新なものは受け入れるのに時間がかかるので、
その受け入れの時間が許せるくらいのものなのか、
最初は受け入れにくくとも、慣れた後は楽に素早く使えるものなのかを考えましょう。
斬新と考えた他のアプリが会った場合、斬新と感じる根本的な要素は何かを自分自身で分析してみましょう。
XY軸を書いて、ごく普通の事柄である中心からどちらかに大幅に振ることを考えましょう。
最初の印象が強烈とか、ものすごくゆったりと動くとか、どこか一点、今までに無いものを取り入れるといったことです。
■----------------------------------------------------------
Q.
ハンマーをもったらすべてが釘にみえるではないですが、
WEBの開発リテラシーやツールはとても研究・優秀で、他分野でも応用がきくのではないかなと。
いかがですか？何か事例などご存知であれば知りたいです。
A.
Web開発のリテラシーやツールが他分野で応用されている例としては、
シビックハックと呼ばれる、公共事業などをITの手法やツールでより良いものにしていこうという動きがあります。
アブラハム・マズローの名言、
"金槌しか持っていないときは、すべての問題が釘のように見える。"
"If all you have is a hammer, everything looks like a nail." by Abraham Harold Maslow
この言葉の真意は、常に自分の知らないもっと良い手段があるのでないかと考えるということです。
そもそも Web や、モバイルの分野は歴史も浅いので、他の分野から学べることが多いと感じています。
雑誌作りの際は、全てのページを壁に貼り出して印象や全体の流れを検証しますが、
モバイルデザインの分野でも同じような方法が効果的に使えると考えています。
そう考えると、他の分野の手法を習うのも大変おすすめです。
グラフィックデザイン、タイポグラフィーの分野など、
現在のタイプグラフィーもデジタル対応し始めていますが、本来は活版印刷でにじむことを前提にデザインされた文字です。
過去に学びつつ、現在に適した形で新しい解釈が必要です。
禅の精神とか立ち振る舞い、経営学、建築のマネジメント手法など、少し違うと思われる分野でも学べる部分は多いでしょう。
■----------------------------------------------------------
Q.
UI設計の際に、遷移画面数が少ない方が良いと聞くのですが、 何画面位に抑えて設計をすると良いでしょうか。
A.
画面数がすくないにこしたことは無いのですが、必要な画面を省いてまで1画面に詰め込むのは良くありません。
画面数という、数の多さだけではなく、
その画面をパッと見渡して、全体が解るか、
自分が今どの位置に居るのか解るか、前の作業に戻れるか、先に進めるか？
何かを覚えておかなければ使えないのは辛いが、覚えておかなくて良いか？
といった観点で、考えます。
まあ、結局のところ画面数が多すぎる場合、上記の要件も複雑で使いにくなっている事象が多いでしょう。
また、メニューの構造によっても、画面数が多くても許せる場合と、
画面遷移が深すぎて解らなくなる場合もあるでしょう。
また、画面数はすくなくても、階層ではなく、縦スクロールで多くの情報を埋め込む場合も考えられます。
複雑さを検証する方法としては、
画面の数よりも、操作数を数えると良い場合があります。
手の操作の回数を細かく分解して考える。
画面数の少なさを気にしすぎて1画面に要素を押し込むよりも、
1画面の要素をすくなくすることを検討しましょう。
Android アプリありがちな、全てメニューの奥に操作が押し込まれているのも個人的には好みではありません。
肌感覚で言うと、ある目的を達成するまでに画面遷移が 4画面を越えたら危険信号、
何か明確な理由が無い限り見直した方が良いかもしれません。
（アプリ全部の画面数が 4ということではありません）
■----------------------------------------------------------
Q.
アプリを初めて作るさいに気をつける事は何かありますか？
A.
酷なようですが、初めてのアプリは大抵なにかしら失敗します。
今では人気のアプリ Path の CEO Dave Morin 氏も、そう言っています。
Path も今でこそ人気ですが、初期バージョンの UI はひどいものでした。
Path CEOが断言 - Mobileアプリの初期バージョンは必ず失敗する その理由
http://blog.btrax.com/jp/2012/07/11/path-ceo/
初めて作るアプリが仕事で、納期もタイトで、複雑なものに挑戦するよりも、
個人プロジェクト、社内プロジェクトなどで、いくつか締め切りの無い環境で、
簡単なアプリを作ってノウハウを蓄え、あらかじめ失敗を沢山しておくのが良いでしょう。
少しでも、失敗を避けるために気をつけることとしては、
世の中にすでにリリースされている人気アプリ、
沢山のアプリを見る、実際に使う。
最初のアプリを作った後に、直すこと、
改良することに時間と予算を用意しておくこと。
どんなに完璧だ！と思っても、何かしら直すところがあるハズです。
Webサイトの構築の場合、完成したら、残りのテスト工程はわずかだと思いますが、
モバイルアプリ（サイト）の場合は、出来上がった！と思って、やっと道半ばです。
そこからのテスト、不具合修正や、改良にとても時間がかかることをあらかじめ予定しておきましょう。
■----------------------------------------------------------
Q.
facebookのスライドメニューなどの革新的なUIはいかにして生まれると考えますか！？
A.
ごく稀に天才が突然革新的なUIを生み出すことはありますが、
大抵の場合は、模倣と、改良の中から生まれるものがほとんどです。
情報の構造をUIとは関係ないところで整理し、現実世界の何かを模倣したり、
今ある他の UI を改良したしするものです。
Facebook のメニューも、始めはボタンの集合でした。
スライドメニューを実装したのも、Facebook アプリが最初というわけではなく、
Facebook 以前にスライドメニューを効果的に使っていた Android アプリもありました。
How Facebook Mobile Was Designed to Write Once, Run Everywhere
http://readwrite.com/2011/09/29/how-facebook-mobile-was-design#awesm=~ovDITi2alhbNRo
今は死に体になっていますが、
Webデザインで、Flash の時代に、革新的なものがいっぱいありました。
それらを見直して、再び活かすのも一つの手でしょう。
現在の UI で革新的なもの、エポックメイキング的なものがまとめられたサイトが参考になります。
http://www.uxarchive.com/
Twitter のタイムラインを引っ張って下げたら更新する仕組みも革新的で、
Apple が標準メールアプリに取り入れたり、APIで準備されたり、特許取得されたりと話題になりました。
この引っ張って更新の仕組みも、突然思いついたものではなく、
最初はごくごく普通のありがちな機能で、それが様々な開発者によって進化し、
突然変異し、品種改良され、今に至ってます。
遺伝のようなプロセスで、いまの UI が生まれたのだと語られています。
インタビュー記事：5 Minutes on The Verge: Loren Brichter
http://www.theverge.com/2012/3/23/2893884/loren-brichter-interview-5-minutes-on-the-verge
■----------------------------------------------------------
Q.
画面遷移ではなく、インタラクションを試作するためにいい方法はありますか？
A.
いくつかのインタラクション作成用のツールがあり、便利に使えますが、どれも完璧ではありません。
時間や予算に余裕がある場合は、
プログラマと相談しながら実際に部品やアプリの断片を作ってしまう方法もあります。
UI部品のサンプルコードをビルドしてもらって、その UI 部品だけのアプリを見ながらインタラクションを調整していく手です。
ツールとしては、以下のようなものがあります。
Framer.js
http://www.framerjs.com/
Facebook origami
http://facebook.github.io/origami/
AfterEffects または Flash ←得意な人が居る場合は良いですが、結局二度手間になってしまいます。
Objective-C(iOS) または Java(Android) ←実際にアプリを作ってしまうということです。
Objective-C や Java で実際にアプリの断片を作って試す場合に気をつけなければいけないのは、
その断片のコードを再利用して完成版のアプリを作ることはせず、
検討用のアプリのコードは一端捨てる覚悟で、完成版のアプリ用には新たにコードを書き始めるのが良いです。
■---------------------------------------------------------
Q.
モバイルが登場したことにより、UXにはどのような変化があったのでしょうか？
モバイルUXが他のUXと一番異なることはなんですか？
A.
いろいろありますが、一つ大きなことは、始まりもなく、終わりもない、
何か目的を達成するだけではない体験が主流になったことです。
細かく言うと、以下の 10項目です。
●モバイルならではの体験が重視されるようになった。移動しながらとか。
●素早く使って、素早く表示されないと使われない
●画像や文字で表現する情報量が1画面の中では限界があるので、少ない。
●シンプルな操作
●大きくて触れるボタン
●テキスト入力は面倒。テキストメッセージングが主流だとしても。
●簡単にやりたいことが見つからないといけない
●縦スクロールか、横スクロール、どちらか一方
●自動で色々できたり、操作や入力が少なくてすむ
●シンプルが全て。操作も体験も全てシンプル。
■----------------------------------------------------------
Q.
ユーザーからのフィードバックを反映させるためのコツはありますか？
A.
ユーザーからの要望やフィードバックを、全部鵜呑みにしないことです。
要望を検討し、要望そのものに優先順位をつけ、
改良は改修のための手間を考えた上で、さらに優先順位を考えます。
そうやって各項目の対応に優先度を付けるます。
作業が簡単なもの、重要度が低いものは、要作業リストに積み重ねておいて、時間のある時に一気に直します。
作業が大変だけど、優先度が高いもの。最優先にします。
ユーザーのフィードバックに、直接的な答えが無い場合もあります。
その背景には何があるのか。
単に慣れていないだけなのか、開発者が気づかなかった指摘なのか、
不具合やバグなのかを考える必要があります。
まずは開発者自身、デザイナー自身が、そのアプリの最大の利用者でなければいけません。
普段から使い込んでいれば、おのずと不具合や、不便さが浮かび上がってくることでしょう。
■----------------------------------------------------------
Q.
プトロタイプ作成の時には技術的な難易度はあまり気にせずにアイデア優先で作っていますか？
A.
アイデア優先で考えます。
アイデア会議と、実装会議を分けるのが良い方法です。
実装のことを考えてしまいすぎると、アイデアに広がりが無くなってきます。
だからといって実装を無視することもできません。
実装に時間がかかるか？ 優先度が高いか？ コアバリューか？
代わりの案をいくつかだして、それと差し替え可能か？ この機能が無いと豊かな体験が失せるか？
最初に実装せず、後から実装しても受け入れられるか？難しいか？ といった観点から考えます。
技術的容易さ、難易度で、アイデアにリミッターがかかってしまうのは良くありません。
けれど、実現不可能なアイデアはいつまでたっても実現しません。
実現に費用と人的リソースがかかりすぎることも実現しません。
技術を知った上で、限界を責める姿勢が大切で、
そのためにはアイデア会議と、実装会議を別に分けるのが良い方法です。
アイデア会議では、実装のことを考えずに斬新なアイデアも受け入れ、アイデアを広げ、
実装会議では、どだい無理なのか？アイデアをどう実現するのか、工夫を凝らします。
また夢物語のような、とっぴょうしもないアイデアも、
ハードウェアや、コンピュータリソースで 100% とまでは言わないまでも
実現可能な事柄も工夫次第ではありうるでしょう。
■----------------------------------------------------------
Q.
ペーパープロトタイプの段階でのジェスチャーはどのように表現していますか？また、ジェスチャーは積極的に採用していますか？
A.
ペーパープロトタイピングの段階では、ジェスチャーは表現しきれないので、
既存のジェスチャーに何があるか、書き出しておいて、それをあてはめるのが良いです。
紙に書いたものを、「スワイプする」とか書いておいて、想像してもらうのです。
ジェスチャー一覧（スワイプなどの操作が絵で書かれたもの）を壁にはっておいて、
一緒に見ながら考えると良いです。
■----------------------------------------------------------
Q.
スマホアプリよりもスマホサイトの方が良い場合はどういう場合でしょうか？
A.
スマホアプリ、スマホサイトを比べる場合、ネイティブアプリ vs. モバイルWeb と言われる場合もあります。
多くの場合、素早く動作するスマホアプリが理想型ですが、
モバイルWebの方が向いている場合もあります。
モバイルWebが向いているのは、
改変が頻繁になされるときや、多くの機種で使われる時、
社内利用など想定ユーザーが決まって場合などです。
また、社内のみで使うものは、ユーザー層が想定済みで、何かあれば説明することができ、
ユーザー獲得や、ユーザーを拡大させる必要が無く、使ってもらえるものだからです。
ただし、人件費はコストに跳ね返りますから、あまりにも使いづらいアプリになってしまうと、
そこで目に見えない膨大なコストが失われているかもしれません。
またネイティブアプリと、モバイルWebのいいとこ取りのハイブリッドアプリという形式もあります。
画面表記はHTMLで行うWebコンポーネントを使ったネイティブアプリで、
ハイブリッドアプリと呼ばれますが、長所も短所も 2倍になるかもしれません。
ネイティブアプリで作るか、モバイルWebで作るかで、
いくつかの観点があります。
●UIにどれだけ凝る？完全オリジナルのUIか標準もしくは標準の延長線にあるUIか。
●アプリの動作スピードをどれほど重要視するか
●一般向けのアプリか、特定ユーザー（例えば社内利用のみなど）向けか？
●開発者のスキルや、人員の確保（バージョンアップも含め）。開発費用に直接影響。
●出来ること、できないことで判断する。カメラ機能や、動画再生、各種センサーなど
●ネット接続が最重要なサービスか？オフラインでも使えなければいけないのか？
●どれぐらいの種類のデバイスに対応しなければいけないのか？
●今後出てくる新機種にどのくらい対応しなければいけないのか？
●マネタイズの方法をどうするか？有料アプリとして販売するのか広告収入なのか？
●アプリストアに出さない場合は、ユーザーの流入を別途考えなければいけない。
●アプリの配布方法、アプリを広める方法はどうするか？
●リリース後のバージョンアップ、メンテナンス対応をどう進めるのか？
●頻繁なアップデートを予定しているのか？
●サーバーのアクセス負荷、求められるレスポンスに充分対応できるか？
●コンテンツや中身や機能の更新頻度に対応できるか？
以上の条件から、どうしても譲れない部分があれば、それを理由に選択し、
どちらでも良い場合は点数を付けて合計でどちらが良いか検討すると良いでしょう。
費用があるなら、ネイティブアプリも、モバイルWebサイトも両方やる。
資金がすくないベンチャーや個人がスピード感をもってサービスをローンチしなければいけないならアプリから。
社内利用や、長期的に超多機種対応しなければいけない場合はモバイルWebを検討するのが得策でしょう。
■----------------------------------------------------------
Q.
アプリUIを確定させるため、プロトタイプにかける時間はどのくらいですか？ 例えば、1時間ほどのMTGを3回程度はやるとか。先生の経験上、どれくらいの時間をかけているのか教えていただきたいです。
A.
集中力が続かないので、30分〜60分くらいが適切だと思います。
これは、チームのスタイルに合わせると良いでしょう。
30分雰囲気の張りつめたミーティングの後に、雑談する時間を設けると
意外なアイデアに広がる場合もあります。
また、短い時間でも良いので、日をまたいで何回もやるがおすすめです。
ずっと考えていて、リラックスした時に、アイデアや、課題の解決策がひらめくことが多いからです。
その際は、打ち合わせの途中で止めるのがコツの場合もあります。次に再開しやすいからです。
エンジニアはきちっと何事も決まらないと、満足しないことが多いですが、エンジンがかかりやすい状態に保つのも良い方法です。
途中で止めたとしても、ミーティングで決まったこと、決まらないこと、課題をタスクに積んでおくのは重要です。
一方、他にいろいろ忙しくて、後回しになってしまう、集中できない時などは、
メンバーを集めて、他の事を遮断して、
半日または1日まるまる考えることだけに時間を使って、集中して考えるのも良い方法です。
ミーティングの際には、まっさらな状態ではなく、
事前にいくらか考えてくる。極端な例だと、100本案を出すなど、脳に負担をかけるのも一つの方法です。
リラックスだけでなく、脳に負担をかけた中から斬新なものが生まれる場合もあります。
■----------------------------------------------------------
Q.
スワイプやフリックをどのように活用すべきか、考え方はあるのでしょうか？
A.
スワイプやフリックは、
コンテンツを直接操作するものに向いています。
触る前にそうすべきと解っているかが重要です。
子供、高齢者が対処となる場合は、スワイプやフリックは慣れてもらえない場合もあるので、
良く考えて利用する必要があります。
その際や、スワイプでしか出来ないとせず、他の方法でも操作できると良い場合もありますが、
一概には言えません。
気をつけるのは、左右の操作なのか、上下の操作なのか、混乱しないように、
画面のどのくらいの距離を触れば良いのか、実際に触ってみて考えることです。
■----------------------------------------------------------
Q.
プロトタイプで作る上で"作り過ぎない"為に特に心掛けていることはどのようなことでしょうか？
A.
動きに関しては、どんなにじっくりと考えても検討しきれないので、
動きの検討は後回しにし、作りすぎないようにします。
また、色や、必要の無い部品、設定画面なども、そのアプリの主要機能で無いかぎり、後回しにします。
一方、案が出し切れてないと感じるときは、作り過ぎと思われても良いぐらい、作ります。
■----------------------------------------------------------
Q.
今から作成の勉強をしたのですが、参考になる本はありますか？
A.
手前味噌ですが、書籍「モバイルフロンティア」の6章がおすすめです。
書籍「ペーパープロトタイピング」もおすすめですが、
モバイル向けの本ではないので、自分で読み替えて活用する必要があります。
■----------------------------------------------------------
Q.
プロトタイピングは、何名で行うほうがいいのでしょうか？あまり人数が多くないほうがいいですか？
A.
多くの違うタイプの人が集まることで、アイデアが広がったり、思いもしなかったひらめきがやってくる場合もありますが、
一人でじっくり考えてプロトタイピングするのも重要な時間です。
複数人数の場合は、3人、5人、など奇数の方が意見が二つに割れず調停役が現れるので良い気がしています。
とはいっても、7人くらいが限界で、それより多くなると、参加せずに傍観者になる人が現れます。
人数が多い場合は、少人数のグループに分けて、グループ内で作業し、途中でメンバーを交換するなどの
方法が良いでしょう。
複数人数で作業する場合は、ブレインストーミングと同じで、否定せずに、いろいろな可能性を探りましょう。
また、だまったままで発言しない人を作らない、またはその反対で、しゃべりすぎる人を作らないのも重要です。
人の発言を遮らないで、順番に発言する方法として、
ぬいぐるみとか、缶とか置いて、それを持っている時だけ話していいというルールを作ると良いです。
■----------------------------------------------------------
Q.
先生は、画面遷移の組合せを、どういう方法（視点）で決めていますか？
A.
画面の遷移ではなくて、情報の提示の遷移として考えています。
情報の抽象度が上がったり下がったりした時に、画面が移り変わるように。
情報の一塊が変わった時に画面が移り変わるとか、
画面が移り変わると、どんなに素早かったとしても意識が分断します。
その前後の情報が少し記憶から離れ、連続性が薄れます。
前の画面は忘れて見えなくなり、全部は覚えていられません。
画面と画面を分断する線引きをどこに置くのか？置かないのか？
記憶が続けられるか、1画面ではなく2画面に分けた方が良いのか良く無いのかで考えます。
場合によっては、設定画面のように、1ページの縦スクロールにする手もあるので、
臨機応変の対応が必要だと思います。
■----------------------------------------------------------
以上です。ここに載っていない質問は第一回目の中で口頭で回答しています。
