フロントエンドエンジニア、デザイナーと協働する
きょんしーです🐧
普段は主にフロントエンドエンジニア(FEE)として働いています。FEEとしてデザイナーと一緒に仕事をする中で心がけていること・大事だと思うことを書かせていただきました。
どんなプロダクト開発に関わっているのか
僕自身がどのようなプロダクトに関わってるかの情報があった方が本題の理解につながるかもしれないので少しだけ書かせていただきます。
HiTTOという社内向けAIチャットボットサービスを提供してる会社(社名もHiTTO)に所属しています。とても分かりやすい動画があるので気になった方はどうぞ。
HiTTOの紹介動画
チャットボットのサービスということもあり、プロダクト自体は世界観を大事にしつつボットのキャラクターを育てる感覚を持ってもらうために親近感であったり使いやすさを意識しています。
僕自身はマークアップはもちろん、複雑なUIの実装やテスト環境整えたり、なんか色々したりフロント周りの便利屋さん的な立ち位置で活動してます。
なぜ記事を書こうと思ったか
ブラウザ自体の高速化やHTMLやCSSの仕様も更新されていく中で表現できる幅が増えました。(主な要因はPCやスマホの性能向上だとは思いますが...)
それに伴いリッチなUIを作りたいという人類の欲求（推定）が高まり、デザインとエンジニアリングそれぞれより高度な人材が必要になります。
そうするとデザインとエンジニアリングが分断されることが起きるのですが、最終的には1つのプロダクトという形でユーザーに届くものを作るのでデザイン・エンジニアリング両者のコミュニケーションは必要になります。
さぁここで領土争いが起きます。（嘘です、すみません🙇♂️）
ここまで過激でなくとも 「エンジニアが意図を汲んでくれてない」「デザイナーがこのケース想定してない」といったことは少なからず経験があると思います。
もちろんこういう事態は好ましくないのですが、ある程度は受け入れる必要もあると思います。ただ全てをしょうがないと片付けると意味がないので少しずつ解決していこうという話をします。
協働するには？
細かく分類できるものではないかもしれませんが、僕自身は以下の3点が大事なことかなと思っています。
- お互いの知識の伝達
- 低忠実度の(ローファイ・)プロトタイプを一緒に作る
- 双方のレビュー
お互いの知識の伝達
デザイナー起点のコミュニケーション
デザイナーならFigmaなどのプロトタイピングツールを使う技術はFEEより優れていると思います。
普段UIデザインをする中で「何に注意して作成しているのか」「何がプロトタイピングツールで実現できて何が実現できないのか」といったことは、コミュニケーションをしないとFEEには分かリませんでした。
2つ挙げましたがあくまで例です。
「何に注意して作成しているか」の会話でもしコンポーネント間のmarginに注意が向いていなかったとなれば、FEEではこういうルールに沿いたいから次から意識していこう。といった会話につなげることができます。
「何がプロトタイピングツールで実現できて何が実現できないのか」といった会話をすることで、プロトタイピングツールで実現できないUIに関しては他のサービスのスクショを共有することやコメントに残すとFEEの頭の中に実装イメージが浮かぶのではないでしょうか。
FEE起点のコミュニケーション
FEEなら実際にコードでコンポーネントを作っていく技術はデザイナーより優れていると思います。
Atomic Design の atoms/molecules を作る時のprops設計をFigmaのVariantsに反映させることもできるでしょう。（完全に同じにしなくても良いと思います）
また、Chakra UIやMUIなど様々なUIライブラリが存在していたり、各所でデザインシステムが作られたテックブログが公開されていたりと、業務に直接関係なかったとしてもフロントエンド関連の情報は頭に入ってるのではないでしょうか。
そういった情報をデザイナーに伝えてみると、「何を持って一貫性としているのか」「こういうことを伝えたい時はこのUIを選択すると良い」 といったことが分かると思います。
Chakra UI Figma Kit というものも作られているのでSlack等でシェアしてみてはいかがでしょうか。
低忠実度の(ローファイ・)プロトタイプを一緒に作る
UIの修正の規模によっては高忠実度の(ハイファイ・)プロトタイプをいきなり作り始めることもあると思いますが、FEEと一緒にローファイ・プロトタイプを作るのが良いのではないかと思っています。
これは2つの理由があって、
- レビューでの手戻りのコスト
- 複数人で一緒にデザインを作り上げていくこと
の観点からです。
レビューでの手戻りに関してはお分かりかもしれませんが、「時間をかけてハイファイ・プロトタイプを作成したのにやり直しになった...」ということを減らすためです。
ローファイ・プロトタイプを作ってレビューをすることで素早くPOないしはFEEにレビューしてもらえるので手戻りのコストを小さくすることができます。
2つ目の複数人で一緒にデザインを作り上げていくことですが、最終的にプロダクトへの実装という観点からプロトタイプを作成しているのでFEEの知見や意見は大事になると思っています。
弊社ではコラボレーティブデザイン[1]を用い、手書きのデザインをそれぞれが持ち寄って対話し、最終的に参加者で1つのローファイ・プロトタイプを作っています。
実際にやってみると分かるのですが、同じ手書きのデザインを持ってくることはほとんどないです。だからこそ面白いのですが、各人がどういう観点からそのUIを捉えているのかが見えてきます。
誰でも参加でき、手書きのデザインなので時間をかけ過ぎることなく作成でき、そしてみんなでその問題に取り組むということは、1人では気づけなかったアイデアに気づけるだけでなく参加者のプロダクトへの関心を高める効果があります。
双方のレビュー
FEEが作成したコンポーネントをデザイナーに、デザイナーが作成したプロトタイプをFEEにレビューしてもらうのは大事だなと考えています。
FE観点では、Storybookを用いれば実際にアプリケーションに組み込む前にコンポーネントのみを作成することが出来るため、Netlifyなどを用いてpull-req単位でホスティングすればデザイナーにレビューしてもらうことが出来ます。
そうすることで組み込む前にプロトタイプとの違いに気づけるためQAでの指摘を減らすことが出来ました。
コラボレーティブデザインの箇所でも少し触れましたが、FEEにもプロトタイプのレビューをしてもらった方が良いと思っています。
実装に取りかかり始めてからルールに沿ってないことに気づいたり、複雑なUIになってたということを防ぐためです。もちろん、ローファイ・プロトタイプの作成を一緒に取り掛かっていればレビューのコストも下がるでしょうし、UI修正の規模が大きければ細かくレビューすることも大事だと思います。
レビュー ≒ 批評に関するおすすめの書籍を載せておきます。
どのように批評すればより良いプロダクトを作っていけるのかの観点で語られている書籍になっています。僕自身はまだ読んでる途中ですが、出来てないことを気付かされるきっかけを作ってくれています。
Discussion