エンジニアと仕事するときにデザイナーができること
エンジニアの視点を学ぶデザイナーとエンジニアは仕事の仕方も考え方も異なります。しかし、良い製品をつくるためにはお互いの協力が欠かせません。考え方が違うからといってそのままにしておくと、品質の低下に繋がることがあります。 「デザイナーはユーザー（人）の声や行動に耳を傾けるべき」「彼らのニーズに合わせた提案や設計をすべき」といった論調を見かけることがありますが、これはユーザーだけでなく、一緒に仕事するエンジニアにも適応できます。すぐ側にいるエンジニアを考慮した提案ができないのであれば、ユーザー相手はもっと難しいと思います。 今でも仕事でビジュアルデザインを担当することがありますが、エンジニアと仕事をする際に以下の 6 点に気をつけています。 1. どういうタイプのエンジニアか知るすべてのエンジニアがデザインに興味があるとは限りません。中には仕様を指示してもらえればそれで良いといった方もいます。
コンテンツやデザインに欠かせない価値観を共有するプロセス
利用者中心とは言いますが 自分たちが作りたいものを作るのは身勝手な行動のように見えますが、「自分たち」という価値（アイデンティティ）が確立されているかされていないかは大きな差があります。価値がないまま、「利用者のため」という考えだけ一人歩きしてしまうと、極度な A/B テストの実践など、数字が高いほうを選択するという製品開発になる可能性があります。 利用者中心のデザインは必要です。しかし、それは土台になる【価値観＝ビジョン】があるから成り立つものであり、いきなり利用者中心のデザインプロセスを実践しても意味のないことだと考えています。スタートアップ向けの講座で ビジョンの共有が重要だと話したのもそのためです。プロジェクトを始める際は、必ずといっていいほど「我々は何者か」という部分を振り返るようにしています。 付箋には「気分が良い」「落ち着く」といった、感情的なフレーズが含まれることがあります
コンテンツから先に考えなければデザインすらできない理由 : could
ワイヤーフレームの間違った使い方 たまにリニューアル案件をいただくときがありますが、見た目より先にコンテンツを整理しましょう、一緒に作っていきましょうと説得するようにしています。このサイトでも様々な角度からコンテンツの重要性を語ってきましたが、最もシンプルな方法は「UX を考えていきましょう」「モバイルファーストで戦略を練っていきましょう」といった専門性の高い言葉を使うのではなく、今までのやり方ではうまくいかないということを分かりやすく説明することです。 従来の Web サイト制作でよくあったのが、まずワイヤーフレームをつくって情報の大まかな構成を設計するというやり方。ワイヤーフレームを作ることは間違っていませんが、コンテンツを作る前に始めてしまうと、あとで大きなギャップを埋める作業が発生することがあります。コンテンツなしで構成を作り始めると、例えば以下のような状況に陥ります。 文字が多過
今のデザインに必要とされるコントロール
本当にコントロールできないのか WD101シリーズの最初に、Webデザインは見た目のコントロールができないという話をしました。スクリーンの大きさが多種多様なだけでなく、利用者が見た目や操作性を自由に変えることができる Web。DTPのような感覚でサイトをデザインしても、誰かの Web アクセスの利便性を損なうと指摘しました。 デザイナーはある種、混沌とした状態から秩序を生み出す能力をもっていると思います。バラバラになった情報を整理して一貫性のあるメッセージを伝えたり、混雑した Web の世界に明確な道筋を示す仕事をしています。秩序を作り出すということは、ある程度のコントロールはなくてはならないわけです。 コントロールすることがデザイナーの仕事であるとすれば、『コントロールができない Web』との相性がよくないように見えますし、デザイナーにとって非常に仕事が難しい環境のようにみえます。しかし
道具の選び方、関わり方を考えるためのヒント
間違ったツールの選び方 ペーパープロトタイプは、紙に書き込むというアナログなアプローチであることから、作るための敷居が低いだけでなく、アウトプットも早く改善がしやすいです。メリットが多いペーパープロトタイプですが、時間の無駄という意見もあります。紙で作られていることから再現性が低く、的確なフィードバックを利用者から得るには難しいからです。 それでは、ペーパープロトタイプが使えないのかといえば、こたえは「No」になります。こうした「○○は使えるのか？」という疑問は制作の方からよく聞かれる質問ですが、回答に困ることがあります。ペーパープロトタイプだけではありませんが、手法や技術そのもので使えるかどうかの判断はできません。採用する前に以下の 4 点を考慮して選ばないと上手くいかないですし、手法や技術へ責任転換をしてしまう恐れがあります。 誰とつくるのか 誰がその手法を使うことになるのか。自分ひと
Fireworksの今後に関するまとめと、ワークフローの考察 (with tweets) · yhassy · Storify
Fireworksの今後に関するまとめと、ワークフローの考察Twitterで発信していたものをまとめました。関連する情報も付いています。
レスポンシブにデザインするために克服すること : could
画像の課題は解決されつつある 先日 Web担当者 Forum で、レスポンシブ・ウェブデザインの功罪とモバイルファースト という記事が掲載されました。Media Queries を活用するなど実装のための概要を説明した上で、非表示だけど読み込まれているから膨大な画像素材が存在する PC サイトのレスポンシブデザインは不適切であると書かれています。 現存の Web サイトを Media Queries だけでレスポンシブ・ウェブデザインをするのであれば、Web担当者 Forum での指摘は間違っていませんが、実際のところレスポンシブにデザインすることは、Media Queries による対応だけではありません。例えば、画像の表示のさせ方を工夫すれば、記事で指摘している課題はある程度解決できます。Web担の記事からもリンクされている CSS Rador でも取り上げられている解決策もありますが
カンプがなくなったときのデザイナーの役割
手段を再想像する 昨年末に開催された CSS Nite Shift 5 で「Reimagination（再想像する） 」の話をしました。人とコンピュータの関わり方が行動や価値観を再定義しているのと同じように、Webサイト制作にしても同様のことがいえます。今までの当たり前を疑い、未来に柔軟に対応できるワークフローが必要とされています。 例えば従来必須だと言われていたワイヤーフレームも考慮対象です。少し前に ASCII へ「柔軟性あるデザインプロセスへ移行するためのヒント」という記事を寄稿しました。ワイヤーフレームが果たそうとしているコミュニケーションの目的は間違っていませんが、つくるためのツールや手法に問題があるのではないかという疑問を投げかけた記事。絶対いると思い込んでいるものも、今の時代にマッチしなくなってきているものは少なくありません。 また、Photoshop や Fireworks
ツールなんてどれでも良いですよ
以前から ピクセルパーフェクトなカンプを作ることに意味はないと話してきました。Photoshop や Fireworks のような絵描きツールは、様々は誤解を引き起しますし、ピクセルパーフェクトな世界を作り上げることは、可変で自由自在に変化する Web の世界では不可能に近いです。開発の初期段階でカンプと呼ばれる架空の完成図を作り込むことのリスクは実は大きかったりします。 しかし、それが「Photoshop / Fireworksを使うな」という意味ではありません。 絵描きツールは、ビジュアル面での試行錯誤するときに大変効果的です。指を動かしただけで、すぐに結果が出てくるというプロセスは、コーディングをしてから見るというプロセスに比べると、直感やクリエイティブを刺激し、模索するという気持ちを促進させます。 たったひとつの最強ツールはない ツールの話で不毛だと感じるのが、「俺のツールは凄くて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
電子書籍「エスクペリエンス ポイント」のサイトができるまで (with images, tweets) · yhassy · Storify