こんにちは。
Ameba Ownd(アメーバ オウンド)でiOS・AndroidアプリのUIデザインを担当しています、鈴木です。
4月28日に『~「Ameba Ownd」制作秘話から学ぶ~CyberAgent UI design seminar』というセミナーを行いました。
チーフ・クリエイティブディレクターの佐藤をはじめ、計4人のデザイナーから日々取り組んでいるデザインの現場についてお話しさせていただきました。
私からセミナーで話しさせていただいた「UIデザイナーの役割や進め方」を、Ameba Owndの立ち上げ秘話を交えて、お話したいと思います。
Ameba Ownd(アメーバ オウンド)でiOS・AndroidアプリのUIデザインを担当しています、鈴木です。
4月28日に『~「Ameba Ownd」制作秘話から学ぶ~CyberAgent UI design seminar』というセミナーを行いました。
チーフ・クリエイティブディレクターの佐藤をはじめ、計4人のデザイナーから日々取り組んでいるデザインの現場についてお話しさせていただきました。
私からセミナーで話しさせていただいた「UIデザイナーの役割や進め方」を、Ameba Owndの立ち上げ秘話を交えて、お話したいと思います。
セミナー風景。セミナー後の座談会でも各デザイナーに熱のある質問をぶつけてくれていました。
Ameba Ownd(アメーバ オウンド)とは?
誰でもかんたんにウェブサイトを作成でき、更新できるサービスです。
PCブラウザにて提すべての機能を利用できるほか、iOS/Androidアプリで主にサイトの閲覧や記事の投稿を提供しています。
amebaownd.com/go
技術的にウェブサイトやブログを立ち上げられない方向けに、かんたんかつ、オシャレにサイトを作成できることが狙いです。
Ameba Owndの開発は困難の連続でした。
予定されている機能の一つ一つが大きく、密に絡み合うので、機能一つで弊社からリリースしていたコミュニティサービスがひとつ作れてしまう規模感でした。
また近頃のサービス開発では、アプリメインでPCでも閲覧できる、というバランスで開発するケースが多かったのですが、Ameba OwndではPCブラウザを主としたサービスなので、アプリとしては機能が多い環境下で開発するという難しさがありました。
そういった課題に加え、機能を絞ってアプリらしい使い勝手を保てるように最適化していくという作業がありました。
これらの課題をどのように解決するか考えた結果、
「何を作るか決める/共有する/ディレクションする」ということを、 デザイナーが意識できれば、出戻りを減らすことができ、最短で作れるのではないかと思い試していきました。
全体としては、このような流れで進めていきます。
開発のフローととしてはオーソドックスな流れだと思いますが、気をつけていたのは決まっていく仕様やUIデザインを早めに共有していくことです。
なぜ今回、ここまで共有を重視したのかというと、
冒頭であげた課題「メンバー誰もが手探り」という点が理由です。
手探りの状態でブラウザ、iOS、Androidを同時に大規模開発しているので、歯車1つが変わるだけで他の部分に影響が出る可能性も高かったので、開発メンバーにはUIデザインを含めてリアルタイムに共有できるように気をつけました。
膨大な仕様を決めつつ、同時に画面を作っていくスケジュールの中で、UIのラフスケッチは効果的でした。
通常、デザイナー自身がアイデアをまとめることに使うことが多いですが、メンバーに対しての共有・確認方法としても非常に有効です。
ラフスケッチの具体的なメリットは、
違う紙にどんどんかけるので、アイデアを広げやすく、紙を並べればアイデア全体を俯瞰して見られる点です。 また、修正をその場で入れていくこともできるので、出戻りを減らすことができます。
一般的なコミュニティアプリであれば、UIデザインを作った方が早いと感じることが多いかもしれません。しかし、今回はプラットフォーム開発だったため、実装段階での出戻りは限りなく減らし、少しでも時間を作り出すためでした。
実際、ラフスケッチを使って仕様を固めた上でツールを使ってUIデザインを作るので、ほぼ迷うことなく作っていくことができました。
デザインを作ると同時に、
アプリ開発ではおなじみになってきたプロトタイピングツールの出番です。画面遷移をイメージできる状態でブラウザと仕様をすりあわせつつ、エンジニアにも同時に相談していきます。
(※場合によってはラフスケッチの段階でプロトタイプを作ることもあります)
この実装のタイミングで、「この画面でユーザーにやってもらいたいことは」というワードを意識して使っていました。
この段階までくると一つ一つの機能開発に集中していることが多いので、「ユーザーに何をしてもらいたいからこの画面フローになっている」ということに再び意識を向けるためです。
「この画面でユーザーにやってもらいたいことは◯◯です」と機能ごとに明確にすることで、開発メンバーの目指すゴールを一つにすることができました。
最後になりましたが、UIデザイナーの役割とはなんでしょうか。
例えば、マークアップができることでしょうか? After Effectsを使ってアニメーションが作れることでしょうか? 企画ができたりイラストもかけることでしょうか。
どれでも非常に大切なことだと思います。しかし、わたし個人の考えにはなりますが、
「情報を整理して、問題を解決する。」それがデザイナー本来の役割だと考えています。
その考えのもと、冒頭でお話した課題をどうしたら解決できるかということを考えた今回の結果、「何を作るか決める/共有する/ディレクションする」というアウトプットになったにすぎません。状況しだいで変化するでしょう。
手段を増やすことも非常に大切ですが、「問題を解決する」というような目的意識があると、自分にとって必要な手段がより見えてくるのではないでしょうか。
UIデザイナー/クリエイティブ・ディレクター
鈴木 伸緒
@nobgraphica
Ameba Ownd(アメーバ オウンド)とは?
誰でもかんたんにウェブサイトを作成でき、更新できるサービスです。
PCブラウザにて提すべての機能を利用できるほか、iOS/Androidアプリで主にサイトの閲覧や記事の投稿を提供しています。
amebaownd.com/go
技術的にウェブサイトやブログを立ち上げられない方向けに、かんたんかつ、オシャレにサイトを作成できることが狙いです。
立ちはだかる壁「機能が多く、メンバー誰もが手探り」
Ameba Owndの開発は困難の連続でした。
予定されている機能の一つ一つが大きく、密に絡み合うので、機能一つで弊社からリリースしていたコミュニティサービスがひとつ作れてしまう規模感でした。
また近頃のサービス開発では、アプリメインでPCでも閲覧できる、というバランスで開発するケースが多かったのですが、Ameba OwndではPCブラウザを主としたサービスなので、アプリとしては機能が多い環境下で開発するという難しさがありました。
そういった課題に加え、機能を絞ってアプリらしい使い勝手を保てるように最適化していくという作業がありました。
これらの課題をどのように解決するか考えた結果、
「何を作るか決める/共有する/ディレクションする」ということを、 デザイナーが意識できれば、出戻りを減らすことができ、最短で作れるのではないかと思い試していきました。
制作フローと、共有の大切さ
全体としては、このような流れで進めていきます。
- 手描きでおおまかなデザインを作る
- デザインツールで作成
- モックアップで確認
開発のフローととしてはオーソドックスな流れだと思いますが、気をつけていたのは決まっていく仕様やUIデザインを早めに共有していくことです。
なぜ今回、ここまで共有を重視したのかというと、
冒頭であげた課題「メンバー誰もが手探り」という点が理由です。
手探りの状態でブラウザ、iOS、Androidを同時に大規模開発しているので、歯車1つが変わるだけで他の部分に影響が出る可能性も高かったので、開発メンバーにはUIデザインを含めてリアルタイムに共有できるように気をつけました。
ラフスケッチの効果
膨大な仕様を決めつつ、同時に画面を作っていくスケジュールの中で、UIのラフスケッチは効果的でした。
通常、デザイナー自身がアイデアをまとめることに使うことが多いですが、メンバーに対しての共有・確認方法としても非常に有効です。
ラフスケッチの具体的なメリットは、
違う紙にどんどんかけるので、アイデアを広げやすく、紙を並べればアイデア全体を俯瞰して見られる点です。 また、修正をその場で入れていくこともできるので、出戻りを減らすことができます。
一般的なコミュニティアプリであれば、UIデザインを作った方が早いと感じることが多いかもしれません。しかし、今回はプラットフォーム開発だったため、実装段階での出戻りは限りなく減らし、少しでも時間を作り出すためでした。
実際、ラフスケッチを使って仕様を固めた上でツールを使ってUIデザインを作るので、ほぼ迷うことなく作っていくことができました。
実装のディレクションで気をつけたこと
デザインを作ると同時に、
アプリ開発ではおなじみになってきたプロトタイピングツールの出番です。画面遷移をイメージできる状態でブラウザと仕様をすりあわせつつ、エンジニアにも同時に相談していきます。
(※場合によってはラフスケッチの段階でプロトタイプを作ることもあります)
この実装のタイミングで、「この画面でユーザーにやってもらいたいことは」というワードを意識して使っていました。
この段階までくると一つ一つの機能開発に集中していることが多いので、「ユーザーに何をしてもらいたいからこの画面フローになっている」ということに再び意識を向けるためです。
「この画面でユーザーにやってもらいたいことは◯◯です」と機能ごとに明確にすることで、開発メンバーの目指すゴールを一つにすることができました。
UIデザイナーの役割
最後になりましたが、UIデザイナーの役割とはなんでしょうか。
例えば、マークアップができることでしょうか? After Effectsを使ってアニメーションが作れることでしょうか? 企画ができたりイラストもかけることでしょうか。
どれでも非常に大切なことだと思います。しかし、わたし個人の考えにはなりますが、
「情報を整理して、問題を解決する。」それがデザイナー本来の役割だと考えています。
その考えのもと、冒頭でお話した課題をどうしたら解決できるかということを考えた今回の結果、「何を作るか決める/共有する/ディレクションする」というアウトプットになったにすぎません。状況しだいで変化するでしょう。
手段を増やすことも非常に大切ですが、「問題を解決する」というような目的意識があると、自分にとって必要な手段がより見えてくるのではないでしょうか。
UIデザイナー/クリエイティブ・ディレクター
鈴木 伸緒
@nobgraphica