実装を引き受ける前に詰めておくべきWebフロントエンドの想定漏れチェックシート - Qiita
リキッドレイアウトのように幅が常に変動するレイアウトのデザインは、動かないカンプからは実際の挙動が読み取れず、デザイナーの意図が汲み取りきれないことが多い。また、複雑化するアニメーションの実装においても、カンプだけではコミュニケーションに不備が生まれてしまう。ほかにも、CMSを使った案件ではデザインカンプと実際のデータの間に齟齬がある可能性もある。 実装効率を高めてスケジュール通りに仕事を終わらせるには、とにかく事前に仕様を固めることが大事だ。ワイヤーフレームやデザインの途中の段階からなるべくデザイナーとコミュニケーションを重ね、想定外の要件が発生しないように気をつけるべきだろう。 この記事では、デザイナーやフロントエンドエンジニアが見落としがちなWebフロントエンドの課題について列挙していく。 ホバー表現を後から指示される ツッコミ 後から仕様追加されると困るから先に決めて! メモ 最近
デザイナーはワイヤーの通りにデザインすべきかという議論は虚しいのでやめよう - デザイナーのイラストノート
先日、7つの実例で学ぶ「ワイヤーフレーム通り」のデザインから脱却する具体的な方法という記事が話題になりました。これに端を発して「そもそもデザイナーはワイヤーどおりデザインを作るべきか」という話題があちこちで見かけられました。（件の記事は、デザイナーを経験されたアートディレクターならではの「デザイナーがワイヤーの枠を出られない理由」が書かれていてとてもいい記事です、ぜひご一読を。） ワイヤーどおりに作るべき？ 言うまでもなく、みなさんご存知の通り、「案件による」。以上です。 しかし、実際ディレクターのお悩みとして「デザイナーから上がってきたものがワイヤーの通りだった」という声はあります。しかしこれは結局のところ と思いますがいかがでしょうか。 と言うのにも一応理由があって「ディレクターにワイヤーの通りだと怒られた」という話はあまり聞かないからです。デザイナー側はそのことをあまり問題視していな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
