DIST18参加メモ sketch時代のWebデザインワークフロー

  • 10 Nov 2017

デザインの勉強会ではそれなりに大きいDISTに参加して来ました。覚書としてメモを残しておきます。

2018年に向けたツールの選び方

長谷川恭久さん

今は、スケッチ戦国時代、デザインツール戦争。

なぜこれだけデザインツールが出て来ているか。それはデザインプロセスが破綻しているから。

通常語られるプロセスは非常に綺麗になっているが、結構溝があるし、途中段階でデザイナーが自身で考えながら埋めていかなければならない。一方で、適当なカンプなどで開発とのズレが生じることもある。

これをどうやって繋げていくか。溝の大きさや、物理的な距離によってこの溝埋めの作業が増える。また外的要因の変化(端末の多様化など)でますますこの溝埋め作業に時間を取られる。

今必要とされているデザインツールとは、この溝を埋めることができること。またスムーズにコミュニケーションができるようになること。表現を高めるツールと連携を高めるツールでわけるなら、現在は連携を高めるツールが必要に。

これつまり制作物の複雑化のためなのかな。でも一方で昔からflashのようにアニメーションを備えた複雑なインタラクションの制作物もあるよね。

ツールの選定で考えるベキことは、連携面と自身に求められている要件。作るものによってツールの合う合わないもある。あとはエンジニアとの関係や距離感。

まぁ、スマホ出た時からこれどうするの、制作者死ぬよねって話はあったよね。

コードを書く人の思考を考えるなら自分もコード書けばいいって思うな。

エンジニアが適当に選ぶのも一方で罪深い。

  • ルールを作ってデザインの品質を担保しよう。
  • プロセスを極力オープンにして逐一見せていくことで周りの協力や理解を得よう。
  • コード思考を実践するうえでSketchはよくできている

Sketchが生きるところ

  • 表現力よりも設計力が求められるところ
  • エンジニアとの連携を強化したい
  • 外部ツールと自由に連携したい
  • デザインを運用していきたい

AdobeXDでいいんじゃないかな、とは思う。ツール自体あまり分散したくないし、そもそもプラットフォームとしてのAdobeはすでに確固たる地位を持っているので長期的にみて外しがない。唯一、組織的な強さで対抗馬になるのはGoogle。ただ彼らがAdobeを凌ぐほどにそこにリソース投下するとは、事業コンセプトやその優先順位を踏まえても到底思えない。

figma, principle

あのコーポレートサイトができるまで

こもりまさあきさん

最近はあまり仕事したくなく、ペースダウン中。Webサービスの設計、コーポレートなど。ワークフローの改善なども。直受け案件が多い。

レスポンシブあるある、について。最近はまだPCのみデザインされるデザイナーさんが多い。スマホやタブレットのカンプがない、とか。写真、フォントサイズなど考えることが盛りだくさんにも関わらず、よきにはからえ、となることが多い。

スマホに対応するときのチェックリストがあればいいかって言えば、そうでもないんですよねぇ。チェックリストでやっていくのは辛い。やはりツールの方でサポートしてくれるのが有難い。ただ、こうして複雑化すると極力要素は減らして検討事項を極少化したくなる。フラットデザインのいいところはルールを制定しているところもあるが、要素を不必要に増やせない思想がその背景にあるかと思う。

francfrancさんの場合。 ラフではPCとSPの画面を用意した。並べて作らないとわからないよね。

旧来型のツールでできないことは、可変幅のシミュレーション。カンプのやりとりは2回程度しかやっておらずあとはお任せされる。実装の担当者の人にはざっくりとしたスタイル定義しか渡していない。

Sketchはその時々で使い方を変えられる。そのときにやりたいようにコントロールできる。実務担当者がSketchを利用したことあるかどうかは配慮する。結局、実装社に渡したのはグレーワイヤーフレーム。文字のスタイルは渡してある。かンプで渡すというよりもルールを渡すという感じ。このあたりは違和感ないな。

もっと細かいコントロールするなら、AutoLayoutなどのツールがある。コマンドラインツールなどもある。クライアントや外部スタッフとやりとりするならSketchCloudなど。

デザインを渡す時代から、ルールを渡す時代になったんだなぁ。

シンボルの効率的な作成・運用法とエンジニア連携についての取り組み

吉竹遼さん

フェンリル!!!その名前聞くだけでテンション上がる。

制作のプロセスをきちんと可視化することが大事だよね。こういうことが意外にできてないので反省せねばな。

ボリュームや概念に応じて、階層構造を作って管理する、抽象度の高いものはレベルが高い。そのレベルの高いものの組み合わせはレベルを下げていく。それ以上分解できない要素はレベル0。

途中途中で定義づけなど見直し。リファクタリング。

DSMそのもを変えていく。本来はエンジニアとどう向き合うか、というスコープだけでなくチームとどう向き合うか、である。