2020年に設立され、オスロとロンドンを拠点に活動するチームを擁するFindableは、建築環境に特化したAIを活用したドキュメントインテリジェンスプラットフォームです。同社は、不動産所有者、管理者、コンサルタントがAIを活用して建築関連ドキュメントの検索、抽出、分析を行うことを支援しています。

Findableのプラットフォームでは、ユーザーは自然言語を使って数千件に及ぶ建築関連ドキュメントに対して質問を行い、非構造化ファイルから構造化データを抽出し、コンプライアンスレポートを自動的に生成することができます。こうしたAI駆動の機能を実現するには、パワーとシンプルさのバランスが取れたインターフェースが必要です。

そこで、同社がアプリシェルのアップデートが必要になった際、デザインチームはこれを製品開発ワークフローを最適化する好機と捉えました。チームは以前にもFigmaを使用してアプリシェルの再設計を行っていましたが、効率性と実験を重視する社風のもと、Figma Makeの機能を試すことが次のステップとなりました。

Findableは、Figma Makeが生成したコードの90%を活用することで、アプリシェルのビルドを50%高速化しただけでなく、製品開発プロセスを民主化し、デザインや開発部門以外のチームも取り組みに巻き込むことに成功しました。

課題: アプリシェルの慎重な取り扱い

アプリシェルはWebアプリケーションの基本構造を提供します。最初に読み込まれ、全体的なユーザーエクスペリエンスの鍵となります。FindableのプロダクトデザイナーであるRiccardo Busatoがこのプロジェクトを主導し、ナビゲーション、レイアウト、構造の設計などを担当しました。これらの要素が、Findableの他のすべての製品を支える基盤となります。

課題は、アプリシェルが脆弱になりやすいという点です。小さなミスがあちこちに影響を及ぼす可能性があり、将来の柔軟性は初期段階でのアーキテクチャ上の決定に左右され、また、徹底的なテストと反復作業が必要となります。

解決策: 静的デザインに命を吹き込む

稼働中のサイトの複雑さは静止画像ではシミュレートしにくいため、Findableではこれまで、デザイナーと開発者の認識を一致させるために、時間のかかる詳細なハンドオフプロセスに頼っていました。そして、デザインからコーディングへのワークフローの過程で解釈のズレが生じ、本番環境で初めてその問題に気づくことがよくありました。

こうした経緯から、チームはFigma Makeに目を向けました。当初は、開発者が最初からより深く、明確に理解できるようにするためのプロジェクトとして始まりましたが、その後、はるかに大きなものへと発展していきました。

構造だけでなくデザインを構築

Riccardoにとって最初のひらめきの瞬間は、Figma Makeが単にビジュアルを生成しているだけでなく、アプリシェルの構造も構築していることに気づいたときでした。

フロントエンドおよびデザインシステムの経験を生かし、Findableアプリのデザインシステム、コンポーネント、テーマ、スタイルをすべてFigma Make内で再現することができました。

これにより、チームは実際のアーキテクチャの骨組みの中で、実際のナビゲーションやルーティングロジックを備えた高忠実度のアプリシェルを構築することができました。

つまり、完全に機能する動作可能なプロトタイプであり、ステークホルダーはアプリを見るだけでなく、感じることもできるのです。

プロトタイプがハンドオフになる

Findableのチームは、アイデアの創出がより迅速になっただけでなく、Figma Makeがデザインからコードへの移行に役立ったことも発見しました。

以前は、詳細なハンドオフプロセスに複数の会議が必要で、多くの場合、専用のハンドオフツールも必要でした。しかし今では、プロトタイプそのものがハンドオフの役割を果たすようになり、デザインからコーディングまでのワークフローが合理化されました。

さらに、Figma MakeファイルはFigmaと同様、シンプルなリンクで簡単に共有できるほか、デザイナーと開発者の間で迅速な作業を行うためのライブコラボレーションも可能です。

再利用可能なテンプレート

この時点で、プロトタイプは、チームがこれまで構築してきたどのシステムよりも、設計やテスト、共有、そしてハンドオフが容易になっていました。

やがてRiccardoは、自分がさらに強力なものを構築したことに気付きました。デザインシステムとアーキテクチャパターンがすでにプロトタイプに組み込まれていると考えれば、将来のデザインにも再利用可能なテンプレートになるのではないか?

こうした考えに基づき、チームはさらに一歩踏み込み、主要な機能パターンや代表的なフローを追加して、アプリシェルをテンプレートへと進化させました。これにより、このテンプレートはFindableのデザインシステム、レイアウト、ナビゲーション、そしてアーキテクチャの基盤となり、当初のプロジェクトの枠を超えて活用されるようになりました。

Figma Makeがルールを施行

チームは、確固たる基盤があっても、ガードレールを定義しないと、システムが徐々に一貫性と構造を失ってしまうことを理解していました。ページの内容がバラバラになり、パターンが乱れ、コードの品質が低下し、保守性が損なわれることになるでしょう。

この問題を解決するため、Findableは根本的な方向転換を行い、Figma Makeを活用してアプリ自体のルールを定義しました。具体的には、デザインルール、レイアウトパターン、アーキテクチャ上の制約、コード品質ガイドライン、さらにはTailwindの使用ルールも定めました。

その結果、チームは予測可能な構造とクリーンなコードに基づいてデザインを一貫して維持することができました。

シニアデザイナーのHans Christian Bergeは次のように述べています。「Figma Makeを使って事前にルールを定義することで、規模が拡大しても一貫性と予測可能性を保ち、強靭なシステムを構築することができました。しかし、真の価値はデザインの民主化にあります。Findableの従業員なら誰でも、既存の仕組みを壊すことなく、製品開発に貢献できるようになったのです」

プロトタイプ作成プロセスの民主化

フロントエンドエンジニアリングの知識とアーキテクチャ的思考を組み合わせることでプロトタイプの構築は進んだものの、Findableにとって真に画期的な変化をもたらしたのは、デザインルールの導入でした。これにより、他のデザイナーもテンプレートを活用して、既存の機能を損なうことなく作業できるようになっただけでなく、複数の人がプロジェクトに関わる際に起こりがちな、デザイナーごとの仕様のばらつきも回避できるようになったのです。

しかし、真の転機となったのは、このテンプレートを利用できるのはデザイナーだけではないと気づいたことでした。テンプレートの基盤がしっかりしており、アーキテクチャがコード化され、ルールが明確に定義されていれば、他のチームもプロセスに参加できるのです。

これによりプロトタイプ作成プロセスが民主化され、まったく新しい、そしてFindableにとっては予想外のユースケースが誕生しました。

• カスタマーサクセスチームが顧客と共にアイデアをライブでスケッチ
• セールス部門が会議で機能要望をプロタイプ作成
• PMが設計を妨げることなくフローを検討
• 全社を横断した、より迅速で明確なフィードバックループ

「Figma Makeを使えば、アイデアについて話し合っている最中にプロトタイプを作成できます。顧客との打ち合わせ中だろうと、その直後だろうと、製品内でコンセプトを形にすることができ、それがFindableの実際の機能に基づいていると確信できます」と、Hansは語ります。

結果

Figma Makeのコードを90%活用することで、市場投入までの時間を50%短縮

最終的なアプリシェルは、当初の予定より50%早く納品されました。最終製品にはFigma Makeのコードの90%以上が使用され、その実装には1日もかかりませんでした。

当初は単なるアプリシェルの再設計として始まったプロジェクトでしたが、はるかに大きなものへと発展しました。最終的に、Findableは全社的なデザイン・開発エンジンとしても機能するプロトタイプを完成させました。それはテンプレートであり、ハンドオフツールであり、生産性を飛躍的に高めるツールであり、イノベーションを加速させる原動力になりました。