WCAN 2013 Summer 2013/07/06

7/6に行われた、WCAN(ダブキャン)2013 Summerに参加しました。
WCANは、名古屋でWeb制作に携わる人たちの集まりとのこと。
私は、Webデザインはほとんど外出ししてしまうのですが、もうちょっとユーザ、デザイン、ITの関係性がなんとかならんかなと問題意識を持っているので、そのあたりでヒントが得られればと思って参加しました。

アジェンダ
1.LT
2.モバイルコンテンツデザイン 設計から実装までのデザインプロセス 矢野 りんさん
3.ハイパフォーマンス・Webフロントエンド 佐藤 歩さん
4.Co-Creative時代の企画・ディレクション 阿部 淳也さん

全体的な印象としては、IT系の開発課題も、Webの制作課題も、行き着くところは同じなんだというところです。

【1.LT】
一発目にLTって、斬新だなぁと思いました。IT系の勉強会だと、大抵本編のあとのおまけに近いからなぁ。あと、4分すぎたところで、一発アラームがなるのも、いいかも。ただ、5分の縛りはあまりきつくないようで、平気で5分超えてた人がいたのはどうかなぁ。
あと、Web制作に携わっている方だけあって、それぞれ見せ方にこだわりのあるものが多く、見せる資料を作成するときに参考にしたいものがありました。

勉強会で発表しよう!(山田さん)
:「まずアウトプット」は今すごく実感してる。
 アウトプットすることで、インプットの効率が良くなるのだ。

Pureでフラットにリニューアル(礒田さん)
:CSSフレームワーク。CSSも複雑怪奇になりがちだから、フレームワークという考え方、ありだなぁ。

社会人1年生、わたしの勉強法(森田さん)
:WCAN自体に50人もの学生さんがいらっしゃったそうでしたが、最近出た勉強会でも学生さんいたし、最近は学生のときからここまでやらんといかんのか・・・。

アクセス解析とUXデザインでモノづくり→コトづくり(勅使さん)
:ここで、ペルソナが出てきたか!一番自分の立場に近い感じがしました。

本当のアダプティブウェブデザイン(石原さん)
:最近アダプティブを目指しているサイトは目にしますね。
 今はあまり関係していない領域だけど、5年後には一般的になっているかもなぁ。
 最低限、基礎知識は持っておかないと。

Webコミュニケーション戦略の正体とは(吉村さん)
:ユーザに「どう思わせたいか?」という考え方、コミュニケーション戦略という考え方は、もっと身につけたい分野です。

【2.モバイルコンテンツデザイン 設計から実装までのデザインプロセス(矢野 りんさん)】

いろいろ試してみて、今行き着きつつある方法論を話してくださるとのことで、わくわく感が高まります。

モバイルデザインの特徴
・アジャイル:開発期間の区切りが短い
・ユーザー中心:デザインの見直しが多い

種類がたくさんあるので、「やってみないと分からない」ことが正直多い。
というか、そういう前提にしないと無理。

日本語Android入力Simejiの場合、スタートアップ時代は、コア機能→改良→新機能→改良→新機能だったが、累計ユーザー500万人以上となったころ、新機能→改良→改良→改良となった。

質を上げる必要性に迫られ、新機能を搭載する頻度を抑えて、改良を重ねていくフェーズに入った。

スタートアップ時代
・基礎設計の上に、新機能を追加
・コア機能のブラッシュアップ
 →開発者主導でコア機能の実現性を最優先課題に

信頼性の向上時代
・安定化を重視
・デザイン的な質の向上
 →デザイナー主導でユーザビリティの向上を最優先課題に

速さに! デザインパターン
質に! デザインガイドライン

Simejiの場合、4週間のイテレーションだがデザインにかけられるのは最初の1週間。

デザインパターン
1.ドリルダウン
 長所:操作が単純で目的の項目が探しやすい
 短所:選択肢が多すぎると探しにくい、ステップが多い
2.エキスパンドリスト
 長所:目的の項目が探しやすい、分類が明確なもの向き
 短所:
3.アクションバー(Android独自、ユーザーをトップに戻す常駐のインターフェース)
 長所:迷ったら最初に戻れる
 短所:PCサイトを使ったことがないユーザーには意味不明
    (PC見ていると思ったら大間違い!→これ、自分には新鮮でした)
    ユーザーは指の周りしか見ていないことに注意
4.ダッシュボード
 長所:選択肢がすぐ分かる。イメージの工夫でワクワク感。
 短所:選択肢が多すぎると選びにくい、あまりたくさん並べられない、
    イメージがコンテンツにそぐわないと腹立たしくなる
    →どれくらいが量として適切か
5.タブ
 長所:表示が速い。分かりやすい。
 短所:3つくらいしか並べられない。

デザインガイドライン
 ガイドラインを、アイコンや色味などについて作成する
 特にモバイルでは、色味は多彩。
 評価指標をもうけてやるべき。

おまけ
・スマホユーザーはSNSや検索結果から個別ページに飛んでくる。ナビゲーションにあまり頼らない。
・言葉で説明しても文字を読まない。漢字よりもまだひらがなの方が読まれる。
・入力することをすごく嫌がる。

まめにデザインを最適化する必要がある。

まとめ
・製品やサービスの時期に合ったデザイン計画をしよう
・初期はデザインパターンでデザインコストを下げよう
・デザインガイドラインを作って「作り直しに強い」サイトにしよう

⇒モバイルでは、やはり普通にアジャイル開発という一言だけで概念が通じるのかと思うと、うらやましくもあります。『種類がたくさんあるので、「やってみないと分からない」ことが正直多い。というか、そういう前提にしないと無理。』というのは、多くの人の実感だと思うし、自分もスマートフォンサイト作成してみて、まさしくそう思っているところ。

⇒今回気軽に「デザインパターン」という言葉が使われていたけれど、たぶんシステムエンジニアでいうところのGoFのデザインパターンとは違うものなので、Webデザイナーと話するときは注意した方がよいかも。

⇒初期コストを下げるという考え方は、Ruby on Railsとかで高速にスタートアップの開発をするとか、方法も出てきているので、システムエンジニアも意識するケースがあると思っています。

【3.ハイパフォーマンス・Webフロントエンド(佐藤 歩さん)】
・フロントエンドエンジニア
・フロントのパフォーマンス3要因:Network、Compute、Render
・Delayを感じさせないためのアニメーションとかは今回の話の対象外
・今回の話はWebKitベース:Chrome、Opera、Android、Safari

・#Perfmatters:Performance Matters

・Network
 ・リクエスト回数を減らす
 ・リソースのサイズを減らす Gzipped、イメージ・テキストの最適化、最小化
 ・コスパの良いものからやる

・Render
 ・Google Chrome Canary:開発版 で検証
 ・画面のリフレッシュレートを考慮する。60Hzだと、16msで収まるようにする。
 ・box-shadow、radiusは意外にコストが高い。いっそ画像にするとPaintコストが下がることも。

・Compute
 ・JavaScriptの実行内容を検証
 ・GC実行中はほかの処理が止まるので注意。

まとめ
・Network:毎日ログを見て、変化をとらえる。
・Render:CSSの過装飾に注意。
・Timelineは神ツール

⇒Webのパフォーマンスは、業務で最も気を使っている部分です。サーバーサイドばかりに時間を取られてなかなかレンダリングまで気が回りませんが、もうここはやらなければならない分野と認識しました。

【4.Co-Creative時代の企画・ディレクション(阿部 淳也さん)】
・熱意は全てを凌駕する!
・仕事のあり方ややり方を変えていくという姿勢。
・このセッションのゴール
 Awareness/Doubt(気づく、疑う)
 Think(考える)
 Action(行動する)

・Webでできることがおおきくなり、Web制作会社を超えた存在になってきている。
 いろんなことができるようになり、期待値が高まっている。
・認識を変えるのではなく、現実を変えることが重要(クラーク・コキッチ氏)
 例:Nike+、R/GA(9年ごとにビジネスモデルを変える)、Epic Mix(スキーを一つのソーシャルに)
・ブランドとは何か?
 ・ブランドはユーザの心の中にあるもの。
 ・サービスやプロダクトが根底にあった上で、生活者の中に生まれ根付いていくもの。
・まさに今、企業が必要としていること
 ・クライアントともっとコミュニケーションをとること。必要なものを聞き出すこと。
 ・新たなサービスや付加価値の提供へのシフト
・コミュニケーション設計の考慮のポイント
 ・体験:
  価値:体験からユーザが得られた結果に価値を感じるか?
  継続性:コンテンツとして継続的に成立するか?ユーザとどのようにつながっていたいのか?

・競争から協業へ
 Client, Agency, Production, Developers:クライアントも含めた協業体制が必要。

・提案から共に考える時代へ
 自分ごとにしてもらうために、ワークショップを行う
 検討・共有→決定
 フィジカルを使ってやる(一個のものを見る)体をつかってやると覚えている

・戦略と施策を立てるためのアプローチ
 ビジネス要件、現状の問題点、ユーザニーズ・インサイト

・ペルソナを書くのが有効

・情報とは受け手が取捨選択するもの。
 ユーザのモチベーションやベネフィットを考えないサービスやコミュニケーションは敬遠される。

・まとめ:毎日の中で少しずつ変えながら、ケーパビリティプレゼンの準備をしよう。

⇒僕らは何者か?という最初の問いに、インセプションデッキの問いに近いものを感じました。
 セッションそのものが、Webを発端に世界を変えようという一つのインセプションデッキの問いになっていたのではと思うほどです。

⇒フィジカルを使ってというのは、たとえば同じホワイトボードに書きながらでもよいと思うのですが、これは確かに効果があります。

⇒スクラムにおけるプロダクトオーナーは、舵取りとして強力な権限を持っています。
 しかし、Web(を中心とした領域の)制作においては、通常のプロダクトよりも多くの領域が関わりすぎていて、唯一絶対のオーナーが決めることすら難しいものになってきているのだとすると、ユーザが自分のこととして考えることができるようサポートするのはごく自然な話だと感じました。
 とすると、システムエンジニアが、「ユーザ、デザイン、ITの関係性」において、どれだけ協業に参加できるかが鍵になることになります。

コメント

非公開コメント