エンジニアが仕事でデザインし始めて思ったこと
こちらは「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar」1日目の記事です。
昔「フロントエンドエンジニアがデザインできるようになると何が嬉しそうか」という記事を書きました。
これはフロントエンドエンジニアとして働きつつデザインを勉強していた時期のお話なのですが、私は最近業務でデザイン、つまりフロントエンドエンジニアとしてではなく一部デザイナーとしての仕事をするようになりました。
そして、実際に自分が"デザイン"という成果物に責任を持つと、また違った視点で課題が見えるようになりました。なので、この記事ではそんなエンジニアからデザイナーの視点で見るようになって気づいたこと・驚いたことを綴っていこうと思います。
デザインの管理が思ったより難しい
まず気づいたのがデザインファイルにも状態があるということです。
大まかに
- work in progress(デザイン作業中)
- ready to implement(実装していいよ！)
- implemented(実装され本番に反映された)
といったところでしょうか。
振り返ってみると自分が実装側の視点にいた時も「これもう実装しても大丈夫なんでしたっけ？」「今回のこれのデザインってどこです？」というコミュニケーションをよく取っていた気がします。コミュニケーションでカバーでも大事ですが、なるべく仕組みで解決したいものです。
というところで最初一ファイル一ページのみで進んで「あ、これはよろしくないな」とすぐに分かったので次のようなプロセスに変えて…みようと思います！
というのもまだ直近諸事情でデザインタスクがなく未実践です、なので妄想ぐらいの感覚でみてください。
あと「こうするとよかったよ！」という意見などをいただけると大変嬉しいです。
ファイルを WIP, Ready to develop, Main に分ける
先ほど書いた状態毎にファイルを分けるようにするといいのでは、と考えています。
開発はチケットベースで Trello を使っているので、それと紐づいている方が開発時に見つけやすいため WIP と Ready to develop ファイル内のページが Trello のチケットと 1:1 で紐づくように作ります。
この辺りは Figma Flow というのも参考にしました。
デザインをマスターとは捉えない
ちょっと迷っているのが Main の部分です。一応全体感持ってデザインを眺めたいこともあるかなぁと思って実装されたデザインはマージするようにはしているのですが、いささか作業として不毛に感じることもあります。
デザインを作る目的をあくまで "実装者に対して UI デザインの意図を伝えること" 捉えると前述のチケットベースでのデザインのみで十分なはずで、マスターとなるファイルをわざわざメンテするのは何も価値を生み出さないタスクとなるはずです。
なので、今のところ具体の How には落とし込めていないのですが、以下の記事で紹介されているようなやり方や、UXPin Merge を始めとする "実装に反映されたコードをデザインに使う技術" には期待しています。
コードをデザインに使えれば、"同期" を気にしなくて良くなりつつ、デザインのもう一つの目的であるプロトタイピング・価値検証も高速に行うことができるからです。
というのを期待しつつも今作っているのがネイティブアプリというのもあり全然できてないので将来的に試していきたいなぁと妄想しているところです。
実装されたもののデザイン品質を上げる仕組み
フロントエンドエンジニア目線だと「デザイン通りに実装している」と思って作っているので気づかなかったのですが、エンジニアが実装したものは結構デザインと違います。(これは実装者のデザイン意識にもよる気はしますが)
また、実機で動くものを見ながら修正したくなることも多々あります。このため、デザインを作るまでがデザイナーの業務ではなく、実装されたものを元に更にブラッシュアップするまでをデザイナーの責任と捉えるとこの辺りの仕組みとして工夫できることは色々あるなと思いました。
自分で修正する
ぶっちゃけこれが一番楽です。私はエンジニアでもあるので特に苦もなく自分で修正 PR を作ってレビューに出すというのができるので、これが一番楽だなと思いました。というか一旦はこのスタンスで、今は Flutter Flow という少しクセのあるツールで開発しているので、それで実装しながら調整していきました。
ペア修正する
上記が短期の作業目線では一番楽なのですが、長期で見るとペアで修正して「どこが悪かったのか」をフィードバックをするのが大事だと思います。
自分も実装者の時はペア修正をしてデザイナーから色々教えてもらいました。
- 余白の値をどんなロジックで決めているか
- レスポンシブでは余白の値は変えずにコンテンツを変えるのが基本ルール
などなど様々なフィードバックをもらいました。そうすると次から実装視点で同じ過ちを犯さなくなるため、長期的にはチームの生産性が上がります。
なので短期的になんとかしなければいけない時は自分でやるのがいいと思いますが、それ以外の場合は「デザイナーがフロントエンドエンジニアを育てる」という考え方もあっていいのかなと思いました。
デザインのシステム化、思ったより難しい
デザインのシステム化、していきたいんですが、思ったより ad hoc なデザインをしてしまいたくなるシーンが多々あります。
あるページを新規でデザインしようとしている時に、既存のコンポーネントではいい感じの体験をデザインできそうにない時は往々にしてあります。プロダクトが成長途中の時はこの「システム化していかなければ後々デザイン負債になる…」という気持ちと「かといって今までのものに縛られて使いづらい UI を提供することはできない」という気持ちが常にぶつかり合っていくものなのだろうなと思いました。
コードを書いていく時もある程度書いてからリファクタリングしていくものだと思いますが、デザインも同じだと思います。
(この辺リファクタリング for デザインみたいなのまとめてみても面白そうなので知見が溜まったら別途書いてみようかも)
また、一つのコンポーネントで複数の文脈に耐えうるコンポーネントを設計する考え方がいるなと感じましたが、この設計は、今までエンジニア目線では基本的にデザインで既にコンポーネントとして設計する"元"のようなものがあったため、もっと根っこから"コンポーネントとは"を考える必要があるなという気づきも得ました。
これはこれで自分のフロントエンドに関する考え方をアップデートできそうな面白そうな問いなので、しっかり向き合っていきたいなと思います。
プラットフォームの制約を理解している必要がある
これは私が業務でデザインしたものが FlutterFlow という少し特殊なツールで実装されるから、ということもあったのですが、そのプラットフォーム独自の制約というのを熟知していないと正に絵に描いた餅になるなと実感しました。
例えば、自分が作ったデザインを FlutterFlow で実装しようとして具体的に遭遇した課題は次のようなことです。
- FlutterFlow が用意している Widget から外れた AppBar や BottomNavigation のデザインをすると、プリミティブな Widget を組み合わせて自作せねばならず無駄に工数がかかる
- 用意されている Widget のアイコンには Material Icon か Font Awesome のアイコンしか使えない
- FlutterFlow の作り方的に同一ページ内で状態持って条件分岐よりページを分けてしまう方が簡単に作れたりする
こういった特性を知っているだけで「そもそも作れない」というのも防げますし、実装にかかる時間を減らすことができます。
よくインターネッツで定期的に紛糾する話題として「デザイナーはコードすべきか」というものがありますが、ガッツリ実装できるようになれとは思いませんが、こういった制約を知っておく努力は必要だな、と感じました。
デザイン業務への理解が高まった
まあ自分でやっているので当たり前なんですが、デザイナーがデザインという成果物を生み出す時にどんなインプットが必要で、どういうプロセスでアウトプットをしているのかの解像度が高まりました。
例えば、正直な話 UX デザインと UI デザインの業務の違いをイマイチ分かっていなかったのですが、今自分は PdM な人が UX のデザインをワイヤーフレームに落とし込む -> それを元に私が UI をデザインする、というプロセスで仕事しています。
こうすると UX デザインはユーザリサーチやビジネス要求を元にユーザがどんな行動をしてどんな価値を得るかの設計をし、それを何らかの形で図や言葉などでアウトプットすること、UI デザインはその定義された体験を UI としてどうやって実現するかを何らかの形(多くは Figma などでのデザイン)で表現すること、とより具体的な理解に繋がりました。
自分はデザインのプロセスをうまいことハックして「より高品質なプロダクトをより速く届ける」プロセスを作りたいと考えているので、この業務理解の深さに繋がったのはいい収穫だったと感じています。
おわりに
以上、難しい難しいばかり言ってますが、デザイナーとして働いてみての気づきを書いてみました。
驚いたのが視点を変えるだけでこれらの課題に気づけたことです。エンジニアとして働いている時もデザインのことは自分なりに練習・勉強していたんですが、やはり成果物に責任を持つと全然世界が違って見えるんだなということも学べました。
(記事の主題とはそれますが、他の職種の業務理解をしたくなったらユーザテストだけでなく実際に自分が責任を持ってやってみるというのがいいのかなと思いました。)
あと課題ばかりあげてきましたが、純粋に新しいことをやるのは楽しかったり、今まで人から渡されるだけだったデザインを自分でしっかり説明できるように作るのは楽しいですね。
それでは、お読みいただきありがとうございました！👋
この記事が気に入ったらサポートをしてみませんか？