プロダクトを観察・理解するための、OOUI の概念モデリング
こんにちは、UIデザイナーの水澤です。今回は、OOUI に関する記事を書きます。
これまで自分が書いた記事(1本目・2本目)では、いずれも「設計する側」の視点で OOUI設計 のトピックに触れてきました。今回はそこから離れ、「観察する側」の視点で概念モデリングを活用している話をします。
「観察する側」の視点で概念モデリングを活用するとは
スタートアップのプロダクト成長支援をしている Gaji-Labo では、例えば「プロダクトに要素や機能が増えてきたので、UI改善をしたい」とご依頼いただくことがあります。見た目を整えるだけでなく、情報整理が必要になります。
そういったとき、まずはそのプロダクトの既存の状態を理解することが必要不可欠です。OOUI における概念モデリングを「観察する側」の視点で活用するとは、そのプロダクトにどんな要素・アクションがあるのかを観察し、概念モデリングによって抽出する作業を通してプロダクトの今の状態を理解することです。
概念モデリングでは、具体的にどの画面にどういう要素が掲載されているのかなどの細かい表現はしません。プロダクトの中でどのような概念を扱っているか、ユーザーが何を目当て(対象・目的)としてプロダクトを利用しているかの概念を書き出します。
上記は概念モデル図の一例です。実際のプロダクトではより複雑な形になっていきますが、このような図で表現します。
観察結果は自分の理解だけではなく、チームの目線合わせにも
概念モデリングを行う理由は、最初のうちは自身がプロダクトを理解するためでもありますが、最終的に目指すところはチーム全員の目線合わせができている状態を作るためです。
プロジェクトによって参加するメンバーやその立場はさまざまなので、概念モデリングによって「今はこういう状態ですよね」と改めて認識を揃えます。そうすることでその後の議論をする土台が整えられ、チームが出力しやすくなると考えています。
日頃プロダクトの開発に関わっているメンバーでも特定の機能や画面だけに触れる機会が多いこともあり、「ああ、そういえば全体はこうなっていましたね」と改めて認識される場面もあります。また、概念モデリングの過程で感じた疑問をヒアリングし、これまでの議論や開発経緯を聞いてプロダクトへの理解をより深めることにもつながっています。
終わりに
概念モデリングは、設計する側だけでなく観察する側として、既存のプロダクトがどのような状態であるかを観察・理解するために有効です。
ちなみにひとつ勘違いをしていたのですが、ドメイン理解をするにはあまり有効ではありません。概念モデル図が表すものはそのサービスが扱っているオブジェクトなので、むしろドメイン知識が全くない状況では、そのサービス特有のモデルから捉えようとすると齟齬が生まれる可能性があります。
もちろんヒントになるところはありますが、基本的にサービス理解とドメイン理解はしっかり切り分けて進められると適切に理解しやすいと思いました。
もしこの記事を読んで Gaji-Labo UIデザイナーの仕事内容が気になった方は、ぜひカジュアル面談にお申し込みください。お話できることを楽しみにしています!
Gaji-Labo UIデザイナー向けご案内資料
今すぐの転職でなくてもOKです!まずはお話しませんか?
現在弊社では一緒にお仕事をしてくださるエンジニアさんやデザイナーさんを積極募集しています。まずはカジュアルな面談で、お互いに大事にしていることをお話できたらうれしいです。詳しい応募要項は以下からチェックしてください。
- React, Next.js を得意とするフロントエンドエンジニア募集要項
- シニアクラスのフロントエンドエンジニア募集要項
- 抽象的な物事を具体的な機能にビジュアライズできるUIデザイナー募集要項
- UIデザイナーとして手ざわりのいいUIを作りたい業務委託パートナーさん募集(Wantedly)
パートナー契約へのお問い合わせもお仕事へのお問い合わせも、どちらもいつでも大歓迎です。まずはオンラインでの面談でお話しましょう。ぜひお気軽にお問い合わせください!
話をしてみたい!