This is my personal translation copy in Japanese of Can Designers and Engineers Use a Single Source of Truth? written by Marcin Treder from UXPin. I love the perspectives from both designers and engineers, and also believe the unified process will make things better XD
前回のプロジェクトはカオスでした。
プロジェクトはわたしが入念に準備した主要画面のプロトタイプから始めました。でも結局プロジェクト期間の数週間は、エンジニア、ステークホルダーとの調整に終わりました。みんな主張したがるし、みんな重箱の隅をつついてきます。UI のあちこちにたくさんの状態があります。その状態すべてをプロトタイプに落とすなんで無理に決まってるじゃないですか! その上プロマネはリリース日の確認で脅迫してくるんですよ? あ、わたしのプロトタイプはご希望通りの状態パターン 100 枚以上追加したせいで開くのが激重になっちゃいました。もう大変ですよ。それでも何とかこなしたところにエンジニアが機能実装を追えてレビューを上げてきたんです。もう頭に血がのぼっちゃいました。全然プロト通りにできてないんです! タイポグラフィ守ってないし、色付いてないんですよ!?
「なんでエンジニアってちゃんとできないの!?」そりゃ思っちゃいますよ。しょうがないからプロトから生成した CSS ソースコードを渡したんです。でもそしたら、仕様通り実装したし UI デザインにそのツール使うのやめてとか言うんですよ。そんなの同意できない訳です。デザイナー界隈みんなが使ってるツールですよ?
もう声をあげるしかない訳です。あなたの実装したカレンダー UI はプロトと全然違います。と。そしたらカレンダー UI は既にあるし、新しくつくると工数かかっちゃうよとか言うんです。急いでつくればバグる可能性もあるし、ユーザーにとっても良くないんじゃないとか。何言ってんのコイツ。わたしのプロトにはコイツの言ってるカレンダー UI のシンボルはありません。加えてわたしがサンプルとして GIF で送った高級感のあるこのアニメーションはシレっと実装しやがりませんでした。つくり直すには最低あと 2 週間は必要そうです。
わたしが間違ってるんでしょうか。業界標準のツールを使ってデザインしても期待通りの実装にはなりそうにありません。このやり方じゃだめなのかな。
前回のプロジェクトはカオスでした。
いつものことですがデザイナーは UI の仕様の細部を人任せです。それでいて、既存の hover と active のスタイルを当てると、プロトタイプと違うと言ってくるんです。3 時間かけたミーティングで説明されたプロトタイプと実装できるコードとの乖離には思考停止になってしまいました。デザインツールでつくる一枚絵はコードで正確に再現できないことを可能なかぎり説明しました。ブラウザとデザインツールは住む世界が全然違うんですよ。デザイナーは聞きませんけどね。いつだって「ピクセルパーフェクトデザイン」で攻撃してくるんです。こう言いたいですよ。ピクセルパーフェクトにデザインしたいなら CSS 書いて。と。でもこの議論は出尽してますしね。ユーザーに伝わるのは、そのパーフェクトなプロトタイプじゃなくて、エンジニアのつくったコード上の体験なんだって言ってやりたい。うまく行かないもんですね。
カレンダー UI の話が挙がったときは目が点になりました。エンジニアチームはアプリケーション全体の UI を考えて UI モジュール化の努力をしてきました。これはチーム全体の作業効率に大きく貢献しましたし、間違いなく UX を向上させました。よくテストされた UI はバグの少ないシステムをつくりました。デザイナーがこのことを理解できないのは私のせいじゃないと思う。デザイナーが聞いてくれたら、施策の度に既存の UI リニューアルするのは間違ってるし、エラーの原因だと伝えますよ。聞いてくれないだろうけども。
それから GIF で作成されたアニメーション。デザイナーは本当にコレをエンジニアに実装させる気なんでしょうか。たかが 5 秒かそこらのアニメーションを。こんなことに工数を割くのがおかしいだけじゃなく、プロジェクトの締め切りを考えなくていいんでしょうか。この派手なアニメーションのパフォーマンスは?
わたしが間違ってるんでしょうか。また毎日終電ですべての変更点を実装し切ることを考えると憂鬱です。期待通りの結果にはならないんでしょう。一筋縄でいかないものですね。このやり方じゃだめなのかな。
身に覚えがありますか。これが 2019 年のデジタルプロダクト開発の現状です。
デザイナーとエンジニアはお互いの考えやアイデアを互換性とシンクロニシティの欠如したツールで表現している。開発者は最終的なプラットフォーム特化のプロダクト技術で作業し、デザイナーは大抵ベクターイラストレーションツール (Sketch, Figma, XD...) でインターフェースの静的な表現をします。
これらのツールは違いこそあれ互換性をあまりありません:
- 異なるレンダリングエンジンを使い、例えばブラウザとベクターイラストレーションツールのように、フォントのレンダリング、色やグラデーションに解決できない違いが生まれます。
- 紙芝居として生成された GIF (e.g. Principle) からパフォーマンスを考慮した信頼性のあるアニメーションコードに変換する作業は苦痛です。
- 実装された UI とベクターデータには大きな隔りがあり、デザインシステムの実現を難しくし、一貫性の欠如とバグの多いコスパの悪いプロダクト体験につながります。
デザインツールの間違ったアウトプットは開発プロセスを間違ったインプットにつなげてしまいます。この結果、UX は間違ったアウトプットになります。インプットが正しくない限り、その結果が満足のいくものになることはありません。
一つの例を挙げます。ケーキを焼くのを想像して下さい。レシピ本の美味しそうなレモンケーキの写真を見ています。まず小麦粉を 1 カップ用意します。クリエイティビティが刺激されますね。ここでレシピ本のレモンケーキのページを切り取り、細かく刻みます。なるほど、小麦粉とレシピ本のレモンケーキ、同じ材料ですね。これは美味しいケーキになるはずです。そうでしょう? そんなことはありませんね。本物の材料を使わない限り、インプットが完全に間違っています。このケーキはあなたの大切な家族を病気にしてしまうでしょうね。不味いのは言うまでもなく。
デザイナーは UI のインプットに目を向けなければなりません。本当の「ケーキを焼く」のです。本当の材料、偽りの材料の写真ではなく。デザインツールは本当の材料をアウトプットできる必要があります。単なる画像でなく。
こうゆうことだと思います: デザイナーを責めるのも、エンジニアを責めるのも違います。デザインツールが間違っているんです。間違ったパラダイムに立ち往生させ、web 開発者たちに single source of truth となるデザインとエンジニアリングのプロセスを提供しないツールが。