社内向け管理アプリケーションのリプレイスでデザイナーが担ったこと

こんにちは。エキサイトでデザイナーをしている齋藤です。

前回の記事では『エキサイトブログトップページのリプレイスでデザイナーが担ったこと』と題し、一般ユーザーに提供する外向きのアプリケーションのリプレイスでデザイナーが担ったことをご紹介しました。

今回は、社内用の内向きのアプリケーションの事例を用いて、一般ユーザー向けとは異なった試行錯誤の過程をご紹介します。

前提と背景

エキサイトブログでは、ブロガー向けの他に、社内でコンテンツを管理するためのアプリケーションも存在します。

技術的側面と運用的側面の理由からリプレイスに至りました。

  • 運用的側面
    • 複雑な操作で使う人を選ぶ属人的なUI/UXであること
  • 技術的側面
    • メンテナンスコストが高い技術(v5系のPHPや独自フレームワーク)が用いられており、機能の新規開発や修正に時間を要する状態であること

これらの課題を解決すべく、リプレイスへの道を歩むことになりました。

デザイナーとして目指した理想状態

先述の課題を踏まえて、次の状態を理想と定めて開発を進めました。

  • 使う人を選ばない、担当者が初日から使用できるようなUI/UXにすること
  • バックエンドエンジニアだけでUIの構築ができる環境を整備すること

理想状態への過程

理想状態のために取り組んだ内容を一部ご紹介します。

使う人を選ばない、担当者が初日から使用できるようなUI/UXにする

現状整理を目的に関係者へのヒアリングから始めました。

既存のアプリケーションを通じてどんな運用タスクがあるのか、人力ではなく仕組みで解決できるものはないか、運用担当者・エンジニアとの折衝を重ねながら、運用業務を理解と改善案の土台づくりを進めました。

その上で、情報やタスクを取捨選択しながら再編案の作成に取り掛かります。

アプリケーションを通じたタスクを文章にすると、「(オブジェクト)に対して(目的)のために(操作)する」になります。

ユーザータスクを文章にしたとき

「担当者が初日から使用できる」を踏まえると、タスクへの解像度がまだ低いことが前提となりますが、その中で比較的明確になるのは「オブジェクト」であると考えます。

ユーザータスクで比較的明確なのはオブジェクト

したがって、オブジェクトを起点として必要な操作を実行できるUXが最適であると考え、OOUI(オブジェクト指向UI)を取り入れて、再編案を作成しました。

再編案の検討で作成した概観図(ぼかし加工をしています)

オブジェクト起点として、既存機能のタスクの統廃合やユーザーフローの交通整理を行いました。

性質上、データの扱いが複雑になるため、バックエンドエンジニアと都度相談しながら仕様策定とUI設計を繰り返します。

凝った演出は不要である一方で、操作を行っていることが伝わる体験(ユーザーアクションに対する反応等)は重視しました。

バックエンドエンジニアだけでUIの構築ができる環境を整備する

管理アプリケーションは、デザイナーが入らずにバックエンドエンジニア主導で機能追加が行われることも少なくありません。

バックエンドエンジニアだけでも一貫したUIが実装できる状態を理想とし、以下のことを意識してフロントエンドの技術選定とアーキテクチャの設計を行いました。

  • ページ・要素間が疎結合になること(例: 要素A用のCSSを削除したら、要素Bでも使用されていて表示崩れが発生するといったことが無いようにする)
  • コンポーネントベースでパズルのように画面構築ができること

ページ・要素間が疎結合になることについては、以下の記事で詳しくご説明しています。

tech.excite.co.jp

コンポーネントについては自前で用意しない、けれども依存関係は最小にする方針のもと、Tailwind CSSとAlpine.jsをベースとした外部のコンポーネントライブラリを採用しました。

結果、リプレイス後はバックエンドエンジニアだけで一貫したUIが、スピーディーに事故少なく構築できる環境とすることができました。

まとめ

今回は、社内向け管理アプリケーションのリプレイスでデザイナーが担ったことをご紹介しました。

タスクや扱うデータの数が多い中で業務フローと向き合いながら紐解いて再編するのは、一般ユーザー向けのUI/UXとは一味違う思考の仕方・動き方となります。

現状をそのままに見た目を整えるに留めず、「本当に必要な機能なのか」「人力ではなく仕組みで解決できるタスクはないか」を常に疑いながら進めることが大切であると考えます。

本稿が管理アプリケーションに携わるデザイナーの一助となれば幸いです。ご精読ありがとうございました。