はじめまして、パシャオクのデザインを担当している今尾と申します。
今回は、UI設計や表現の話ではなく、プロジェクト進行における効率化の一環として
・次々に打ち出される改善施策へのスピーディな対応
・デベロッパーとのスムーズなデザインファイル共有
・新参スタッフや後任者へのスムーズなデザイン作業移管
などのために、パシャオクでテスト的に実践しているデザイン管理の方法をご紹介したいと思います。
複数の異なる情報群にユーザーが効率的に接触できる場にすることと、回遊性の向上を目的に
ひとつのストリームラインを複数の「モデュール」で構成しているポータル的なつくりが
ページ設計のひとつの特徴になっています。
またパシャオクはオークションというサービスの性質上、キーワード検索やカテゴリ検索、
出品／入札／落札管理など機能的なモデュールが非常に多く存在します。
「ユーザー視点」という鉄則のもと、ユーザーの行動を綿密に想定し、
最適なコンテンツ構成を考慮した上で、ページがプランニングされているわけですが、
みなさんもご存知のとおり、緻密に設計したそれらも、
サービスを運用していくことで、次々とスピーディな改変を求められます。
抜本的な改革に踏み切る、いわゆる「ダカイゼン」は別として、
それら「カイゼン」は主に部分的なモデュールに対しての改修や、
モデュールの抜き差しによるページ構成の再編などが中心となります。
ページごとでデザインファイルを管理せず、機能単位で別けた
モデュール単位での管理を行っています。
もちろん初期設計や大幅な構成の見直しの際は、全体の文脈の整合性などを考慮する上でも、
ページ単位でのデザインを行いますが、
以降の改修やアレンジメントは各モデュール単位のファイルに対してデザインの
アップデートを行っていきます。
複数コンテンツや機能が混在しているため、比較的大きく（長く）なりがちな
それぞれのページファイルを、部分的な改修のために開いて作業を行うよりも
予めモデュールごとに細分化したデザインファイルに対して作業を行う方が、
効率的だと考えたためです。
また、多くの場合、複数ページにまたがって使用している回遊施策のためのモデュールも
ワンソース管理ができるので、ページごとの新旧混在や先祖返りを回避すること
にもつながるためです。
ナンバリングしたモデュールごとのデザインファイルと、
それらが他のどのモデュールとどういった順序で組み合わさりページを構成するのかを記した、
設計図としての簡易構成書を共有ファイルとすることで、
従来のページ単位をベースとした重く複雑なファイルをやりとりするよりも、
格段にスムーズになります。
各モデュールファイルにレイアウトガイドなどのデザインガイドラインを
記述すれば、別でデザインガイドラインを用意することなく、
レイアウト指示などを行うこともでき、デベロッパーの実装に役立つ他、
全容を熟知していない新参メンバーも、スピーディに改修作業に取り組めます。
以上、
あくまでも現段階ではまだテスト的に行っている取り組みですが、
ご参考程度にしていただければと思います。
今回は、UI設計や表現の話ではなく、プロジェクト進行における効率化の一環として
・次々に打ち出される改善施策へのスピーディな対応
・デベロッパーとのスムーズなデザインファイル共有
・新参スタッフや後任者へのスムーズなデザイン作業移管
などのために、パシャオクでテスト的に実践しているデザイン管理の方法をご紹介したいと思います。
ページの構成とスピーディーなデザイン改善
Amebaのいくつかのサービスと同様に、パシャオクの各ページも、複数の異なる情報群にユーザーが効率的に接触できる場にすることと、回遊性の向上を目的に
ひとつのストリームラインを複数の「モデュール」で構成しているポータル的なつくりが
ページ設計のひとつの特徴になっています。
またパシャオクはオークションというサービスの性質上、キーワード検索やカテゴリ検索、
出品／入札／落札管理など機能的なモデュールが非常に多く存在します。
「ユーザー視点」という鉄則のもと、ユーザーの行動を綿密に想定し、
最適なコンテンツ構成を考慮した上で、ページがプランニングされているわけですが、
みなさんもご存知のとおり、緻密に設計したそれらも、
サービスを運用していくことで、次々とスピーディな改変を求められます。
抜本的な改革に踏み切る、いわゆる「ダカイゼン」は別として、
それら「カイゼン」は主に部分的なモデュールに対しての改修や、
モデュールの抜き差しによるページ構成の再編などが中心となります。
モデュール単位でのデザイン管理
そこでパシャオクでは、キャンペーンや特集用などの企画系ページ以外はページごとでデザインファイルを管理せず、機能単位で別けた
モデュール単位での管理を行っています。
もちろん初期設計や大幅な構成の見直しの際は、全体の文脈の整合性などを考慮する上でも、
ページ単位でのデザインを行いますが、
以降の改修やアレンジメントは各モデュール単位のファイルに対してデザインの
アップデートを行っていきます。
複数コンテンツや機能が混在しているため、比較的大きく（長く）なりがちな
それぞれのページファイルを、部分的な改修のために開いて作業を行うよりも
予めモデュールごとに細分化したデザインファイルに対して作業を行う方が、
効率的だと考えたためです。
また、多くの場合、複数ページにまたがって使用している回遊施策のためのモデュールも
ワンソース管理ができるので、ページごとの新旧混在や先祖返りを回避すること
にもつながるためです。
ディベロッパーへのファイルの受け渡し
デベロッパーとのファイルの受け渡しもナンバリングしたモデュールごとのデザインファイルと、
それらが他のどのモデュールとどういった順序で組み合わさりページを構成するのかを記した、
設計図としての簡易構成書を共有ファイルとすることで、
従来のページ単位をベースとした重く複雑なファイルをやりとりするよりも、
格段にスムーズになります。
各モデュールファイルにレイアウトガイドなどのデザインガイドラインを
記述すれば、別でデザインガイドラインを用意することなく、
レイアウト指示などを行うこともでき、デベロッパーの実装に役立つ他、
全容を熟知していない新参メンバーも、スピーディに改修作業に取り組めます。
以上、
あくまでも現段階ではまだテスト的に行っている取り組みですが、
ご参考程度にしていただければと思います。