Hatena::ブログ(Diary)

in0in0の日記

2011-06-05 「恰好良い」Webデザインの作り方

いやー1年間みごとに放置してました。

昨日、福井で開催された震災チャリティイベント、「UPGRADE JAPAN!!」でおはなししてきました。

スライドをアップしたのでシェアしたいと思います。

「恰好良い」Webデザインの作り方

見た目としてのデザインというところに目を向け、考察してみました。

実際webデザインは技術的な話題や新しい考えかたの話題は多いんですけど、見た目を整えるって意味のデザインってあまり語られてない気がします。webデザインをプロダクトや、空間デザインに近いものと位置づけ、デザインのワークフローを「視線の誘導」と「装飾の演出」の2つのSTEPに分解することを提案してます。

企画やコンテンツのほうが重要なのは当然ですが、実制作に入った後のワークフローとして参考にしていただければ幸いです。

2010-06-04

制作者の「3ある」、ユーザーの「3ない」

04:32

f:id:in0in0:20100605035354j:image

先日社内勉強会にてお話させていただきました。

テーマはユーザビリテイです。

web標準が制作業界に定着し、我が社でもユーザビリティという言葉を聞く機会がふえてきました。にも関わらずそのユーザビリティ議論は自分が使いにくかったことに起因していたり、偉い人の鶴の一声で進んでるような案件が目につきます。それユーザーのこと考えてないよねと問いただしたくなったわけですね。そこで「それ、誰のためのユーザビリティ?」という発表をさせていただきました。

我々制作者と、ユーザーとの間には決定的な溝がある!ということで“制作者の「3ある」、ユーザーの「3ない」”としてまとめてみました。


制作者の「3ある」

まずは制作者が持っている3つの特徴を紹介します。業界人なら共感できることうけあいのまさにあるあるネタですねw

欲望がある

制作者は欲深いです。

一ページの中に情報をつめこんでおけば、ユーザーはすべて目を通してくれると思っています。また、ユーザーには全く関係ない社内方針や社長など富裕層の要望などすべてを盛り込もうとします。

知識がある

制作者はプロです。

ナビゲーション構造や、リンクのありか、ここはAJAXだからページ遷移しないとかここは別ウィンドウで開くとか…サイト内の仕様を熟知しています。技術的な知識も当然豊富に持っています。

愛着がある

制作者はうぬぼれています。

クールなデザイン、スマートなコード、魅惑のライティング、空気のような仕様…サイトのなかにはたくさんの思いでと、あたかも長年住み慣れた実家のような愛着がそこにはあります。


ユーザーの「3ない」

それに対してユーザーが持っていないものを3つ紹介します。制作者が持っているものと完全にずれてますね。

読まない

ユーザーはページ内の文章を読んではくれません。

自分の興味があるキーワードを拾い読みするだけです。文章が多いだけで嫌気がさしますし、それっぽいだけで違うリンクをクリックもします。そこに情報がみつからなければすぐ帰りますし、すべての情報があっても満足して帰っていきます。

知らない

ユーザーはサイトの仕様を知りません。

どこに何があるのか、そのリンクがjavascriptで開くのか別ウィンドウなのかも知りませんし、そういう場合でも戻るボタンで戻れると思っています。いちいち考えることもしませんしそもそも考えたくありません。

興味ない

ユーザーはサイトそのものに興味がありません。

興味があるのはサイトにある情報と、それを手に入れた後の自分の生活です。デザインなんかこれっぽっちも見ていないですし、覚えてもいません。最近リニューアルしたyoutubegoogleリニューアル前がどんなデザインだったか絵に描ける人が何人いるでしょうか?おそらく多くの人は動画や検索することが目的であり、それ以外は全く見ていません。


じゃー制作者はどうしたらいいのか

制作者の「3ある」とユーザーの「3ない」の間には埋めがたい溝があります。「3ある」を常に意識して抑制せよ!というのはブッダの教えレベルの話で悟りを開く必要がありますw(そういうアプローチも面白いですがw)

なのでまずはユーザーを知ることから始めてはいかがでしょうか?

幸いにしてwebサイトアクセス解析によってある程度、ユーザー像と動きを知ることができます。すべての中心に客観的なデータを持ってくることで自然と「3ある」は抑制できると思います。また、家族や友人レベルで良いのでユーザーテストをしてみるのも良いかもしれません。ちなみにうちの母親でテストをした結果、デスクトップの左上にあるマークがインターネットという覚え方をしてましたwこの場所からアイコンが移動しただけでわからなくなるそうです。こんなレベルでもmixiを使ってブログを書いていたりyoutubeを楽しんだりしています。webありきの世界になっている中で私たち業界人はもっと謙虚になるべきなんでしょうね。

「3ある」を抑えて「3ない」を知る。

ユーザビリティを考える大前提として肝に命じておくべき知識です。

2010-02-11

Firefoxアドオン ポップアップ辞書「フェッチイミ」

02:41

f:id:in0in0:20100212023723p:image

技術系の調べ物をしていると英語のページに出くわすことがあります。今までは舌打ちしつつ離脱していたのですが、そんなことにも今日でサヨウナラです。翻訳だと意味分からない訳になることが多いんで、単語だけ手軽に教えてくれるツールないかなーと探したら見つけました。

マウスオーバーした英単語の意味をポップアップで表示してくれるFirefoxのアドオン「フェッチイミ」です。

個人的にかなり感動しました。分からない単語だけ即座に表示してくれるので原文のままでも結構読んでいけます。同時に単語学習も出来そうで一石二鳥!アルクの英和辞典からデータを持ってきているそうで、インターフェイス必要十分条件を満たしておりいい感じです。

f:id:in0in0:20100212023724p:image

「Get up」など二つの単語で一つの意味をなしている場合もちゃんと教えてくれます。これはかなり嬉しいですね。中学程度の熟語も相当忘れているので…w しかもスピーカーアイコンがついている単語は、ctrl+Fで発音までしてくれます。もちろんツールを使わない時はOFFにもできますので必要ないときにポップアップされる心配はありません。

いつかはこのツールともサヨウナラして、自力で読めるようになるよう頑張りますw

フェッチイミ 1.0 ダウンロード

2010-02-08

OOCSS(Object-Oriented CSS)の考え方

04:26

f:id:in0in0:20100209034242j:image

CSSでサイトを作るとき、ページをidで区切り、その中のclassに対してスタイルを指定するというやり方が一般的じゃないかなと思います。

#page-foo .box {margin:10px }
#page-baa .box {margin:20px }

しかし、いざあのページのこの部分をこのページに持ってきたい…となるとCSSファイルごと持ってこなければならない、移転先のclass名とバッティングしてしまうなど再利用が難しいという反面もあります。

今回仕事でサイトを構築するにあたり、再利用可能なモジュールで構成すればコーディングにかかる工数は減るのではと考えていたので(特にIEバグ関連…検証済みのモジュールで構成すれば確実!)再利用性とパフォーマンスを重視したフレームワークOOCSSについて調べてみました。

OOCSSの基本的な考え方

目的別にclassを複数指定する。

idに依存するロケーションで見た目を区切るのではなく、使われ方に応じてclass名をつけます。ソースで説明してもわかりにくいので例をあげます。ここでは「ダイニングテーブルに置かれたリボンのついた大きな箱」をマークアップするとします。

ロケーション別に分ける場合

<div id="#ダイニングテーブル">
<div class="リボンのついた大きな箱">…</div>
</div>

マークアップしていました。

しかしOOCSSでは

<div>
<div class="箱 大きい リボン">…</div>
</div>

と記述しています。ダイニングテーブルかち無視です。しかし、この箱はちゃぶ台の上にもそのまま置けるようになったわけですw

また、「シールの貼ってある小さな箱」を表現したいときも

<div>
<div class="箱 小さい シール">…</div>
</div>

となり、「.箱」は再利用できるわけです。

無駄に箱のスタイルをいくつも記述する必要がなくなりますね。同じように「大きい、小さい」も「箱」だけでなく「袋」なんかにも再利用できるわけです。良く考えてみれば箱の例のように、箱という機能はテーブルによって左右されるわけじゃないですもんね。どこにあっても箱は箱として使える!これ箱としての大前提!ってことですね。

構造とスキンを分離する

先程の例で言うと「箱」「大きい」が構造、「リボン」がスキンになります。実際にOOCSSのテンプレートを見てみると、以下の図のようになっています。

f:id:in0in0:20100209034241g:image

「.line」がページに横たわっている大枠、「.unit」「.size1of3」がカラムとその幅、「.mod」がモジュールといった構造を表わしています。「.grab」「.excerpt」「.sommers」はモジュールに当てられたスキンです。構造には marginやfloatなどの隣接要素に影響を与えるプロパティが、スキンにはbackground、borderなどの装飾系プロパティがシンプルに指定されています。

パフォーマンスが良い

ロケーションでぐちゃぐちゃ書かない分、CSS記述がシンプルになりパフォーマンスが良くなります。子孫セレクタはパフォーマンスに良くありません。(そんなに変わらんとの説ありですが…)

【before】
#page-hoge .hogebox . hogeclass  {・・・}
【after】
.hogeclass  {・・・}

実際に使ってみて

CSSでここまで構造について真剣に考えたことは、恥ずかしながらありませんでしたw

いままではある程度場当たり的に「ここはこのくらいのmarginでいいだろー」で済んでいた部分が、「ここは.lineだからmarginはいくつで…」とかっちり決めて置かないとすべてに影響してしまうのです。後々の再利用のことまで考えてコーディングしないといけないので、初期工数はかかりますが、再利用性は申し分ないです。

自分は、スキンのライブラリページをまずコーディングし、そこからコピペでパズルのようにページにはめこんでいく方法をとっています。検証済みの構造の上にスキンをかぶせていくだけなのでブラウザ間の表示崩れもありません。

ぶっちゃけテンプレートhtmlはパフォーマンスや汎用性を持たせるためか、ちょっと複雑な作りになっています。実際に使用するには厳しい部分も結構あると思います。(角丸のために空のbタグが大量にあったり…)なので、テンプレートを直接カスタマイズするよりは考え方を身につけて要件に合わせ自分で構築していった方がいいかもしれません。

どれだけ優れたフレームワークもあくまで道具でしかなく、自分の手になじませないといいものは作れないと思いました。

2010-01-31

Webディレクターズハック 〜社内TechTalks参加レポート〜

23:33

f:id:in0in0:20100131233247j:image

社内TechTalksに参加してきました。講師は近所のweb制作会社から@ichigamiさん。テーマは「Webディレクターズハック 〜実務に役立つWebディレクションのコツ〜」でした。

普段、社内のディレクターさんとしか接する機会がないので、社外のディレクターさんがどうやってるのか、お話が聞けたことは大きな利益となりました。その中で心に響いた言葉をいくつか。

決裁者と直接話せ

仕事をしていていちばん困ることはちゃぶ台返しです。

要件に対して最適な方向性をデザイナーとして提示して担当者と作り上げてきたのに、社長から「いやそういうことじゃない」と…今までの時間を返せーとなる訳です。そうなる前にあなたに決裁権があるかどうか、真の決裁者は誰なのかを明確にしなさいとのことでした。

当たり前のことなんですが、時間の関係で煩わしくて忘れがちなことだなーと思いました。

要件の本質を汲み取れ

ここの文字を赤くしてくれと言われて「はい、赤くしましたー」と言っちゃうデザイナーはポンコツだと。

「赤くするのは目立たせたいんですよね、それはなぜですか?」と問うこと。「そういうことであれば、赤くするんじゃなくて、こちらの方がもっと効果的ですよ。」と提案すること。

これに関しては自分は実践してるつもりなんですが、そのまんまやっちゃう人が意外に多い気がします。

クライアントのデザイン能力が自分より高いのならそれでいいんですが、それならデザイナーに発注しない訳で、期待以上の働きをしてくれるのを求められている以上、それには答えるのがデザイナーの義務です。対立することを恐れていては結局クライアントにも自分にとっても利益のないものが出来上がってしまいます。継続可能な関係を築くためにもいつでも最適な可能性を求めることが重要です。(ただし対立しすぎてデザイナーの我を押し通すのはもっといけないこと)

提案のその先を提案する

せっかく最適な方法を提案してそれが実装されたとしても、どれだけの効果があったのか証明できなければ自分の評価につながりません。デザイナーとして提案するならその効果を数値化して測定方法まで提示すべきとの事でした。

これはやっていなかったですね…。効果測定は個人的にやることはあっても相手にやり方まで伝えることは恥ずかしながらしてなかったです。問題意識を共有する意味でもやるべきだなと思いました。提案はしたけど、自分の思い込みでした〜じゃ笑い事じゃないですからねw

結果として

まずはクライアントコミュニケーションを積極的に取ること。自分との壁を取り払わなければどれだけ正しいことを言っていても受け入れてもらえません。土壌が整っていなければどれだけおいしい野菜の種を植えても育ちません。

次はクライアントを愛することかなと。くさいですが、やりたいと思ったことに善悪はありません。意図を正しく汲み取ってクライアントに最適な方法を提示すること。そのためにはゴールを明確にしてそこに向かって一緒にやって行こうという協力関係が必須になります。クライアントの利益は必ずこちらの利益になります。ゴールからずれているなら、Noという勇気も大切です。それがあなたの利益になるんですよと伝えることが大事!

共通のゴール、つまりはユーザーを見据えることをクライアントに伝えるのも大事だなと思います。ユーザーの存在しないWebサイトは存在しません。もしあったとしてもそれを作るために発注するクライアントはいないでしょう。デザイナーは最終的にユーザーの目に届くものを作成する訳ですから、責任を持たなければなりません。「ユーザーの利益になるもの→クライアントの利益になるもの→自分たちの利益になるもの」という関連性を俯瞰で見つめる能力が必要になります。

費用対効果を考えつつ、その中でユーザー、クライアント、そして自分が幸せになる方法を見つけることが本当のクリエイティブな活動なのではと感じた一夜でした。