
課題解決の秘訣は、「寄り添い」と「積み重ね」事業課題を解決するために、デザイナーとしてできること
こんにちは、プロダクトデザイナー7年目の熊谷慶人です。現在、OB/OG訪問ネットワーク「ビズリーチ・キャンパス」というサービスを担当しています。 ひとことにプロダクトデザイナーと言っても活躍の場は様々だと思います。私は事 […]
10月18日(水)に、株式会社ベーシックで行われた「Nextstage Nite vol.2 – 実践されるデザインガイドライン –」に、HRテック(HR × Technology)で採用を強くする「HRMOS(ハーモス)採用」(旧:HRMOS採用管理)のフロントエンドエンジニアの浅井が登壇しました!
浅井 雅彦 (Masahiko Asai)
大手のWeb企画・制作企業にて、ナショナルクライアントの大規模なWeb制作を行う。自社のサービス開発でのやりがいを求め2015年にビズリーチに参画。HRMOS採用管理事業部のフロントエンド開発を牽引している。
当日は、
の5社の現場で実際に作られている(作っている最中である)デザインガイドラインやスタイルガイドをLTで発表するもので、それぞれの現場の苦労や背景、プロセスなどが見れて、私たちにとっても学びの多い時間となりました。
今日は、当日お話しさせていただいた内容をお伝えしようと思います!
当日のスライド
当日取り上げたサービスは、採用業務の一元管理と、データでの可視化・分析を通じて戦略的に採用を行うためのクラウドサービス「HRMOS(ハーモス)採用」です。
HRMOS採用ではスタイルガイドを策定するにあたり、Atomic Designの概念を取り入れて作成しています。Atomic Designとは、ページ単位でデザインするのではなく、UIコンポーネントの合体によってページを構成していく考え方で、下記のようなメリットがあります。
参考:新しいデザインシステムの手法 Atomic Designとは
後ほどご紹介しますが、HRMOS採用のスタイルガイドはWebで作っており、インタラクションまで確認することができます。
今でこそこの形ですが、それまでに課題が色々ありました。
当初は、Sketchファイルでスタイルガイドを管理していましたが、Sketchファイルをもとにフロントエンドの実装を進める中で、課題もいくつか出てくるようになりました。
課題①:100%再現されない
新しい機能が追加され、新しいUIやルールが追加された場合は都度、Sketchファイルをアプデートしていたのですが、実際の画面を実装するのはフロントエンドエンジニアで、100%意図した通りに再現されるかは、技術力とリソースに左右されされしまうこと。
課題②:同じUIなのにcssが複数存在する
スピード優先のサービスの場合によくありがちな、同じUIコンポーネントなのにも関わらず同時に複数人で開発することで、同じUIを再現するcssが複数存在し、さらには微妙に違うということ。
課題③:スタティックなファイルでは再現できないインタラクション
細かいインタラクション(例:アニメーションなど)など、感覚で判断するしかないものが多いこと。
課題④:Sketchファイルのアップデートが面倒
機能改修や色変更などが発生した場合、スタイルガイドの対象箇所を変更せねばならず、アップデートが面倒であること。
開発メンバーが増えるにつれ、上記のような課題が顕在化するようになり、なにかしらの対応が必要な状況になりつつありました。
お客様にHRMOS採用のUX/UIを評価頂いてる中、サービス全体で一貫性を保ち、良質な体験を提供するためには、ますますスタイルガイドが重要になってくることがメンバーの中で課題に上がりました。
とはいえ、スタイルガイドを整えて運用していくにはリソースがかかります……。日々の業務をやりながら、サービス内のUIを見直すことは簡単なことではなく、なかなか着手できずにいた中、あることがきっかけで着手することになります。
HRMOS採用はこれまでAngularJSで開発を行なっており、現在はAngularへのアップデートを進めています。このアップデートをきっかけに、上記の課題を解決できないか考えることにしました。
特に、アプリケーションの規模が大きくなるにつれ、UI(見た目)の部分とアプリのロジックが混ざり、お互いメンテナンスしづらい状況が増えてくるようになりました。また、UI(見た目)の修正はデザイナー+フロントエンドエンジニア自身の手でアップデートしたいなど、長期的にサービスを運用していく観点でもこのタイミングで課題を解決すべく、UIとアプリを分離することにしました。
これまでUIとアプリケーション間が密接に繋がっていたのを、UIコンポーネントライブラリとアプリケーション本体で、次のような指針に沿って分離するようにしました。
UIとアプリケーションの分離を進めていく中で、メンテナンス性も徐々に上がり、デザイナーとエンジニアの協業体制が少しずつ出来てきました。ただ、どんなUIコンポーネントが揃っているのか、全体像を把握しにくい状況でしたので「デモアプリ(=動くスタイルガイド)」も合わせて開発しようということになりました!(やっと本題です笑)
まずはデモをご覧ください。
動くスタイルガイドのデモ
このように実際に稼働しているサービスとは別に、UIコンポーネントだけを網羅的に見れる動くスタイルガイドにしたことで、たくさんのメリットがあります。
プロジェクトメンバーからも良い反応があります。
デザイナー:
フロントエンドエンジニア:
サーバーサイドエンジニア:
これまで良いことばかりを述べて来ましたが、もちろん課題や改善点もあります。
特に、フロントエンドエンジニアにタスクが集中しやすいこと、開発工数がかかることが欠点として挙げられます。
スタイルガイドにリソースを割くべきか問題は、どこでも起こり得ることだと思いますが、サービスにおいて長期的なビジョンがあり、統一したUIで複数のアプリケーションを素早く展開したいような状況下では、スタイルガイドの策定とデモアプリ化は有効と考えています。
以上、当日イベントでお話させていただいた内容をお届けしました!
当日感じたのは、どこもスタイルガイドの必要性を感じていて、色々試行錯誤しながら作っているんだなということでした。
さらに、
といった声も多く聞きました。
しかし、スタイルガイドの必要性を一番に感じているのは現場であり、サービスの拡大やメンバーの増員など長期的な視点で見たときには、スタイルガイドがあることが強みとなることは確か。わたしたちも道半ばですし、まだまだ課題があって試行錯誤を重ねている中で、まずはできることからはじめてみようと日々改善中です!
イベントではお伝えしきれなかった詳細は、今後ブログでスタイルガイドの作り方というシリーズでお伝えしていこうと思いますので、ぜひお楽しみに!
※2019年6月14日に「HRMOS採用管理」は正式名称を「HRMOS採用」に変更しました。