他サービスと連携した機能をデザインする
こんにちは！プロダクトデザイナーの上原です。
ちょっと前になるのですが、Microsoft Teams上でオンライン名刺の交換ができる機能をリリースしました。
その際の体験設計を担当したのですが、他サービスと連携する際に意識した点や大変だった点を振り返ってみます。
まずは公式ドキュメントを理解する
Sansan内に閉じたサービスであれば何ができるかであったり、実現可能性はエンジニアメンバーと密に連携していく事で進めやすいと思います。
しかし、他サービスと連携した機能を作る場合は、そのサービスを理解することが大切でもあり大変です。
TeamsにはMicrosoft社が公開している公式ドキュメントがあります。
まずはそこを確認・理解します。
APIの仕様などはエンジニアメンバーが確認してくれますが、UIなどのレギュレーションも存在します。
Figma上で提供されているUIもある
また、Temasの場合はFigma上にUI Kitなども提供されているので、それらを把握し、どのような選択肢があるのか、どのUIが望ましいかを理解していきます。
グローバルなサービスはUI KitなどがFigmaで公開されている事も多いので、そこでFigma上でのコンポーネント化やガイドラインなどを参考にするのも良いインプットになります。
他メンバーもわかるようにしておく
そして、確認したドキュメントは今後他のメンバーが作業する際にも伝わるように、↓のような形でFigmaのThumbnailにリンクを設定しています。
実際にそのサービスを可能な限り触れてみる
次に、実際のTeamsアプリにも触れてみます。
ドキュメントでは理解できない挙動などを実例をみて理解を深めて行くことが大切です。
ユーザーは普段使いしているプラットフォームを使っている感覚なので、Sansan独自の挙動で混乱させては良い体験になりません。
細かい箇所で言えば、Submitした後の挙動やテキストの表現方法なども体験して把握していきます。
なるべく多くをインプットしていく為に、社内のメンバーとも率先してそのサービスを使うように心がけます。
定期的に行うオンラインMTG等も、普段はZoomの弊社でしたがTeams上で実施する等も意識していきました。
また、Teams上で提供されいている他社のサービスなども意識して試すようにしていました。国内のサービスよりも、海外のサービスの方が、Teamsの様々な振る舞いを多様に取り入れているように感じたのも印象的でした。
連携先サービスの開発知識がある方を巻き込む
これは連携するサービスとの関係性や座組にもよると思いますが、連携先サービス側のエンジニアリングがわかる方が付いてくださると効率よく開発を進めることができると思っています。
実現可能性などはSansan側のエンジニアメンバーも最大限調査・検証をしてくれていますが、実装してみないと見えてこない所などもあります。
そういった観点で、連携サービス側にエンジニアリングの知見がある方が付いていただけるのであれば、早い段階でプロトタイプをベースに論点や新しい可能性を洗い出す事ができると思います。
プレスリリース等のプロモーションを見越しておく
機能リリースが近くなってくること、プレスリリースの話も出てきます。
また、営業用資料への展開なども必要になってきます。
その際には当然画面イメージなども添え世に出していく必要が出てきますが、デザイン時に適当なダミーデータで作ってしまうと、その際に修正の手間が発生してしまいます。
僕はまさにそのパターンだったので、プレスリリース用にデータを整える作業で時間を要してしまいました。
予めそういった場面で使えるデータで作っておけばよかったと思っています。
連携サービスのUIが変わる事を想定しておく
当然の如く連携サービス側も日々進化をしています。
これも失敗談に近い話ですが、開発途中で連携サービス側のUIやトンマナが変わる事がありました。
先方のUI KItからデザインを持ってきている場合も、UI Kitが直ぐに最新化されるわけではなりません。DuplicateしたUI Kit上のコンポーネントを手作業で新しいUIに更新していく作業などもありました。
また、全てをFigmaでコンポーネント化していたわけではなかったので、画面遷移毎にUIを最新に差し替える作業なども発生しました。
自分たちでコントロールできないところなどは、変更に強い作りにしておかないとこういった手間が起きやすくなります。
当たり前の事も多いですが、以上が他サービス連携をデザインする時の振り返り備忘です。
この記事が気に入ったらサポートをしてみませんか？