知っていて損はないディレクターとしての「話し方」基本ルール
社会人になった時点で、ある程度の敬語やら丁寧語やらの講習・勉強は済ましているのがほとんどだと思いますが、「話し方」「伝え方」まではあまり意識して使えていない方が多いように感じます。（過去の自分も含めて） なので今回はWebディレクターという職域を任された場合に発生する口頭でのコミュニケーションにおいて、何をどうすると内容が人に伝わりやすいのか？をまとめてみました。 どういった時に口頭でのコミュニケーションが必要になるのか Webディレクターとして仕事をする上で、「口で言って物事を伝える」という場は実はそんなに多くはありません。が、その少ない機会というのがすごく重要な場合ばかりなので、どんな場所で必要になるのか？をまずは書いておきます。 代表的なパターン（対外部） ・クライアントに対し提案、交渉を行う時 ・要望やクレームに対する回答を返す場合 ・成果など、何かを報告する時 代表的なパターン（
ディレクターが指摘すべきデザインの注意ポイント10個
ずいぶん久しぶりの投稿になってしまいました。申し訳ない。 今回はタイトルの通り、ワイヤー上がった！デザイン依頼した！で上がってきたデザイン案（もしくはモックアップ）を見て、その段階でディレクターが何を「確認」すればいいのか？という内容についてです。 もちろん経験を積む。もしくは自分自身でデザイナーも経験するなどの機会に恵まれれば大丈夫なんですが、僕みたいに「いきなりWebディレクターという肩書きを与えられてしまった人」は、デザインの何を確認すれば良いのか分からなくなってしまうケースも多いんじゃないかな？と思って書いてみました。 実際にはマークアップ後まで影響してくるので、もっともっと項目は伸びると思うのですが、ひとまず僕が注意して見ているポイントを10個ピックしています。 色数を使いすぎていないか あれもこれも！と欲張りすぎて、結局なにが「一番強調したいのか」が分からなくなってしまっている
Webサイト上で使いやすい原稿の書き方（非ライターさん用）
結構前の記事なのですが、驚くほど違う→あなたの文章を最適化するたった４つのルールという記事を読んで、「なるほどー」と思いつつ、なかなか思い通りに行かずに悶々としているディレクターナカムラです。 今回はこの記事に触発される形で「そもそも文章書くの自体が苦手！」だった僕が、現在なんとかかんとか現在Webサイトの原稿などを書いたりしている手順をさらしてみます。 細かい原稿の書き方ルールと言うより、「書く前の情報整理術」みたいな感じです。 人によって書き方は色々だと思うので、あくまでナカムラはこうやってるよ。という情報としてお読みいただければと思います。 まず、自分が誰なのか？と決める 書き手のスタンスって奴です。 自分は一体この原稿を書く上でどんな立場から文書を書くのか？ わかりやすく言ってしまうと、誰の代わりに書いてるの？ という事です。 自社サイトなどが対象で、自分自身の名前が使えるのであれ
クライアントに「とりあえず作ってみて。みてみないとわからないから」と言われた時のディレクターの返し方
先日、「とりあえず作ってみて。みてみないとわからないから」というつぶやきがTwitter上で話題になり、その一連の流れをまとめたtogetter上の記事が物議を醸した。 という事がありました。 「とりあえず作ってみて。みてみないとわからないから」つぶやきまとめ」 んで、この記事に対して僕がディレクターとして思ったことがあったり無かったりしましたので、ちょいと書いてみようかと思います。 ナカムラが思ったこと。 これってディレクターが前段階でもの申してやればなんとでもなることじゃね？ まず、クライアントの意見は全部入れるとだいたい見当違いのものができあがることが多いです。もうね、これは仕方ないと思う。だって企業の担当者はWEBの専門家では無い場合がほとんどなんだもの。 だから、どんなものができるのかイメージできない。 結果として「とりあえず作って見せてよ。お金出してるでしょ？」というスタンスに
クライアントとの更新やりとりを10倍楽にする（かもしれない）テンプレートまとめ
ずいぶん久しぶりの更新になりました。 しかも一部の方に予告していた内容と全然違う内容です。ごめんなさい。 まあ、ちょっと忙しくて何書こうとしてたんだか忘れた感じです。 さて、今回は表題にもあるとおりクライアントとの更新やりとりを簡単にしよう！っていう意図から、僕がディレクションの現場で使ってきたテンプレートやら何やらを公開しながら後悔するっていうネタになります。 そもそもなんで更新依頼処理ってあんなに面倒なんだろう？ 案件やサイトの構造、クライアントの理解度とかこだわり具合によってかなり変化するとは思いますが、大体以下の流れを辿ってサイトの更新依頼から公開となります。 更新時の依頼→制作フロー ・まずは何の話なのかを解読 ・更新なのか新設なのかを解読 ・何がやりたいのか？またそれはなぜなのか？を聞き取って ・どのくらいの期間であげればいいか確認 ・要素を洗い出してざっくりワイヤー作って ・
やたらと重い「Firefox」を、馬鹿みたいに高速化する方法まとめ。
結構Firefoxが好きなので、ちょこちょこ改造していたんですが、管理するPCごとに新しいこと試したり前やってたことをやめたりしてるうちに何が何だかわからなくなってきてしまったので、そろそろまとめようかなー？ってことでまとめてみました。 ちなみに、ここに書いてある改造は完全に自宅マシン用です。 会社のマシンでここまでやると・・・ちょっと動作とかアドオンの不都合とか色々検証してないことも多いので、出来るだけご自身の責任でお願いいたします。 とりあえず手始めに入れるアドオン SQLiteOptimizerアドオンを入れる Firefoxの重たくなる一番の原因となる、SQLiteの計量最適化を図ってくれるアドオン。 Faster Fox Liteアドオンを入れる 設定は「ターボチャージャー」に。 かつ、アドバンス設定で「Disable IPv6 DNS lookup」にチェック。 MemoryF
プロジェクトの開始までにWebディレクターが用意するものとこと13個まとめ
さて、発注が決まった。クライアントからの要望はまだフワっとしてるけど、納期は何となーく見えている。（もしくは納期だけがカッチカチに決まっている）。 この状態からプロジェクトの本格スタートまでにディレクターが用意するべきものは何があるんだろう？今日はそのへんをまとめてみます。 ゴールまでのざっくりストーリー たとえばコーヒーのポータルサイトだったとして「コーヒーに関する情報なら何でもあります！」って言っても何も始まらない。そこにあるストーリーを多少適当でもいいのでドラマチックに盛り上げてしまいます。 1：店主はかつて2店舗のカフェを切りもりした実店舗の経営者 2：学生の頃からカフェが好きで、なんとか自分の理想のカフェを作りたかった 3：それは、カフェの持つ独特の雰囲気とコーヒーの香りが大好きだったから 4：だから、自慢のカフェの雰囲気を全国どこにいても感じてもらえるサイトを作りたかった。とか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webディレクターズマニュアル