UIUX大好きなことに加え。登壇者がクックパッドの池田さん、深津さん、DeNAの坪田さんという、カレーに唐揚げのっけて温泉卵のっけた的超豪華御馳走なセミナーに参加してきました。
UIデザインの今とこれから～現役UIデザイナーによるUIデザイナーのためのセミナー～です。
感想としては「カレーに唐揚げのっけて温泉卵のっけて、さらにまいせんのカツサンドも食ったが、溢れんばかりの食欲がわいてきてデブまっしぐら」です。色気より食い気。食欲の秋、芸術の秋万歳。そんなかんじが伝わればと思います。
毎日の料理のためのUIデザイン
クックパッド株式会社 池田 拓司氏の登壇でした。
・レシピサイト、158万品＋プレミアムユーザー
・3500万UU/月 女性が85%
・エンジニアとデザイナー（8名）＝計50名
・集客→会員獲得→レシピをのせたり探すなどの行動、新規など全体のデザインを見ている
・3-4名位の小さなチームに分かれてる。機能改善は一週間。新規サービスは一ヶ月。アプリリニューアルは三カ月
・デザイナーの役割は広いが、人によって違う
・ユーザーへの密着、駆動開発：誰のために使われる？共感を得られる？を考える→ターゲット絞って限定公開→行動ログ指標評価→拡大公開
・根源的なユーザー理解が必要。EOGSというフレームワークを使っている
・ユーザーの声が開発者に届くようになっている 拡大公開したらすぐメールをチェック
・説明なしでもわかる無限語化
↓EOGSというフレームワーク、ITproにのっていたので転載します。
ユーザー理解のために何から考えていいかわからん！という人にとっても、常にUIUX考えている人が思考の幅を広げるためにも、こうした考えるときの下敷きはすごく大事だと思います。
・3つのルールがある
UIデザインルール、UI development rules、UI designFramework（twitterBootstrapみたいなの、文章だけでなくコードに。実装に近づける）
・『「毎日の」料理を楽しみにして心からの笑顔を増やす』毎日苦痛を感じる人のために、というデザインがポイントとなる
・「毎日」の料理のため、毎日アクセスしても自然になじめる使い勝手、デバイスをまたいでも違和感のない使い心地
・開発効率のため、デザイナーが全ての開発で手を動かさないように、素早いプロトタイプ開発をできるように
例：料理の見栄えよくするために寒色は使わない、レシピへのリンクは緑
・UIコンポーネントの抽象化、キーカラーの変数化
・UIデザインルールにはスタッフ全員がアクセス可能
ガイドライン化。うう、大事だと思いつつ日々の施策に流されて私はものすごく手がまわってない部分・・・・。泣
ガイドライン化は書類を作ることではなく、今後の開発効率を上げ、サイトの品質を担保していくという部分を肝に銘じて明文化していこうと反省しました。
・送客枠の位置の変更 位置争いがおこる。位置を変えることで総客数をコントロールできる？→クックパッドではあまり非連続な変化は起こらなかった。
・送客枠の見せ方 バナー型ではなく「フォーム型」に変更。位置の変更より、ユーザーがなんか入力したくなるものに。
・「リリース後８割」二か月で140点より一ヶ月で70点出してみるという思想！
・定性的なデザインの判断もしている
・事例の結果共有、ABテストの連続（繰り返してCVR12%アップ！）
・レシピから食のプラットホームへ。買い物、美容、娯楽、教育、健康へひろげていきたい
例：やさい便、特売情報、料理教室、アレルギー対応レシピアプリ
・「毎日の料理のためのUIデザイン」→「毎日の生活のためのUIデザイン」へ
・池田さんが大事だと思ってること「ユーザーにとって目的とすることを自然に可能とするデザイン」「届け手と受け手とのギャップの少ないデザイン」「ユーザーにとって驚きや感動を与えることができるデザイン」←今はとくにこれを大事にしてる♪
特に印象に残ったのは、ユーザーの声を開発者がきく、という体制について。
よくある事業会社では、ユーザーの声と開発者がかい離しているように感じています。ユーザーの声はカスタマーセンターがきいて、そこで編集された情報を企画が読んで、企画が作るものを考えて開発者へ依頼、しかも開発者は外注・・・という状況。それぞれが分業で成立はして効率的である一方、開発者がユーザーの幸せを「自分ごと」としてとらえられない面もでてくるのではないでしょうか。
自分ごととしてとらえて、サービスの問題解決に自発的にコミットしてく体制を作りたいならば。まずは毎日ユーザーの声や行動を感じられるきっかけが必要だと痛感しました。
ZOZOTOWN改善計画のように、ユーザーがサービスへの感想を投稿し、それをすぐ開発者も読めるようにする。開発後の評価指標としてユーザーの声も候補にあげる。自社サービスの改善のため、まだまだやれることがある！と思えて、わくわくしてきてしまいました。
fladdict流UIデザイン
深津 貴之氏の登壇でした。「アプリ開発の前にツールとメソドロジー（方法論）を開発する」というお話でした。
・自分でツールやメソッドを作ることで、工程を理解し最適化するバイアスが働く
・ペーパープロトのノートを作る、iOSテンプレート、iOSのピクセルスケール（定規）
・わざわざツールをつくる理由＝チームで使おう、と思える。いきなりPhotoshop立ち上げて考える、というのがなくなる。
↓ペーパープロトのノートはこれ。
iPhoneアプリ設計用の、ペーパープロトタイピング用ノート作った！！ 自社&業務用なので40冊単位でしか扱わなそうだけど。これでバリバリ仕事するぞー。 pic.twitter.com/jI9LTk5NCB
— 深津 貴之 (@fladdict) August 13, 2013
深津さんが紹介してくださったツールはこちらで購入できるそう♪
ほしい・・・・物欲の秋発動。
【送料無料】プロトタイピング・パッド 10packs, save 5%
時代や環境、経験則に依存しすぎないように、考え方や学習を抽象メソッドベースで行う
※webだけとか印刷だけとかじゃなく、横断できるような考え方を身につけられるように
(1)プロコンリスト 感情と好みを排除したデザイン評価リスト
長所と短所を並べる→つりあいのとれる長所と短所を打ち消していく→残った長所短所を考える。感覚や思いこみでの先走りにブレーキをかけ、客観的評価の機会を設けられる
(2)ステートメントシート コアコンセプトのチーム共有
ステイトメント（アプリの全てを説明できるシンプルな一文、ここから外れた機能は盛り込まない）、ターゲット、ユースケース、コア機能、諦めることを書く。プロジェクトの最初にこれを共有する
(3)フィッシュボーン図 問題と原因を網羅するツール
問題を書く→この問題を4つに分割する→この問題をさらに無数の問題に分割する
(4)イメージボードを作る 関連するビジュアルデザイン
Photoshop立ち上げるより、紙でがんがん可能性を試して問題をつぶしていく
さまざまなツールやメソッドを紹介いただきましたが。
UIを作る・改善をしていく中で、どデザインの現場においてどう考えてものをつくるのか、どうチームで意思決定していくかという部分が印象的でした。問題の内容や端末が違っても、デザインを考えられる思想。技術の進化は日進月歩だけども、こういう根幹て実は大きくはかわらないんじゃないのかなと思っています。
あと、深津さんの素敵プレゼンをささえてたツールがすてきだったのでメモメモ。
これで社内プレゼンしたらきっと素敵。
・スマホ操作したものろプロジェクターにうつす、リフレクターというアプリ(Mac Winあり) http://www.airsquirrels.com/reflector/
・紙で書いたUIをつなげて見せる→POPというアプリ https://popapp.in/
UIデザインの今とこれから
株式会社ディー・エヌ・エー 坪田 朋氏の登壇でした。坪田さんといえば、DeNAクリエイターブログの「UXデザイナーに求められる7つのミッション」の記事が私はとても好きで、熟読していました。
・グローバルNO1 DAU1000万、年間利益200億 どれか達成しましょうという新規サービスの目標がある。エンターテイメント事業本部の中に、企画推進部・システム部・UXデザイン部がある
・UIデザイナーの役割は、UIUX、情報設計領域のプロダクトリード
フロント画面のUI設計、デザインレギュレーション策定、グラフィックデザイン、デザイン制作効率化、生産性向上のための工程改善
・Scopy 5sec snap Pekoなど小規模なアプリを作ってる。開発期間は二カ月～四カ月 メンバーは2.5人くらい
・コンセプト調査（リサーチとストーリー策定）→仕様策定（UI開発・ユーザーテストくりかえし）→見積もり実装（タスク分解）→リリース（レビュー、リリース）→以後繰り返し
この流れは、坪田さん執筆の「UXデザイナーに求められる7つのミッション」の記事に記載されていたので、あわせてこちらでもご紹介します。全体もぐるぐるしつつ、デザインのたびに評価しつくりなおす、というフローがわかりやすいかと。
そもそものニーズ調査、ターゲット地域の調査、ターゲット人の調査、ささった場合要望ヒアリング
・開発前に決めること
リリース日（締め切り効果！）、キークレーム（ぶれないコンセプト）、リソース人数、リリース後の撤退基準
・ストーリー作成と優先順位 リリースブロッカーとなるものを決める（これは絶対やる、これは工数厳しそうなので2ndシーズン、みたいなかんじ）
・プロトタイプはHTML CSSで作ったり、紙で作ったり。実機で触ってみる。エンジニアとメールでライトにコミュニケーションとりつつ作っていく
・アプリのテスト配信にはTestFlight、プロジェクト管理にはBasecampを使っている。
私はアプリではなく、web上でのECサイト中心に動いていたので、TestFlightは初めて知りました。
TestFlightで手軽にiOSアプリのベータテストを行う for Flash Professional CS6
basecampについては、ちょっと前のだけども、webクリエイターボックスでも記事があったのでチェック。
プロジェクト管理ツール「Basecamp」の使い方 | Webクリエイターボックス
色々管理する手法はあるなあ。。私は今はレッドマインメインだけど、いろんなツール試してみたいなと思う今日この頃です。
また、DeNAらしい数字的な部分の話もでてきました。我の大好物也。
・北米では、クラウドソーシングでのテストをしている。1回あたりサービスに5～10万はらえばテストしてくれる。
・デザイナーむけには、DAUとダウンロード数気にするわけではなくリターンレートを気にするよう意識している
例：1週間後70％ 3週間後40%
・見た目の話 KPIをコントロールするためのデザイン
・適切なUI設計ができているのか、価値を明示・体験させられているのか、Pushコンテンツの最適化
・ユーザーの立場を中心に考えながら様々な方法論を組み合わせて問題を解決できる人
・サービスコンセプトを定義して、プロダクトの情報設計領域をリードできる人
「UI設計に必要なスキルはゲームから学べます」と坪田さん。
そうなのそうなの！ファミコンとかゲームボーイで私はすごく学んでる部分もあるので、共感してしまいました。ゲームセンターCX大好きだし。
アプリやサービスはただ作るだけ、ではなく。「作ったものをデザイナーやチームのメンバーがスピーディーかつ客観的に評価できるようにする。」「しかも次の施策につなげられる仕組みを考えておく」を考えておくのが必要・・・というのが坪田さんの話の骨格でした。特にDeNA社はプロジェクト進行における意思決定がロジカルな分、数字の話が多くでてきていました。
私も数字大好きっ子なので、サービス開発時に画面設計考えつつ、必ずサイトカタリスト等で「何の指標をKPIで取得するのか」「ここの指標は数字で計測したい」をセットで考えてます。たとえばサービス開発中、UI案で迷って「これがよいだろう」とベターという一案選んだときとか。本当にその案がよかったのかという検証には数字は欠かせません。もしそこで数字が悪ければ、なぜ悪いのかを定量的・定性的に分析して、あたためてた別案がいいとか、それかまったく別の思想がよいのかを考える材料としています。
他、絶対に必要としてつけた機能が、果たしてどの程度のユーザーに使われているのか。ユーザーが何を求めているのか。定量的、定性的評価を繰り返して繰り返して、ようやくその向こうにユーザーの姿が見えてくるものだと私は思っています。
———-
「自分が思うように」「クライアントからいわれたように」作る、だけじゃなく。
作っている時も、ユーザーにとどいたときも、検証しながら作ることがよいUIデザインにつながるんだという思いを改めて感じたセミナーでした。PDCAをまわす。その一言なんだけど、その一言の行動は、事業運営している中ではとても難易度は高いと思っています。組織的に時間や工数をとったりするのが難しいところがある、というのはもちろんなんだけど。UIUXに関わる人が経験をためればためるほど、自分に謎の自信がわいてきて、「ユーザーはこう思うからこうすればいいんだよ」と決めつけちゃいがちになるから。
自社は比較的PDCAをしっかりまわしているとは思うのですが、まだまだやれることはあるんだと思います。私と同じように、サービスデザインに関わる人たちが、同じように血湧き肉躍っていますように！ぐつぐつぐつぐつ。
Leave a Reply