ジェネシックスにおける「UX」とは
Posted on | 6月 8, 2011 | No Comments
UX＝ユーザーのゴール体験
ジェネシックスが変えていこうとしているUX、ユーザーの体験とは何か。
一言で言うなら、それは「ユーザーのゴール体験」です。
今回は、このUXとユーザビリティと世界観という三つの概念について書きます。
ユーザビリティとUX
ユーザーは意識・無意識に関わらず、行動のモチベーションであるゴールを持っています。
そのゴールによっては、ユーザビリティですら飾りに過ぎなくなる場合もあります。
むしろ使いにくことがユーザーを満足させることすらあるでしょう。
例えば、Twitterのダイレクトメッセージ機能に対するユーザーのゴールの一つは、「安全にクローズドメッセージを送受信すること」です。
Twitterの他の機能がオープンですから、そこから相対的に導きだされるゴールということになります。
ダイレクトメッセージは、間違って普通のオープンなツイートになることは許されず、間違った相手に送ることも許されません。機能の前提として”何があってもそれだけは許されない”のです。
この発見から、ジェネシックスのiOS向けTwitterクライアントでは、DMを専用タブでモードとして切り出し、ユーザーリストから選択して送信する形式にしています。このモード上で使用する限り、間違いオープン送信は起きません。ユーザーは「D」の後に半角スペースがちゃんと入っているか確認しなくても安心してDMを利用できます。
DMは実際は通常のTweet入力画面からも送信できます。簡便さから言うとこちらの方が使いやすいでしょう。
しかし、「D 」を編集できるようにしておくと、偶然スペースを消してしまった・・・ということも起き得ます。
このように、敢えて不可能にする＝使いにくくすることによってユーザーのゴールを実現させるのも、UXからのデザインです。
世界観としてのUX
人間は事物を個々の構成要素の集合体ではなく、一個の全体として認識する性質があると言われています。
アプリの機能それぞれをユーザーのゴールに沿わせていくことも重要ですが、それよりも重要なのはアプリ全体としての世界観です。
これは、ユーザーのゴールと表裏一体となった概念で、言い換えると「ゴールの達成方法を表現したもの」と言えます。
ユーザーのエモーショナルなゴール、ファンクショナルなゴール、さらにその先にある自己実現のゴールの理解。それらを達成するための提案としての世界観。これを提示できないつくり手は、今後ユーザーにとって無用の存在になっていくでしょう。
#Appleの製品やプレゼンテーションがまさに世界観の提案の好例です。
アプリケーション定義ステートメントによる共有
iOS Human Interface Guidelines(HIG)の「アプリケーション定義ステートメント」はこの世界観を表すのに適したもので、”アプリケーション定義ステートメントは、アプリケーションの主要な目的とその対象を、簡潔かつ具体的に宣言したものです。”と定義されています。
ジェネシックスでは、ユーザーのゴールの仮説を立てた後、その達成方法の提案として、アプリケーション定義ステートメントを作成/共有しています。
世界観から先に発見されることもありますが、その際もユーザーのゴールを逆行して見つける作業が必要になります。
これは、送り手の自分勝手な妄想を防ぎ、恣意的な判断やコミュニケーションの行き違いによって最終的な成果物がブレることを防ぐためです。
ジェネシックスにおける「UX」
ジェネシックスのデザインセンターでは、UXに対して責任を持つのはデザイナーであり、プロジェクトメンバーの代表として「UXデザイン」をしています。
また、その他の職種のメンバーもUXの重要さを認識し、それぞれの立場で提案を出し合い、更なる高みを目指しています。
具体的なUXデザインの手法については、次回書きたいと思っています。
2011年6月8日現在、ジェネシックスではUXデザイナーを募集しています。「UXデザイナー」と言ってもスマートフォンのアプリを作ることが前提ですが、この記事のような職場こそ自分が望んでいたものだと感じられたらご連絡ください。
ジェネシックスのUXデザイナーとは
Posted on | 5月 31, 2011 | No Comments
「UXデザイナー」というのはどんな役割を持った人間を指すのでしょうか？
僕にも一般的な定義ははっきりしていませんので、弊社ジェネシックスでの状況を書きます。
ジェネシックスのデザイン体制
ジェネシックスのデザインセンターのデザイナーは2種類の肩書きを持っています。
それは、
- 「UXデザイナー」
- 「UIデザイナー」
です。
UXデザイナーは、Goal Directed Designに基づいてユーザーのゴール体験の実現する方法を設計し、UIデザイナーはそれを具現化します。
また、
- 全てのプロジェクトにUXデザインが必要。
- UIデザイナーが独力でUXをデザインすることはできない。
という規定を設けているので、UIデザイナー単独でプロジェクトにアサインされることはありません。
「UX」は必要？
この「UXデザイナー」（「UXデザイン」）という呼称については、本当に必要なものなのか。という話を@memocameraとしたことがあります。
確かに僕の名刺上の肩書きは「チーフUXデザイナー」ですし、UXデザインについて日々話しています。
ですが、UXデザインの定義を説明すればするほど、単に「デザイナー」で済むものを、わざわざ「UXデザイナー」としているのでは無いかという話になったのです。
デザインの歴史を振り返ってみると、グラフィック/プロダクト/ファッションなど、デザイナーは媒体を通して媒体それ自体のみではなく、それがもたらす体験をつくってきました。
そこを改めて「UX」と言う必要があるのか。という事です。
そこに対する僕の答えは、本質的には「デザイナー」が正しいというものでした。
そうなんだけれど、現実として、「デザイナー」という言葉は「見た目を作る人」というイメージがあまりにも強すぎるので敢えて「UXデザイナー」にして、「UX？」という疑問を生み出す装置にしたい。と説明しました。
こういった言葉の定義は疑問があればとことん議論するべきです。その末のコンセンサスが言葉に力を持たせるからです。特にこういった新しい概念を組織に取り入れるには、定義をしっかりと共有するべきです。
ジェネシックスにおけるUXデザイナーの役割
ジェネシックスにおいて、「UXデザイナー」とは、
「ユーザーのゴールを理解し、その実現方法を「振る舞い」「形態」「コンテンツ」で提案し続け、それらをチーム全体に共有しユーザーに還元することで、事業に貢献できる人材」
と考えています。
具体的には、
「企画書とユーザー調査を元にUXデザインを定義し、そこからアプリ全体と各画面の要件を作成してチームに共有、その後はユーザーの代弁者として設計・実施に携わり、ビジネスのゴールと技術的な制約/可能性を理解しつつ、課題があれば解決案を提案する。」
これを独力でやりきる能力を要求されるのが、ジェネシックスの「UXデザイナー」です。
2011年5月31日現在、ジェネシックスではUXデザイナーを募集しています。「UXデザイナー」と言ってもスマートフォンのアプリを作ることが前提ですが、この記事のような職場こそ自分が望んでいたものだと感じられたらご連絡ください。
ジェネシックスのモノづくり哲学
Posted on | 5月 16, 2011 | No Comments
ジェネシックスに初のデザイナーとしてジョインするにあたって、まず僕が作成したのは
「ジェネシックスのモノづくり哲学」
でした。
これは、もちろんデザインの定義を共有する目的がメインですが、ジェネシックスはその当時のメンバー全員がデザインの重要性に対して理解を持った稀有な組織で、その中でデザインを任される責任に対する自分の決意表明でもありました。
今ではその頃の3倍以上のメンバー数になりましたが、デザイナーはもちろん、エンジニアなど、他の職種の方がジョインされた時にも、オリエンの際に共有しています。
さて、いつも回りくどい僕の性分に違わず、この件についてもストレートなものにはなっていません。
まず、「モノづくり哲学」と題しておきながら、次のように謳っているのです。
UXをゴールとしている。ということで、これがジェネシックスでUXデザインが重視され、 UXデザイナーという肩書きが存在する理由になっています。
これは特にデザインの世界では珍しくないものだと思いますが、ジェネシックスでは、組織全体で共有しています。
一見「モノ」の否定しているようですが、それはその先の体験をゴールとしているだけで、
モノ自体のつくり方も下図を元に考え、実践的に使えるツールにしています。
これの使い方ですが、例えば企画はとにかく素晴らしいAwesomeなものとして出発する事が多いと思います。
でも、それは色んな意味で過多な要件になる事が多くなるものです。もちろん最初は発散して良いのですが、そこから要件を削ってSimpleにするという作業が必要になります。
でも、削り過ぎてユーザーにとって必要な機能まで無くなってしまうと、アプリとしての存在意義がなくなります。つまり、ユーザーにとってRealな要件にする必要があります。
さて、こうやってまとまった要件ですが、せっかくSimpleかつRealになってもワクワク感まで失ってはいけないので、Awesomeさがちゃんとあるのか確かめます。
このように、サイクルとして考えたり、三点の間でうまくバランスとったりして、モノのあるべき姿を探って行くのがジェネシックスのモノづくりプロセスの根底にある考え方です。
こういったことをデザイナーが考えるのは普通かも知れませんが、重要なのはそれを組織全体に価値基準として共有し、責任もとっていくことです。
実際にやってみて感じるのは、舵を切る際やコンセンサスを得る際の容易さです。
上に書いた内容を読んで、これはキレイ事や理想であって、現実には難しいと感じられた方がおられたら、一度ジェネシックスの現場を見ていただければ納得していただけるでしょう。
もし「デザイン」の定義や立ち位置でお困りの現場があれば、試してはいかがでしょうか？
#具体的にどうやって作るのかについては、またの機会に書きたいと思います。
※2011年5月16日現在、ジェネシックスではUXデザイナーを募集しています。「UXデザイナー」と言ってもスマートフォンのアプリを作ることが前提ですが、この記事のような職場こそ自分が望んでいたものだと感じられたらご連絡ください。
iOS Human Interface Guidelines Introduction リーディングメモ
Posted on | 3月 27, 2011 | No Comments
ジェネシックスデザインセンターで開始したiOS Human Interface Guidelines読み合わせ会のメモです。後追いでIntroduction分を。
これももちろん翻訳ではなく超訳というか主観訳。今後修正する可能性もあります。
Introduction
→原文：iOS HIG / Introduction
最高のUIとUXをあなたのiOSアプリに。
The Guidelines At a Glance
#イントロダクションはHIG各パートへのリファレンスになっている。
Great iOS Apps Embrace the Platform and HI Design Principles
ユーザーにとって良いアプリを作るためには、iOSデバイスの特徴を理解し、ヒューマンインターフェイスの原則を取り入れる方法を学ぶべき。
参照：Platform Characteristics,Human Interface Principles
Great App Design Begins with Some Clear Definitions
アイディアからアプリを作る場合は、どんな機能を誰に提供するのか正確に決め、それにルックアンドフィールを合わせる。
参照：App Design Strategies,Case Studies: Transitioning to iOS
A Great User Experience Is Rooted in Your Attention to Detail
大小様々どんな時でもデザインのあらゆる面でUXを最優先にし続けること。
参照：User Experience Guidelines,iOS UI Element Usage Guidelines
People Expect to Find iOS Technologies in the Apps They Use
iOSはすごいテクノロジーを提供してて、それはどんどん利用していいんだけど、ガイドラインには従うように。
参照：iOS Technology Usage Guidelines
All Apps Need at Least Some Custom Artwork
iOSのデフォルトUIを使ったアプリであっても、最低限アプリアイコンはApp Storeやホーム画面で見て楽しめるくらいのものにしましょう。
アートワークの量に関わらず、どうやってそれを作ればいいのか知るべき。Retina用のアートワークの制作をより簡単にする方法もある。
参照：Custom Icon and Image Creation Guidelines
>>?iOS Human Interface Guidelines Chapter II : Platform Characteristics リーディングメモへ
iOS Human Interface Guidelines Chapter 1 : Platform Characteristicsリーディングメモ
Posted on | 3月 27, 2011 | No Comments
ジェネシックスデザインセンターで開始したiOS Human Interface Guidelines読み合わせ会のメモ。翻訳ではなく超訳というか主観訳。今後修正する可能性もあります。
ということで、「iPhoneヒューマンインターフェイスガイドライン」のまとめは中止しました。悪しからず。
<<?iOS Human Interface Guidelines Introduction リーディングメモへ
Chapter 1：Platform Characteristics
→原文：iOS HIG / Chapter II : Platform Characteristics
デバイスの特徴を踏まえてデザインしましょう。
The Display Is Regardless of Its Size
ディスプレイは見るものとしてだけでなくインターフェイスとしてもUXの要。
デバイスによってサイズとか違うけど以下は気をつけよう。
タップサイズは44*44を確保。
アートワークは見やすく。
(UIではなく)コンテンツに集中できるように。
iOSデバイスのスクリーンサイズ表
| デバイス | ポートレート | ランドスケープ |
|---|---|---|
| iPhone 4 | 640 x 960ピクセル | 960 x 640ピクセル |
| iPad | 768 x 1024ピクセル | 1024 x 768ピクセル |
| その他のiPhoneやiPod touch | 320 x 480ピクセル | 480 x 320ピクセル |
ポイントとピクセル
ピクセルは画像を制作する際の単位。
ポイントはデバイス上で表示されるサイズ。例えばRetinaだと1ポイントは2ピクセル。
Device Orientation Can Change
ユーザーは色んな理由でオリエンテーションを変えるということを踏まえてデザインしましょう。
アプリがホーム画面と同じオリエンテーションで起動する事が期待される。iPadはホーム画面もオリエンテーションが変わるので注意しましょう。
Apps Respond to Gestures, Not Clicks.
ユーザーはジェスチャーを使って直感的に操作する。それを邪魔しないように標準のジェスチャーを使いましょう。
あと、画面サイズが大きくてもやたらとむやみに複数の指を使うようにはしないこと。
標準ジェスチャーの表
| ジェスチャー | アクション例 |
|---|---|
| タップ | マウスのクリックのように画面上のものを押したり選んだりする。 |
| ドラッグ | 上下左右にスクロールする。 |
| フリック | 素早く上下左右にスクロールする。 |
| スワイプ | table-viewの行で削除ボタンを出す。 |
| ダブルタップ | ズームインしてコンテンツや画像を中央に見せるようにするか、既にズームインしている場合はズームアウトする。 |
| ピンチオープン | ズームイン |
| ピンチクローズ | ズームアウト |
| タッチ アンド ホールド | 編集可能なテキストでカーソル位置の拡大表示。 |
| シェイク | アンドゥやリドゥの開始。 |
People Interact with One App at a Time
iOS4からマルチタスキングが採用され、アプリがフォアグラウンドから消えても落ちないようにできるようになった。バックグラウンドのアプリは、画面の下から出てくるmultitasking UI で見ることができる。
バックグラウンドのアプリは、必要に応じてバックグラウンドに行った時のまま（suspended）であったり、バックグラウンドでも動作し続けたりする。
Preference Are Available in Settings
「設定」アプリを操作するためには一度フォアグラウンドのアプリを閉じる必要があるので、「一度設定したらめったに変更しないタイプ」の設定を置く。ビルトインアプリは使っているけど、ほとんどのアプリはこのタイプの設定が無いので「設定」アプリに設定が無い。
Onscreen User Help is Minimal
モバイルユーザーはアプリ本来の使用目的以外に時間を割きたいとは思っていないので、大量のヘルプは読まない。さらに、ヘルプは貴重な領域を奪う。
iOSデバイスやビルトインアプリは直観的で使いやすいのでヘルプコンテンツを必要としていないし、他のアプリも同じように使いやすい筈だとユーザーは思っている。
An App Has a Single Window
#ここはまだちゃんと訳せていない。
iOSアプリはタイプに関係なくシングルウィンドウで、これはデスクトップアプリのウィンドウと同じだけど、ユーザーはその存在を認識せず、アプリをスクリーンの集合として認識している。
Two Types of Software Run in IOS
iOSで動くソフトウェアは以下。
- iOSアプリ：iOS SDKで作られるネイティブのアプリ。（AppStoreからインストールできるようなもの）
- Webコンテント：iOSデバイスを使ってユーザーが使うwebサイト。3つの種類がある。
- Web Apps：iOSアプリと同じように振舞うように作られたWebページ。
- 最適化ページ：サイズや操作性含め、iOSデバイスのディスプレイ上のSafariに最適化されたWebページ。
- 互換ページ：iOSのSafariでも問題なく表示・操作できるWebページ。
Safari on iOS Provides the Web Interface
iOSのSafariはデスクトップのSafariと似てるけど違うもの。
特に、デスクトップのようにWindowサイズを調節することでviewport(表示領域)を変えることはできない。
オリエンテーションを変えたりズームしたりして変えるだけ。
cookieは使えるけど、FlashとかJavaは使えない。HTML5のaudioやvideoタグ、CSS3はJSを使う。
iOSのSafariでのジェスチャーは主に表示されているコンテンツに対して使われる。ただし、onclickは使えるけどhoverなどは使えないといった特徴がある。
Webクリップアイコンから起動すればフルスクリーンモード(SafariのUI非表示)にできる。
→フルスクリーンにするためのmetaタグ
AndroidのUIガイドライン
Posted on | 1月 24, 2011 | No Comments
Androidのデザインに関して調査中なのですが、
とりあえず公式な「User Interface Guidelines」はあるので、それを和訳しないと・・・と思ってたら、
「3. UI ガイドライン – ソフトウェア技術ドキュメントを勝手に翻訳」というかたちで公開されている方がおられました。感謝！
このドキュメントのボリュームの差が自由度とクオリティコントロールのバランスになってるわけですね・・・
iPhone ヒューマンインターフェイスガイドライン チェックシートを公開しました。
Posted on | 1月 8, 2011 | 2 Comments
先日Twitterでもお知らせしたのですが、
iPhone ヒューマンインターフェイスガイドラインの準拠をチェックするためにジェネシックス社内で使用しているチェックシートを公開しました。
（昨年書いていた、「iPhoneヒューマンインターフェイスガイドライン」のまとめを中断して作成していました。）
※追記：公開していたドキュメントがセキュリティ設定が強化されたようで社外からアクセスできなくなっていました。個人アカウントで公開しなおしましたのでご利用ください。また、内容を最新にしたものも作成中です。
Google Docsでクリエイティブ・コモンズライセンス 表示-非営利-継承 で公開しています。
iPhone ヒューマンインターフェイスガイドライン チェックシート(Google Docs)
非営利となっていますが、お仕事上で利用するのは問題なく、このチェックシートの供与によって対価を得ることを禁じているだけですので、安心してお仕事でお使いいただければと思います。
共有資料ですので、ファイル自体の編集はできませんが、Google Docsの「ファイル」メニューから「形式を選択してダウンロード」をしてご利用ください。
また、問題追跡のシートを初めGoogle Docsでの使用を前提としていますので、ぜひ再度のアップロードをお勧めします。（コピーできればいいんですが・・・）
作成にあたっては、まずHIGを読み通した上で記述を再分類し、できるだけ意味のない重複を避け、システムの制約上意識しなくても実現できるところも省きました。
さらに、弊社のトップiOSアプリエンジニアである@TonnyXuのチェックを経て、公開に至っています。（彼がいなければ完成しませんでした。感謝！）
まだ十分な運用を重ねたとは言えませんが、同じ業界の方のお役に立てば幸いと思い、公開した次第です。
ご意見や不備に関しましては、当記事のコメントか「自己紹介」ページのフォームからお気軽にお寄せください。
ロジックとアウトプット
Posted on | 1月 3, 2011 | No Comments
『警官の血(上)』文庫版 P.297の主人公の安城民雄と友人の宮野の会話で、当時の運動家達の思考回路の一端に触れた気がした。
「そこはともかく、分析が正しいなら、そこから出てくる方針も正しいでしょ」
「武装蜂起の？」
「ええ」
ロジックが正しいならば、それによるアウトプットも正しいという考え方は、デザイナー業界でもよくある話です。
むしろ、形態や振る舞いなどの「正しさ」が絶対的に判断できないようなものをアウトプットとするデザイナーだからこそ、そういったロジカルな正しさに頼ろうとするわけですが、じゃあそういった立派な論理を展開するデザイナーさんの作品に触れた時に、優れたものと感じられるかというと、必ずしもそうでないことが多いように思います。
僕自身、ビジュアルデザインが不得意な部類のデザイナーなわけで、そう思われることもあるかもしれませんが、ただ、使ってみた時にどこか快いものを作っているつもりではあります。実際のユーザーに使っていただいて、そこで評価していただいたあとで、はじめてデザイナー自身も最終的な評価ができ、それによって自らの論理（仮説）を検証する必要があります。
そうして常に成長し続けられるデザイナーであろうと年始にあたり思いました。
ライフゴール設定は難しい。
Posted on | 1月 3, 2011 | No Comments
アラン・クーパーのゴールダイレクテッドデザインにおけるユーザーのゴールは、
- エクスペリエンスゴール（理想的な感覚）
- エンドゴール（タスクとしてのゴール）
- ライフゴール （実現するべき自己像）
の３つとされています。
この中で、社内で共有する際に最も難しいのが、ライフゴールです。
これを設定する意義を伝えるのはとても難しく、それは多分まだまだユーザーを概念として見てしまう今までのやり方によるものだと思うのですが、実はライフゴールはエンドゴールよりも重要度が高いものなので、そこのところを深く理解してもらいたいと常々思っています。
はじめに僕がいかなる宗教団体に属していない事を断った上で書くのですが、仏教の「方便」（「嘘も方便」とかの）という概念に関わる話に、キサーゴータミーの説話というものがあります。
話の内容としては、 愛する息子を失って半狂乱になった母親であるキサーゴータミーが釈迦に子供を生き返らせるように頼み、釈迦はそのための薬の材料として「これまで一人も死人を出したことの無い家から譲られた芥子の実」を要求します。
現代日本の核家族社会では定義によってはありえますが、説話の中では当然そんな家はなく、探していく中で逆に肉親を亡くした悲しみを語られたりします。
そして、その過程でキサーゴータミーは不幸は自分だけのものでない事を悟って、ついには出家する・・・というストーリーです。
高校時代にこれを知った僕は、ラザロを生き返らせるキリストとの違いに仏教への信頼を強めたのですが、今この説話で感じるのは、ライフゴール設定の難しさです。
説話では仏陀はキサーゴータミーのゴールが死んだ子供を生き返らせるという非現実的なものではなく、その死を受け容れ乗り越えて行くことである事を見極め、そこに導くためのエンドゴールを与えます。
ここまで思い切った設定は、自明の理で無い限りしない方が良いかと思いますが、 ここのバランスをどう設定するかがペルソナ設定の肝になると僕は思っています。（アラン・クーパーはライフゴールは無くてもいいと言ってますが・・・）
サービスやアプリが実現すると見せている機能が、実はその先のライフゴールを見据えていて、いつの間にか人生的にハッピーになっているなんて事ができたら、それこそ自分がこの仕事をやっている意義があろうというものです。
とかいう自分のライフゴールは・・と曝け出すのは恥ずかしいので別の機会にするとしても、それが僕自身のエンドゴールであることは間違いなさそうなので、ぜひ到達したいと思います。
UXデザインの手法と映画
Posted on | 1月 3, 2011 | No Comments
iTunesで「荒鷲の要塞」を観ました。
大学時代か何かに見ていて、以前からもう一度観たかったんですが、近所のTSUTAYAには無かったので、待望の一本でした。
内容的にはお約束的なところはあるものの、これぞサスペンス！という感じで、「スティング」まではいかないものの、二転三転する状況に、引きこまれました。
ただ、やはりこの時代の映画は人物が描かれていないというか、ストーリー的に必要なある特徴を持ったキャラクターとしてしか存在していない様に感じました。
もちろん、俳優の力によって補われている部分はあるのですが、彼らがなぜその任務を果たそうとしているのかはわかっても、彼らにとって任務を果たすことがどういう意味を持つのかがわかりません。
これでは、観客はその任務の成否でしか感情移入できないということになります。
最近は子どもがいるので映画館に行くことも少なくなったのですが、それでも観に行った「インセプション」では、主人公がある任務に取り組むのですが、なぜ彼がその任務を果たそうとするのか、その任務を果たすことによって何者になろうとしているのかまで描かれています。（それによってラストの解釈が難しくもなるのですが。）
で、これが、アラン・クーパーのゴールダイレクテッドデザインにおける、
- エンドゴール（果たすべき任務）
- ライフゴール（任務を果たすことによって実現される自己）
につながるのではないか・・と思ったので備忘ポストです。
今度映画をレビューする際には、ぜひそういった視点を持ってみようと思います。
これも訓練ということで。
（エクスペリエンスゴールがあるかどうかも見極めたいですね。 ）