今日からはじめるインクルーシブデザイン

これは2015年度履修生の大谷による 産技大人間中心デザインOB/OG Advent Calendar 2018 - Adventar の 2 日目の記事です。

インクルーシブデザインとは

Every design decision has the potential to include or exclude customers. Inclusive design emphasizes the contribution that understanding user diversity makes to informing these decisions, and thus to including as many people as possible. User diversity covers variation in capabilities, needs and aspirations.
すべてのデザイン上の決定にはユーザーを参画させることができます。インクルーシブデザインとは、できるだけ多くの人々にそのプロセスを伝えながら決定に参画してもらうことで、ユーザーの多様性を理解するための手法です。ユーザーの多様性を通じて幅広い能力、ニーズ、および要望に対応することができます。
http://www.inclusivedesigntoolkit.com/whatis/whatis.html

主にアクセシビリティの文脈で、デザインプロセスの上流から実際の利用者（特に障碍を持つ方やマイノリティの方）に参画してもらうことで、より品質の高いプロダクトやサービスを提供しよう、という手法です。

なぜ、インクルーシブデザイン？

The importance of creating inclusive government services - Government Digital Service

アクセシビリティの文脈なので行政サービスなどの分野では多く取り入れられているようです。やることで価値に直結するので分かりやすいですよね。

Accessibility - Apple
Inclusion & Diversity - Apple

ユーザーが多岐にわたる巨大な企業では、該当するユーザーの実数が多いのでビジネス的にも取り組む価値があります。
例えば国内における40才未満のロービジョンの割合は 0.2% ですが、これは1000万個売れる商品であれば1万個分の売り上げに相当します
参考

また、特に障碍を持つ方やマイノリティの方に限ることなく、利用文脈（強い日光の下でスマートフォンを使ったり、片手にギプスをつけている状態でゲームをしたりなど）による利用がしにくいといった不利益の軽減にもなるので、「自分のプロダクトは普通のユーザー *1 しか使わないから」と言い切ってしまえる訳でもありません。

自分たちがやっていること

自分が担当しているのは10〜20代の女性向けファッションメディアなんですが、実際のターゲットユーザーである 20 前後の女性に、動作チェックのアシスタントとして QA アルバイトに来てもらい、毎週行なっている社内向けリリース版を利用して常に最新のアプリで動作確認をお願いしています。

もちろん、デザインの決定に関わってもらっている訳ではないですが、以下のようなメリットがあると思っています。

  • 新しく実装した機能について違和感がないか確認してもらえる
  • 動作確認についても普段使っている状態（持ち方、タッチの仕方、利用の仕方等）で確認してもらえる
  • 普通にデザインなどで困った時に聞ける

フィードバックループを作る

ずっと、事業側としてプロダクトを作ることをやってきて思うので会うが、実際に手を動かすエンジニアやデザイナーに対して「ユーザーを見る」という態度を醸成することが一番難しくて大切なことだと思っています。
特にプロダクトのリリースサイクルの間隔がどんどん短くなっているなか、常に隣にユーザーのお手本がいて毎回のイテレーションになんらかの形でその意見が反映される状態は 強い プロダクトを作るために理想的な環境ではないでしょうか。
逆にユーザーを見ないイテレーションを 10　回実施して、 1 回だけユーザー調査をじっくり行うイテレーションを一回挟むという方法にどこまで、有効性があるでしょうか？

ちょっと脱線して、シリコンバレーの強さとは

ちょっとだけ話がずれますが、アメリカは多様性の国ですよね。
もちろんそれだけが理由ではないと思いますが、プロダクトを作るにあたって自然に多様な価値観を持つチームが自然に出来上がる環境というのはシリコンバレーから新しい価値が生まれる一因にはなっているんんじゃないかなぁ。

まずは一歩、そして

「これがインクルーシブデザインか？」と問われれば違うのだと思います。
ですが、操作困難性という意味で「高校に入るまでスマホを買ってもらえなかった女の子」と「ロービジョンの女の子」にどんな違いがあるのでしょうか？

大事なのはあなたの思い描いているユーザーと実際のユーザーは違うということ、そしてその先に色々な状況や立場のユーザーがいるということを理解することです。
そのために、まずは目の前にユーザーがいる、ユーザーと一緒にプロダクトを作っている状態をを自然だと思えるようになることを最初の一歩にするために、（とても広い意味での）インクルーシブデザインをはじめて見ませんか？

*1:「普通」と言ってしまっている時点でユーザーコンテキストを理解していない訳ですが

UX DAYS TOKYO 2016で感じた５つのこと

WIP

f:id:k-sya:20160411232451j:plain

3月18日〜20日に開催された UX DAYS TOKYO 2016 。カバー写真でわかるように ジェシー・ジェイムス・ギャレット を見に行くというミーハー根性だけで行ったのですが、予想を上回る内容で、今の自分の課題点や想いと重なる部分が多く非常に実りあるカンファレンスでした。ざっくりとまとめると「IAとビジュアルスキルの重要性への原点回帰」なのですが、頭の中の整理をかねて、私の感じたこれからのUX業界のこれからについて5つの視点でまとめてみました。

UXという言葉がIAに追いついてきた?!

IA関連の話の多かった感がある今回のUX DAYS TOKYO。

IAを情報の整理だけと考えてしまうのは非常にもったいないです。Abby Covert の話にもありましたが、情報を整理するにはどのような視点で整理するかが重要で、それにはユーザーの理解は必須となります。誰かに向けてプロダクトを作る以上、その誰かが誰なのかを考えなければいけない。UXとIAはほぼ同じ事を、違う（あるいは多くの部分で重なる）アプローチで実践しているのです。

UXとIAを比較した時、歴史的にもスキル体系を見ても（少なくともウェブ制作の実務においては）IAの方に一日の長があります。極端な言い方をしてしまうと「誰にでもできるUXデザイン」と「専門職としてのIA」という棲み分けだった両者ですが*1、UXは言葉や業界の成熟とともに、ようやくIAと同じレベルにたどり着いたのかもしれません。

逆に言うとUXデザイナーを志す人間であればIAのスキルは今後必須です。IAに関しては書籍など情報がたくさんありますし、最近ではUX文脈でのIAを解説した書籍の発売も続いています。デザインという枠からもう一歩踏み出すのが重要なタイミングに来ているのでしょう。

コミュニケーションデザインの重要性

デザインとはいかに「伝えるか」というスキルです。 Kevin のストーリーボーディングにしても Abby の組織内の言葉の統一にしても、いかに正しく効果的に感情を含めて価値・ストーリーを伝えるか、という事にフォーカスした内容でした。これからのデザイナーにとってコミュニケーションスキル、といっても対話スキルではなくコミュニケーションの仕組みを作るスキルが重要になってくるのでしょう。

コミュニケーションには2つあります。一つは組織内のコミュニケーション、もう一つはユーザーとプロダクト・サービスのコミュニケーションです。ユーザーに向けての実践はずっと進められておりリソースも大量にあるのですが、組織内のコミュニケーションという文脈でいうとあまりありません。海外のUX系の書籍紹介で必ず紹介される書籍に「Webサイト設計のためのデザイン&プランニング」という本がありますが、国内ではあまり話題になったのを見たことがありません。ウェブ制作プロジェクトのドキュメントデザインにフォーカスした書籍で、デザイナーがプロジェクトのコミュニケーションに対して積極的に関わる事で、どれだけ価値を生む事ができるかよく分かる良書となっています。

コミュニケーションデザインはプロセスです。UX界隈ではあまり良く思われない風潮のあるA/Bテストですが、何回も実施する事でチームの中での共通言語を作る、という意味で非常に役立った経験があります。こういった時間軸と価値観を結びつけたデザイン能力というのはデザイナーの得意分野のはずです。いわゆるUXデザイナーの役割としてのファシリテーション、WS設計・実施だけではなく、もう一歩踏み込んだ形でプロジェクトのコミュニケーションにコミットしていく事がこれからのデザイナーの役割なのかもしれません。

レイヤーで考えるUX

もう一つ感じたのは、デザインにおいてレイヤー構造で考えるという事は必須だということです。JJGの5層構造しかり、ラダーアップ・ラダーダウンによる価値分析しかり、一つの事象を複層のレイヤー構造で理解してアウトプットとしての"形"に反映していく事がデザイナーの本分だと思うのですが、同時に非常に難しいスキルでもあります。

もちろん、優秀なデザイン思考ができる人は自然にやっているのでしょう。でもそれだけだと２つ問題があると思っていて、一つは暗黙知となってスキルの継承ができないこと。そしてもう一つが重要で、表層レイヤー以外のレイヤーの情報がコミュニケーションから取り残されるという問題です。よく異職種間で言語が通じないというケースが発生すると思うのですが、これは顕在化されたデザインやプロダクトの裏に文化やコンテクストという別レイヤーがあり、それが見える化されていない事による「分かってほしい価値を理解してもらえない」という現象が発生するのではないのかと思うのです。

お互いの歩み寄りによって、という解決策になりがちですが、伝えることのプロフェッショナルであるデザイナーとしてはここをおざなりにするのは非常に良くないです。昨年からのプロトタイピングツールの流行で、平面×時間軸での思考の見える化はずいぶん進んだと思うのですが、まだレイヤードな情報をアウトプットし視覚化するためのツールはないんですよね。こういった分野はIAという職種がずっと取り組んでいた分野でもあると思うので、知見を取り込み、さらに進んでいくべき方向なのかな、と思います。

言葉の使い方とUX

「正しいコピーライティング」はGVがプロトタイプを作る際に重要視しているポイントです。かならず初期段階から正しい言葉を使うことが大切とのこと。デザインスプリントのワークショップにおいても、実在する（しそうな）コンテンツを使って、略さないで文章を使うように念押しされた事からもこれが重要だという事がわかるでしょう。

また、Abby のセッションでは組織内で決まった言葉を使う事の重要性が繰り返し述べられていました。そもそも、UX界隈においても言葉の定義は非常にあいまいで、UXという言葉そのものでさえ人によってまったく違うものを指している事がよくあります。それ自体は必ずしも悪ではないですが、チームとなった時にそのままの状態では、なにかを成し遂げようとしても必ず失敗するでしょう。

「とりあえずダミーテキストで……」となりがちな文言やテキストコンテンツですが、経験価値の提供という意味とコミュニケーションという両方の面で非常に重要だという事が語られたカンファレンスだったと思います。

余談ですが、この分野においては日本の活字文化や優秀な"編集者"が揃っているというのは、すごい強みになると思っています。紙からウェブへ。スキルセットと報酬のアンマッチで不幸な話しか聞かない業界ではありますが、言葉でコンテンツの価値を最大限伝えるプロフェッショナルという彼らのスキルは、これから確実に見直されていくのではないでしょうか。

デザイナーであること

ここまではIA的なポイントが続きましたが、それ以上に今回の2日間を通して一番強く感じたのはビジュアルデザインスキル重要性でした。 たった一枚の落書きがプロジェクトの方向性を決めることもあるし、ホワイトボードに書き出すだけでずっと同じところをぐるぐるしていた会議が一気に前に進むこともある。視覚化がコミュニケーションを促進する効果は非常に強力です。

GVのDesign Sprintは、コンセプトの持つ価値を最適にビジュアライズし、クオリティの高いインターフェイスを短期間で作り上げることのできる、デザイナーの高いスキルがあってこそのアプローチです。Kevin のストーリーボーディングについても、適切にビジュアライズできなければ、ただ誤解を与えてしまうだけです（彼自身は「上手い必要はない」と言っていましたが）。

最近、"UI/UX"という言葉の価値を見直していて、やはりビジュアルデザインはエクスペリエンスの重要な部分を占める物だと素直に思えるようになってきました。というよりも、高いビジュアルデザインスキルを持つことができなければ、どこかで限界に突き当たってしまうのでしょう。ここは本当に個人として取り組んでいかないといけない部分ですね。

最後に

ゆっくりと反芻しながらまとめていたら予想以上に長くかかってしまいましたが、本当にすばらしいカンファレンスでした。 IAの話題の多さとエージェンシーという彼らの立場から若干オールドファッションな印象は感じましたが、インハウスであるからこそ彼らの専門的なプロフェッショナリズムに学ぶことはたくさんあると思います。今年は業界全体ももう一つレイヤーが上がる気がしますし、自身についてもこれまで培ってきたスキルを棚卸しして次に進むための整理ができました。

もう一歩前へ。

*1:アカデミックな話ではなく、あくまでもIT業界における実際として。

HTTP/2がつなぐSEOとフロントエンド開発の未来

この投稿はhttp2 Advent Calendar 2015の24日目の記事として インフラ系の人がHTTP/2推進を頑張ってくれると、私のようなフロントエンドやSEOに関わる人間が幸せになるので、ぜひ、とにかく、なんとしてでも頑張っていただきたい！という応援のメッセージを送りたいという思いが形になったものです。

11月末。Googleの中の人でも飛び抜けて有名なジョン・ミュラー氏がGoogleのクローラーがHTTP/2に対応すると発表しました。 さらに、その中でランキング要因としても影響すると明言。SEO業界に衝撃が走りました。

Why Everyone Should Be Moving To HTTP/2

さらに、CDN大手のCloudflareがデフォルトでHTTP/2に対応するなど、時代の波は確実にHTTP/2に来ています。

Cloudflareが全ユーザにデフォルトでHTTP/2を適用、大企業ユーザのみオプトイン | TechCrunch Japan

SEOにおけるHTTP/2とは？

HTTP/2はSEOに優位だ…という件ですが、とはいえ単純に対応すればいいという単純なものではありません。

今年の4月からモバイルフレンドリー対応といってスマートフォンで検索した際に、スマートフォン対応が正しくされているサイトはなるべく上位に表示する、というアナウンスがありました。さらにその中でユーザーエクスペリエンスが高いサイトを評価すると言っています。

  • 携帯端末では一般的でないソフトウェア（Flash など）を使用していないこと
  • ズームしなくても判読できるテキストを使用していること
  • ユーザーが横にスクロールしたりズームしたりする必要がないよう、コンテンツのサイズが画面のサイズと一致していること
  • 目的のリンクを簡単にタップできるよう、それぞれのリンクが十分に離れた状態で配置されていること
  • インターステシャル広告を使用していない

ちなみにUXという概念が適用されているのはあくまでモバイルのみなのですが、Google社がUXという観点でサイトを評価していこうという方向性なのは間違いありません。 さらに、オフィシャルには言われていませんが、サイトの表示速度についても、ランキング要因として評価しているのではないか？と言われています。

つまるところ、HTTP/2に対応すればSEOで有利になるのではなく、HTTP/2を利用することで早くなった=ユーザーに利益があるページを評価する。 そのための、HTTP/2対応クローラという話なのでHTTP/2に対応するだけではなく、HTTP/2で早いサイトを作ることが大切になるのです。

フロントエンド・エンジニアがささえるSEO

HTTP/2でなくとも、パフォーマンスの高いサイトは最終的に評価されます。

画像スプライト、ドメインシャーディング、ビルドツールを使ったミニマイズや結合などなど、パフォーマンス向上のテクニックはあり、ランキングに直接影響はないと明言されていたとしても、実際に相関はあると言われています（質の良いサイトにはリンクが貼られやすい、バズりやすいというのが主な理由です）。

意識はあまりされていませんが、これからのSEOは日々ユーザーに素早くサイトを届けようと奮闘しているフロントエンジニアが重要な役割を担うことになっていきます。

で、先ほどのHTTP/2の話に戻るわけですが、「SEOに有利になるから、HTTP/2で超早いサイトにしてくれ。」これってフロントエンドエンジニアには嬉しいことなのではないでしょうか？ だって、みんなHTTP/2を使いたいですよね？ HTTP/2時代のサイトパフォーマンスの最適化はJavaScriptの実装を最適化したり、CSS設計を効率化したりといった本質的な部分にコミットできるから。

もう、慣れないPhotoshopを開いて、画像をちまちま結合していく作業は不要になるわけです。

HTTP/2は架け橋

とはいえ、じゃあ既存のサービスをHTTP/2にするか？というと、それはハードルが高いのも事実ですよね。そこでSEOの登場です。 フロントエンドとしては「SEOに有利だからHTTP/2にしましょう！」と高らかに宣言できる時代が来たということだと思うのです。

SEOはHTTP/2の影響でフロントエンドエンジニアの大切さを意識するようになり
フロントエンドエンジニアはSEOの要請でHTTP/2の導入の後押しができる

Web標準の進化で、仲が悪い……とよく言われるSEOとフロントエンドエンジニアが手を取り合って協力する事ができる日が来たのは、両方にコミットしてきた私のような隙間エンジニアはすげー嬉しいというのが本音です。

ハックや小手先のテクニックではなく、本質的な所にザクザク切り込んでいけるようになるわけで、2016年のウェブも本当に楽しみですね！ ぜひ、インフラ担当の皆様におきましては、SEO担当やフロントエンドエンジニアを味方に付けて、HTTP/2導入の推進をしていただければと思います。

だよ派 of UXデザイン

みなさん、今日も元気にUXをデザインしてますか？ところでUXデザインってなんなんでしょうか？そこがいつもわからないのでちょっと分類してみましたよ。

註：私の脳内のUXデザインの定義分布です。一般的な意見を集約した物ではありませんのでご注意ください。

UXデザインとは
┣ UI/UXデザインだよ派
┃┣ かっこいいビジュアルやUIだよ派
┃┣ ワクワクするインタラクションデザインだよ派
┃┣ インタラクションの手触りだよ派
┃┣ UIはUXにおいて一番大切だよ派
┃┣ スピードこそがUXだよ派
┃┗ ストレスなく使える使いやすさだよ派
┣ ユーザー体験をデザインすることだよ派
┃┣ ユーザーの利用シーンを考慮したデザインだよ派
┃┣ ユーザーの感情をデザインすることだよ派
┃┣ ユーザー中心のイノベーションだよ派
┃┗ ユーザーの顕在化していないニーズに応えるプロダクトを作ることだよ派
┣ 他の概念の置き換えだよ派
┃┣ おもてなしだよ派
┃┣ マーケティング戦略だよ派
┃┃┣ オムニチャネルのサービス設計だよ派
┃┃┗ グロースハックだよ派
┃┣ 経営戦略だよ派
┃┣ HCDと一緒だよ派
┃┃┗ HCDの拡張概念だよ派
┃┣ サービス設計&運用その物だよ派
┃┣ IAの置き換えワードだよ派
┃┃┗ IAの方が偉いよ派
┃┣ ユーザーリサーチの手法だよ派
┃┗ ポストイットだよ派
┣ プロセスだよ派
┃┣ 組織論だよ派
┃┣ サービスデザイン手法のひとつだよ派
┃┣ 設計手法のひとつだよ派
┃┣ PDCAだよ派
┃┗ プロジェクトマネジメント手法のひとつだよ派
┣ UXデザインはまだまだだよ派
┃┣ UC（User eCstasy）の方がすごいよ派
┃┣ CX（Customer Experience）の方がすごいよ派
┃┗ 時代はエンタープライズUXだよ派
┣ UXに意味はないよ派
┃┣ あなたの思うUXがUXだよ派
┃┣ UXなんてデザインできないよ派
┃┣ ただのバズワードだよ派
┃┃┣ 言っておけば稟議が通りやすいよ派
┃┃┣ 言っておけばクライアントが満足するよ派
┃┃┗ 言っておけばなんとなく自分がかっこ良く見えるよ派
┃┗ バカ発見器だよ派
┗ 原典派
　┣ ISO9241-210だよ派
　┗ UX白書だよ派

ディスコミュニケーション

私が「UX」という言葉が嫌いな理由はディスコミュニケーションの温床だからです。これほど耳触りがよく便利な言葉はない。UXって言葉でまったく別の方向にサービスやプロダクトを推進された時にはたまったもんじゃない。

きちんと学んだ人なら誰もが感じると思いますが、ほとんどの人が使うUXという表現は他の言葉で置き換えが可能です。であれば適切な言葉を使えばよいのです。

もしUXデザインという言葉を使いたいならきちんと学んで使いませんか？そして、その難易度の高さに打ちのめされれば良いwww

最後にちょっとイイ話

個人的にはUXはデザインできる物ではないと思っています。
なぜならエクスペリエンスを認知するユーザーは本当に千差万別で、こちらが思ってもいないような使い方をしてくれる。 えー！そんな所にバリューを見つけるの？？？というような本当にキラメキみたいなもんです。 ものづくりに関わっている人間としては、その瞬間が一番楽しんですよね。作り手と使う人の究極のコラボレーションというか。

そして、それにはユーザーの声に耳を傾け続けることがなにより重要だし、良い物を作り続けるというこだわりがなにより大切だと思うのです。 ということで、私はHCDという考え方が大好きで、イノベーティブではないけれど地道にユーザーを見続けたいと思うのです。

このエントリーは「UX Tokyo Advent Calendar 2015」の3日目の投稿です。4日目と5日目、誰か手をあげろ！

Frontrend Conference The Finalに参加

Frontend

Frontrend Conference - A conference for front-end developer（2015年2月21日開催）に参加してきたので自分用メモ

[Keynote] Pragmatic Front-end Developer: From Artisan to Expert

斉藤さんによるエモい話。フロントエンドは無くならないどころか、これからより一層面白くなってくると思う。

資料（ドラフト）

リンク

JavaScript
CSS
  • idiomatic.css, css guidelines, sass guideline
html
  • code guide by mark otto
tools
  • editorconfig, jscs, csscomb
styleguide
style generator
Tips

[JavaScript] Reactive Programming in JavaScript

あほむさんによるRFP入門。いままで見たFRP入門の中で一番分かりやすかった。
いろいろ触ってみよう。Bacon.js押しだったけど、このタイミングだとReact.js使うかな

資料

リンク

[JavaScript] Introduction to React

外村さんのReact話。
一つ前の記事を受けて、いろいろさわる際の参考にする

資料

リンク

[CSS] Web Components/Polymer, Styling Shadow DOM

谷さんによるWeb Compornents話。おさらいから設計的な。
この辺りが普通に使えるようになるとフロントエンド本気で面白くなる。

リンク

専用セレクタ

  • :host()
  • :host-context()
  • ::shadow
  • ::contents
  • /deep combinator（>>>）

設計のヒント

Tweet

ライトニングトーク

Tweet

[JavaScript] Introduction to ServiceWorker

1000chさんにによるServiceWorker話。
実際に使えるのはずいぶん先だろうけど、5〜10年後のウェブがどうなるのかって視点で見てた。
ここまで考えてウェブを作るべきなのか？という話もあると思うけど。

資料

リンク

キーワード

  • offline first

  • navigator.onLine

    • on.online, on,offline
  • FileSystem API
    • ブラウザ実装されていない
  • Web Storage API
  • indexedDB API
  • Application Cache
  • Service Worker
    • 高機能なローカルプロキシ
    • リクエスト検知
    • リクエスト改ざん
    • on.fetch
    • Fetch API
    • Cache API
    • background Sync API
      • Sync Event
      • Sync Manager
    • Web Push API
      • サービスワーカーをプッシュサーバに登録してプッシュを受け取る
      • push manager

[CSS] Inline layout

づどさんのInline Layoutの話。面白そうだったけど聞けず。
しっかり理解って意味でためになる資料。Tweetで保管しつつ

資料

[JavaScript] JavaScriptテストの疑問、お答えします。

kyo_agoさんのTestエモ話

資料

リンク

test

  • ユニットテスト
    • mocha
    • jasmine
    • （QUnit）
  • SinonJS
  • Promiseパターンのテストどうする？
  • faketimer系を使わなくなった
  • powerAssert
  • E2E
    • Protractor
    • testeam
  • test runnner
    • karma
    • testem
  • Isomorphicだとテスト楽
  • Phantomは結構レガシー

Tweet

[CSS] Styling Atom (Editor)

atom使ってないし、ちょっと色々話が飛んでてどう聞けば良いのだろう…って感じだった。
プレゼンにエディタ使ってるのが印象的
SUIT CSSの事を知ることができたのはよかったかな

リンク

Tweet

検索連動広告戦略セッション@SMX Advance2014

seo SMX Anvance 2014

Search Engine LandのSMX Advance2014レポートを読んだ際のメモその４。
なんだかんだで重要なペイドサーチセッションが今年のSMX Advanceのラストセッション。４人のパネリストによって発表されたとの事。分野が違ってこっちに踏み込む勇気はないけど、面白そうな業界だよね。

Up Close @ SMX Advanced: Amazing Paid Search Tactics

Heather Cooan @ Clix Marketing

ペイドサーチ分析用のGoogle Analyticsティップス。
PPCマーケティングが完全独立スキルだとよくわかる。単純な運用だけじゃやってけない、って話なんだろうなー。

  • カスタムデータソースでコストデータを読み込み、流入経路毎のROIを計る
  • フィルタを活用した検索パートナーのパフォーマンス測定ビュー
  • 便利な指標紹介
    • ページバリュー
    • アシストコンバージョンバリュー

Steve Hammer @ RankHammer

AdWordsスクリプトを使った自動化について。
大事なのは急いだり、ステップを飛ばしたりしない事。きちんとひとつずつ効果を検証しながら進める事が大事。

  • 自動化の３つの利点
    • 計算
    • 外部連携（エクスポート、インポート）
    • パラメーター（テキストなどの自動変更）
  • 基本フレームワーク
    • Find
    • Fix
    • Scale
    • Success
  • その他サンプル多数

Jennifer Slegg

AdWordsのライティング、キーワード選定について。

  • 文法は重要。スペルミスで全く効果がなくなることも
  • サイトリンクは重要だけど遣り過ぎないように。マックスは25文字だが12文字程度におさめるように。
  • 競合の多いビッグワードの観察も大事。どんな事をやっているか、自分のキャンペーンに活かせないか考えよう。
  • 最後にちょっと驚きの手法で、たまには除外ワードで出稿する事も大事、とのこと。思い込みで役立つキーワードを捨ててるかもよ？

Larry Kim @ WordStream

最後はLarry Kimによる、クオリティスコアの話。
クオリティスコアが重要視されるようになって、従来の戦略が使えなくなったという話。

  • これまでCTRが少なめでもそれなりのビッグワードで出稿していた方が効果があった
  • ただし、その方法だとクオリティスコアの減少が著しい
  • また低いクオリティスコアのアカウントへのBidの価格上昇も大きく、かなりのコスト増
  • クオリティスコアの上昇（下降）でインプレッションに9%程度の影響が
  • 表示順位は3位あたりが一番コストパフォーマンスがいいらしい
  • CTRが低くてもCTAが高いと意味が無いのでLPの見直し大事
  • 下1/3のキーワードを削除してまるっと見直そう

ローカルSEOセッション@SMX Advance2014

seo SMX Anvance 2014

Search Engine LandのSMX Advance2014レポートを読んだ際のメモその３。
Search Engine Landを見ている限り、いま一番熱いSEOの話題であるローカルSEOのセッション。スライドは無しでフリートーク形式で行われて、会場は満員だったらしい。さもありなん。

Up Close @ SMX Advanced: Local Super Therapy Session

得意分野ではないのと中途半端にピックアップできないので、主な話題だけリストアップ。気になる人は原文を読みましょう。

  • Google My Business
  • Local SEOにはインタラクションが大事
  • サイテーションの考え方を変えよう
    • サイテーションはリンクのような物でGoogleの性能アップでNAPの統一などは重要ではなくなった
  • レビューはランキング要素と考えないように
  • コールトラッキングはしないこと
    • 電話番号はブランドの一部
    • 番号が分散するなどもってのほかというパネリストの全会一致
    • 単一の番号であれば問題は無いがトラッキング業者を変えるorやめるのができなくなるリスク