皆さん stand.fmというアプリ/サービスを知っていますか？
そうです。音声サービス界隈に彗星の如く現れたニューヒーローとも言えるサービスです。そのぐらい今、勢いがあると思います。

皆さんご存知の通り、音声コンテンツ市場は近年、googleやspotifyの参入やスマートスピーカーの普及に伴ってかなり盛り上がっており、日本の市場も例外ではなく、RadiotalkやVoicy、Recなど様々なサービスが存在しています。
そんな盛り上がりを見せる市場で、最近、特にコンテンツの充実・サービスとしての伸びを見せているのが、この stand.fm だという事です。

僕は今まで、appleのpodcast、Voicy,Radiotalkのユーザーでしたが、そんな僕が最初にこのアプリを触った印象は、
「使いやすい！UIがかわいい！」
気軽にTwitterのタイムラインから飛んで配信を一度聞いたつもりが、今では毎日使用するアクティブユーザーになってしまっています。ぐぬぬ…

使いやすいUIには、ユーザーが気づかないデザイナーの細かな配慮や設計が必ずあるはずなので、今回UIデザインの修行僧として、僕がこのかわいいUIをトレースしてその謎を紐解いていこうと思います。

今回このnoteを書くにあたって、東 莉緒(@rio310mink)さんのnoteを参考にさせていただきました。競合サービスの特徴を把握する上で大変勉強になりました。

stand.fmって？

stand.fmは「音声配信を気軽にもっと楽しく」をキーワードとした音声コンテンツ配信サービスで、特徴は以下の通りです。

✏️特徴
•質問に回答することが出来る「レター」機能
•直感的で使いやすいUI
•LIVE配信機能
•コラボ配信機能
•短めのコンテンツがメイン

運営会社は、女性に人気のキュレーションメディア「Mery」を立ち上げた中川綾太郎さんが創業したnewnで、newnは他にも、チーズケーキのD2Cブランド「Mr.CHEESECAKE」や小柄な女性向けのアパレルブランド「COHINA」を運営しています。実績を見るだけでも、インターネットを活用して既存のマーケットに切り込み、ユーザーの心を掴んでいくのがとても得意な会社という印象を受けます。newnが運営するサービスはどれもスタイリッシュでふわっとしていて、どこかかわいらしいイメージを抱くようなサービスで、このstand.fmにも当然newnのブランドコンセプトが一貫して反映されている気がします。やはりどことなく、かわいらしくて柔らかい印象を受けます。

配信者層としては、テック系からカルチャー系などある分野に特化した方々が多く発信しています。著名な配信者としては、スタートアップ界隈の有名な方々が多く発信されていますが、あえて発信者層の特徴を挙げるとするならばやはり、知名度の高い方々だけではなく、幅広くある分野に特化した人々を取り込んでいる点だと言えます。

著名な配信者
•けんすうさん
•Goodpatch 土屋さん
•LayerX 福島さん
•FABRIC TOKYO 森さん
•優木まおみさん　etc...

概念モデルについて〜stand.fmのUIを考察する前に〜

音声コンテンツサービス（音楽を除く）は、多くの人にとって、最近になるまでそこまで馴染み深いものでは無かったと思います。現に、stand.fmで初めて音声コンテンツを聞いた人も少なくないと感じます。
そうした新たな層に対して、馴染みのないサービスを提供する上で非常に重要になるのが、概念モデル（メンタルモデル）です。

以下、D.A Norman「誰のためのデザイン？」より
概念モデルとは、通常きわめて簡素化された、あるモノがどう動くかについての説明である。
...
概念モデルは一つのまとまったイメージであるのに、対象物は世界のあらゆるところにある異なる機会の中に置かれた部分から構成されていることもある。
...
メンタルモデルは、その名からも分かるように、人の頭の中にあって、ものがどう動作するかについてのその人の理解を表す概念モデルである。同じモノに対しても、人それぞれの異なるメンタルモデルがあるだろう。実際、ある人が一つのモノに対していくつかのメンタルモデルを持つことも有る。それぞれは、その働きの異なる側面に対応している。モデル同士が矛盾することさえもある。

要するに、「人々が、他のモノから想像して作り出す、ある特定の一つのモノに対する理解のイメージってことですね。」
僕ら人間は、自分の馴染みの無いモノにふれるとき、アフォーダンスや、対応づけ、色、形、マニュアルなどから、そのモノがどういうモノなのかを想像しながら、触れていきます。例えば、ハンドルに似た形のアプリのUIを見たとき、僕らは車のハンドルを連想し、それは左右に回せると考えたりします。
このように、僕ら人間が馴染みの無いプロダクトに触れるときに欠かせないのが、概念モデル、メンタルモデルなんです。
そしてNormanは、良い概念モデルを示唆することがデザインをする上で非常に重要とも述べています。

概念モデルは、理解を助けたり、モノの動きを予測したり、モノが予定通りに動かないときにどうすればよいかを知るのに役立つ。良い概念モデルがあると、自らの行動の結果を予測できるようになる。良いモデルが無い時には、機会的に闇雲に操作しなくてはならなくなる。言われた通りにしか出来ない。なぜそうなるのかを十分に理解できないし、どういう結果が生じるのかもわからない。

そして、僕がここで考えたいことは、音声コンテンツアプリを初めて僕らが使うとき、もしくはそこまで馴染み深くないとき、どのような他のプロダクトを連想して概念モデルを構成していくかという点です。ここがこの音声コンテンツというサービスのUIを１から設計していく上で非常に重要になってくると考えています。

音声コンテンツアプリの概念モデルを構成していく上で、ユーザーの連想するプロダクトは、

連想されるプロダクト
•Yotubeに代表される動画サービス
•spotify、apple musicなどの音楽アプリ
•apple podcast、spotify pocastなど既存のポッドキャストサービス
•Twitter、Instagramに代表されるSNSアプリ

ユーザーは下記画像左のような機能に触れたとき、各サービスのUIを想起すると想定されます。

つまり、UIの設計段階で、上記画像左のような機能が要件に含まれていた場合、UIデザイナーは、右にあるようなサービスから想起される概念モデルと不一致のないようにUIを設計していく必要があると思います。

こうした背景を理解しつつ、ようやくstand.fmのUIを見ていきたいとと思います。各画面のトレースに仕様したツールはadobe XDです。

ホーム画面

左から元画像、トレース、ボックスモデル

UI要素としては以下の要素があります。

📍UI要素
•ロゴ
•検索ボタン
•特徴を説明するスライド式カード（大きいサイズ）
•コンテンツのカード（LIVE配信中、各カテゴリ、）
•特徴を説明するスライド式カード（小さいサイズ）
•ハッシュタグに該当するコンテンツカード
•タブバー

ホーム画面にはかなり大きめのサイズでフローティングのカード要素があり、これをめくっていくことで、stand.fmの使い方や特徴を把握することが出来ます。このカードをクリックすると、詳細ページに飛ぶことから、かなりサービスの紹介が丁寧になされている印象を受けました。コピーとしては、「あなたも配信をはじめてみよう」という事で、このアプリはただコンテンツを聞くアプリでは無く、誰でも発信が出来る事をアピールしている事が伺えます。カードをスライドしていくと、LIVE機能、レター機能の紹介が続くことからも、手軽な発信を全面に押していることが分かるでしょう。

カードの下には、LIVE配信中のコンテンツ、おすすめちゃんねる、話題のちゃんねる、以下各カテゴリのコンテンツ、各ハッシュタグに該当するコンテンツが並んでいます。

また、スライド式の要素では、必ず２個めのカードを若干はみ出させることで、この続きに同じ要素がある事をアピールしています。

各カテゴリの要素をすべて見たい場合は、右上の「すべて見る」から確認する事ができます。一般にあるカテゴリグループに対して、そのコンテンツのすべてを見るという動作には、右端の位置にUI要素が与えられる傾向に有ると思います。

カテゴリの並び順としては、ライフスタイル生活、ミュージック、エンタメ、クリエイティブ・テック…とあてはまるユーザーが多い順に並んでいます。また、トップビューで真っ先に目に入る、特徴を紹介するスライド式のフローティングカードを小さくしたものが、ところどころ差し込まれていて、アプリの特徴をユーザーに掴ませる事が徹底されています。

🧐違和感
「すべてのコンテンツ要素はワンタップで再生に飛ぶ事ができる。」

ここで少し違和感を感じました。各コンテンツ内の主要な要素は番組名と番組画像です。その構成であれば、要素をタップすると、その番組の放送一覧に飛ぶ挙動だけがあるというのが一般的であるように思われます。（＝ワンタップ再生は存在しない）例えばappleのポッドキャストの「見つける」ではこの設計を採用しています。

逆に、各コンテンツのワンタップ再生を重視するのであれば、番組タイトルは小さめにし、最新の放送自体の再生要素（＝再生ボタンと、各放送タイトル）を大きくデザインする気がします。このような設計はYoutubeのホームで採用されています。

そこで、もう一度stand.fmのカテゴリ内コンテンツを確認すると、番組自体をメインとしつつ、最新の放送をサブとして持っている事がわかります。

ここから伺える事は、このアプリはレターを中心に設計されたもので発信者もレターに回答している人が少なくありません。そうなると、ホーム画面に表示されるような番組（＝多くはフォローしていない番組）の各放送の1回ごとのタイトルからは、番組の内容が掴みづらい部分があると推察されます。仮にこの番組サムネイルと「ムーンライト伝説」というタイトルだけのビュー（＝Yotutube型のワンタップ再生の設計。）ですぐに再生出来る場合、コンテンツの内容が想像出来るか、魅力を感じるかを考えてみてください。恐らく不可能に近いと思います。

Youtubeのような動画コンテンツの場合は、サムネイルを見ただけで各コンテンツの内容を想起する事が出来ます（＝サムネイルの情報量が多い）が、音声コンテンツの内容を伝える上で、サムネイルだけでは情報としてとても弱いです。そこで、再生は促しながらも、その番組がどんなものであるかを確実に伝える必要があったと考える事が出来るでしょう。他方で、stand.fmは短めの放送を想定しているため、podcast型のビューでは、この手軽に聞けるという感覚が表現できないため、podcast型を採用していない気がします。

つまり、このサービスにおいては、話題ベースではなく、「誰が何を話しているか」という部分が、コンテンツとして非常に重要性を持つ事がわかります。そのためこのような、「即時の再生」と「番組のコレクションにつながる要素」の両方の要素を1つのカードで表現したと思われます。

タブバーの要素は5つで、左からホーム、フィード、録音、通知、ユーザチャンネルの順。録音が中心にあることからも、このアプリが録音を設計の中心に据えている（＝発信者を支援）事がわかります。
フィードのアイコンはapple podcastにかなり類似したものを採用していました。

長々と書いてしまいましたが、トップ画面及び、タブバーについてまとめると、

📍トップ画面とタブバーのまとめ

•大きいフローティングカードから詳細ビューへ移行する設計は、ユーザーへこのアプリの特徴を伝えるためである。
•スライド要素の2個目は、あえてはみ出させることで連続感を演出出来る。
•音声コンテンツ及び、stand.fmにおいては、誰/どんな人が発信しているかと各放送は切り離す事が出来ないため、yotube型とpodcast型を組み合わせたコンテンツカードを採用している。
•タブバーの真ん中に録音があることは、発信者の方向を向いているUIと言える

フィード画面

続いてフィード画面を見ていきます

UI要素としては、以下のものがあります。

•ページタイトル
•放送サムネイル画像
•再生ボタン
•再生時間
•放送タイトル
•いいね
•コメント
•チャンネル画像
•チャンネル名

stand.fmのフォローフィードは、YoutubeやTwitterと同様にタイムライン型を採用しています。これとは別に、apple podcastは登録した番組に対しては、コレクションでまとめるという形を取っています。また、他には、spotifyのポッドキャストではエピソードのタイムラインと、番組ごとのフィードの2つのビューを備えていて、それを上部のタブで切り替えるというUIでした。デフォルトでは、stand.fmと同様に時系列順のエピソードタイムラインが設定されており、spotifyはかなり使いやすいUIはだと感じました。

こうした我々の概念モデルを形成する他のプロダクトを見た上で、stand.fmのフォローフィードを見てみると、そのUIにどのような設計思想が反映されていると考える事が出来るでしょうか。

youtubeやTwitter、spotifyに見られるエピソードのタイムラインには、新規性を重要するという思想が伺えます。つまり、今さっき投稿されたとか、今日投稿されたことによって、各エピソードが意味を持つということです。一週間前に投稿されたツイートや投稿動画よりも、今さっき投稿されたものに意味があるということです。
stand.fmもこの思想を根本に持っているため、フィード型を取っていると言えるでしょう。逆に、apple podcastは重めのコンテンツかつ、最新性を重要しないコンテンツが多く存在するため、コレクション型を取っていると推察されます。（例えば、学習系のコンテンツはあまり最新性を重要としません。）

つまり、これらの事を総合して考えられることは、投稿されるコンテンツの内容、尺などによって、タイムライン型を取るかコレクション型を取るかが変わってくるということでしょう。そして、stand.fmはコンテンツの内容的に、最新性を重要視するため、タイムライン型をとったと考えられます。

しかし、ここでもある疑問が僕の中に生じました。

「タイムライン型を取るのであれば、投稿日・投稿時間を要素として含ませるのが必須ではないのか？？？」

この疑問に向き合うために、今まで通り、既存のサービスのUIを見てみます。すると、タイムライン型を取るアプリのほとんどが投稿時間を要素として持っている事がわかります。

※podcastはコレクションビューの上部タブから、エピソードごとフィードに飛んだビューです。また、spotifyも同様に投稿日の要素を持ちます。

こうした既存のサービスにはついている投稿日時がなぜ、stand.fmにはないのか。結論から言うならば、おそらくstand.fmはまだこれら既存のサービスと比べると、コンテンツの量がまだ充実していないことを暗示しているのではないでしょうか。すなわち、最新性を重視してタイムライン型を取る一方で、管理する必要のあるフォロー対象がそこまで多くない。という事です。こうした状況においては、日時を掲載しなくても、他のコンテンツとの相対的関係から大方、日時が想像されます。なので、これはあくまで予想ですが、stand.fmが今よりさらに盛り上がって、フォローして管理する番組が増えてくると、日時の要素が追加されてくる気がします。要するに、現時点で開発リソースを割く優先度がそこまで高くないからだと思われます。

そして、次に僕が着目したUI要素は「いいねとコメント」です。

なぜなら、ホーム画面（トップビュー）の各コンテンツカードは、この2つの要素を持っていないのに、なぜフォローフィードのコンテンツカードでは表示したのか。という点が気になったからです。

ここでも既存のサービスのUIからなにか着想を得られないか試みます。
spotifyのポッドキャストやappleのポッドキャストなど、ポッドキャストサービスは、機能要件としてそもそもいいねとコメントの要素を持ちません。
したがって、フィードにおいても、当然そのような機能の記載はありません。しかし、stand.fmにはコメント、いいね機能が存在します。これは当然、番組に対するリアクションを可視化する事で、ユーザー同士のインタラクションを活性化させる事が狙いでしょう。いいねとコメントを機能要件としてつけるということは、恐らく、そのサービスをある種、インタラクション、コミュニケーションの場として定義することになると僕は考えます。その意味で、stand.fmはこれの機能を採用したと考えます。しかし、一方で、ではなぜ、この2つの要素を、ホーム画面のコンテンツに要素として含ませなかったのかという点が、やはり気になります。

Youtubeではホームフィードと、登録チャンネルのフィードでは、各コンテンツは同じUI要素を持っています。これはある意味、登録チャンネルでの各動画が持つべき情報と、ホームでの各動画が持つべき情報が一致している事を意味するでしょう。

この理論から考えると、stand.fmはフォローフィードと、ホーム画面では、各番組の持つべき情報（伝えたい情報）が異なる事が推測できます。では、具体的にどのような、違いがあるのか？

stand.fmのホームとフィードの伝えたい情報の違い 

•ホーム画面では、いいね・コメントに左右されずに、それぞれのエピソードを同列のものとして扱ってほしい。→いいね・コメントの影響を各番組が受けるべきでは無いと考えたのではないか。
•フィード画面では、逆にそうしたいいね・コメント数依存のコンテンツ間の差分を表現したかった。

僕らはYoutube動画をホームビューから見るとき、再生回数が多いものを「イマ伸びている動画」として認識して再生します。これは、ある意味では参考になるとも言えますが、他方で、各動画へのバイアスがかかる事も意味しています。こうした、いいね・コメント数から来る「盛り上がりのバイアス」をなくして、より多く、幅広いコンテンツが存在する事を確認して欲しいという設計思想に基づいてstand.fmのホームは設計されたのではないでしょうか。逆に、stand.fmのフィードの方は、各エピソードは興味のあるコンテンツとして既にユーザーが認めたものであるため、それらにはいいねコメント数からくるバイアスを認めているということでしょう。

一旦、フィード画面のUIに対する考察をまとめておきますと、

📍フィード画面のまとめ
•各エピソードの新規性を重視しているため、時系列順のタイムライン型をUIとして選択した。
•ホーム画面では、いいねコメントによるコンテンツにかかるバイアスをなくし、幅広い番組があることをユーザーに伝える設計。他方、フィード画面では、そうしたバイアスからくるエピソードへの影響を認めている。

検索画面

お次は、検索画面を見ていきます。この検索画面は、ホーム画面上部の右上にあるアイコンからのみアクセス可能で、専用のアイコンはタブバーには用意されていません。

このビューが持つUI要素としては、

📍UI要素
•戻るボタン
•検索フォーム
•キャンセルボタン
•番組画像
•番組タイトル
•投稿者名
•フォローボタン

まず考えたいのは、検索用のタブバー、もしくはナビゲーションバーが存在していないという点でしょう。今まで参考にしてきた、音声コンテンツアプリの概念モデルを形成する上で役に立っていると思われるアプリ達は、軒並みタブバーもしくはナビゲーションバーに、検索アイコンを持ちます。

こうして見ると、ますますstand.fmが検索アイコンをタブに持たないの不思議に思えます。今回ももちろん、なぜなのかを考えていきましょう。僕がここで着目したのは、「stand.fmのリスナーがどこから流入してくるのか」という点です。多くのコンテンツ系のアプリ、及びSNSにおいては各コンテンツへの最初の到達が、アプリ内で完結しているケースが多いのでは無いでしょうか。もちろん他のサービスからの流入も多いものの、かなりの数のユーザーがアプリ内での検索機能を使って流入していると思います。
では、stand.fmはどうでしょうか。これはあくまで推測ですが、stand.fmを設計した方たちは、検索からの流入をそこまで想定していないのだと思います。そうであるのならば、どこからの流入を想定しているのか？答えは明白で、ホーム画面とSNSです。先程、フィード画面のときも少し触れましたが、stand.fmのホーム画面は、幅広いコンテンツが存在することをユーザーに伝える事を重要視しています。そのため、このホーム画面で特定の番組に興味を持ってもらって、そこからチャンネルビューへ移行、フォローという動線を強く意識しているのでしょう。また、SNSからの流入に力を入れている事は、他サービスへのシェア画面にかなり力を入れていることから明白でしょう。

これら2つの理由から、stand.fmは検索ボタンをそこまで重要視していないことがわかります。この場合も、いずれコンテンツが充実してきたら、検索アイコンがタブに追加される可能性も大いにあると思います。

いよいよ検索ビュー自体の考察に入っていきます。
まず、上部の戻るボタン、検索フォーム、キャンセルという構成は、かなりapple musicとapple podcastのUIを継承しています。
違う所は戻るボタンが存在する点ですが、これは、stand.fmに検索タブが存在しないため、ホーム画面に戻るために必須であると言えます。

僕がこの画面のUI全体を見て着目したのが、アクティブなボタンに使われているカラーについてです。通常、デザインの一貫性を保つために、アクティブカラーは1色であることが多いように思われます。この画面で僕がアクティブな要素として捉えているのは、キャンセルボタンとフォローボタンです。最初に載せたスクリーンショットを確認してもらえば分かる通り、キャンセルボタンには水色、フォローボタンにはピンクが使われています。着目すべきは、キャンセルボタンに使われている水色です。サービス全体のアクティブカラーとして、ピンクを使っているにも関わらず、ここでは水色が使われているのです。この水色は、僕が触った限り、他のどのビューのアクティブなボタンにも出てきていません。つまり、ここでのみ使われているアクティブカラーという事です。ここで、検索ビューが類似しているmusicとpodcastのUIを確認してみます。

ご覧の通り、どちらもキャンセルボタンには、アプリ全体のアクティブカラーと同様の色であるピンクと紫が使われています。つまり、通常であれば、キャンセルボタンの色はアプリ全体のUIに一貫性をもたせる意味でも、ピンクであるべきなんです。だからこそ、ここで水色を使っている事には、それなりの理由があると僕は考えました。apple musicやpodcastの検索結果にあって、stand.fmだけが持つ検索ビューでの要素は何でしょうか？それは、フォローボタンです。そしてこのフォローボタンの内部がピンクで塗られているというデザインをとったがゆえに、キャンセルボタンには水色が使われていると考えられます。フォローボタンで画面上のかなりの面積の色をアクティブなピンクで覆っているため、キャンセルボタンをピンクにすると全く目立たないんですよね。試しに、僕が、キャンセルボタンにも同様のピンクを当てた例を載せておきます。

どうでしょう。デザインとして一貫性は感じられますが、オリジナルよりキャンセルボタンが目立たなくなりました。ただ、アクティブなカラーを揃えるというのは、アプリを設計する上で大切だと思うので、おこがましいながら、改善するとすれば、Twitterのユーザー検索ビューと同様のUIを採用することである程度改善すると思われます。すなわち、フォローボタンの縁と文字にアクティブカラーを使ったUIです。

ただ、この場合、そもそもキャンセルボタンは、検索フォームにフォーカスしたときにのみ現れるUIとなるので、ページの遷移の仕方が変わってしまうかもしれません。なので、ページ遷移の関係上、キャンセルに水色を使うというのは、ある種仕方のないデザインだったのかもしれません。今回ここでこのフォローボタンについて言及しましたが、フォローボタンの話はまた後で登場します。予告しておくと、＜再生ビューのフォローボタン＞と、＜番組ビュー&検索ビューでのフォローボタン＞の色の使い方が違うんです！！！

検索ビューのUIに対する考察をまとめますと、

📍検索ビューのまとめ
•タブバーに検索ボタンが無いのは、stand.fmへの流入元が検索メインでは無く、ホーム画面とSNSによるものであるから。
•キャンセルボタンに水色が使われているのは、ページ遷移とデザインのバランスを考慮して、仕方なく使われているものである。

再生画面（ハーフモーダル）

左から、元画像、トレース（フォロー外）、トレース（フォロー中）、ボックスモデルです。

UI要素としては、以下のものがあります。

•閉じるボタン
•エピソードタイトル
•チャンネル画像
•番組タイトル
•フォローボタン
•説明文
•シークエンスバー
•スキップボタン
•再生/停止ボタン
•いいねボタン
•コメントボタン
•レターボタン
•共有ボタン

ぱっと見でもかなり多くの要素が存在している事がわかります。

ここで着目すべきはやはり、再生ビューにハーフモーダルを採用している点でしょう。ハーフモーダル内の要素はかなり、apple podcstと類似していました。このハーフモーダルは引き上げると下のようになっています。

引き上げると、下に「次に再生するエピソード」のキューが並んでいます。stand.fmは機能要件として連続再生機能を認めているため、このキューの表示というのは必須でしょう。こちらの場合もかなり、apple podcast 及びmusicと類似したデザインとなっています。

しかし、podcastと比較して決定的に異なる点があります。それは、podcast及び、apple musicでは、このフルスクリーンのハーフモーダル以外は存在しない、つまり、画面半分のハーフモーダルが存在しないという点です。

appleが画面半分のハーフモーダルを採用しているのはsafariの共有ボタンなどが挙げられます。

stand.fmは一見、apple musicと同様のUIを採用しているように見えますが、実際に採用しているのは、共有ボタンのハーフモーダルのUIなんですね。
では、このstand.fmのハーフモーダルのメリットはなんでしょう。それは当然、モーダルビュー内で情報の優先度をつけられることです。すなわち、必要最小限の機能を画面半分で満たし、それ以上の詳細の操作をするときのみ、カードを引き上げてもらうといった形です。

この設計は、safariなどでは、とても有用です。なぜなら後ろのコンテキストを維持しつつ、最小限の重要な操作をハーフモーダルで行うことが出来るからです。現状のコンテキストを維持しつつ、一時的なコンテキストに移行する事ができる。そして必要があれば引き伸ばして詳細に操作を行うことが出来る。これこそが、ハーフモーダルの真髄だと思われます。ハーフモーダルについて詳しくは、以下のnoteとappleのHuman Interface Guidlinesを参考にしました。

では、なぜstand.fmはapple music型のモーダルビューを採用せず、現状のsafari共有ボタン型のUIを採用したのでしょうか。精一杯自分で考えてみましたが、このUIに関しては、僕の知識では、デザイナの意図を推測することが出来ませんでした。僕がUIを独学で学び始めて1・2ヶ月ということなので、ご勘弁ください。しかし、僕が初心者であるからこそ、このハーフモーダルに対する疑問をぶつけておきたいと思います。もし偉い方が見ていたら、そっと教えてくれるとありがたいです。以下、僕の疑問です。

❓ぼくの疑問❓

ハーフモーダルは、現状のコンテキストを維持しつつ、一時的なコンテキストへ移行するために考案されたUIです。先程紹介したnoteの記事の中では、mac の複数ウインドウを、スマートフォンという小さい画面の中で、z軸による表現を用いる事で再現していると、考察されていました。すなわち、なんとか複数のコンテキストを、画面上でユーザーに視認させつつ維持する方法はないかという問いに対する回答が、ハーフモーダルというわけです。これらを前提知識として、stand.fmのUIを見てみると、ハーフモーダルが維持しているコンテキストは何でしょう。すなわち、スマートフォンのz軸において、ハーフモーダルの下の階層にある要素とは何なのか。そうです。サムネイル画像及び、番組タイトルになってしまうんです。ハーフモーダルが維持するコンテキスト（＝ハーフモーダルのz軸上で下にあるコンテキスト）は、それ自体でビューとして成立するものが来るのが一般的であるし、iOS標準アプリでの使われ方はこれにあてはまると思います。しかし、stand.fmが維持しているコンテキスト（サムネイル画像と番組タイトル）は、それだけでビューとして成立していないように思われます。
つまり、ここでハーフモーダルを採用する理由がそこに存在していないんです。もし仮に、ハーフモーダルを採用するのであれば、apple musicにならって、フルスクリーンに近いモーダルビューを採用し、その中に、番組タイトル、サムネイル画像を含めるのがUIとして適切なように感じられます。
この場合、ハーフモーダルが維持しているコンテキストは、色々なビューの可能性が考えられます。（ホーム画面、フィード画面、チャンネル画面。どれも単体でビューとして成り立つ。）

長々と、疑問をぶつけてしまってすいません。次の話題に移ります。

次に僕が、再生ビューで着目したのは、フォローボタンの色です。これは、検索画面のところで予告した話です。

すなわち、検索画面とチャンネル画面のフォローボタンは縁とテキストが白で塗りがアクティブカラーのピンク。一方、再生画面でのフォローボタンは縁とテキストがピンクで塗りが白と、両者のデザインに違いがあります。

左2つのフォローボタンと、右のフォローボタンのデザインが違うのに気づきましたか？フォロー機能から連想されるプロダクトであるTwitter,Instagram,YoutubeのUIを確認してみましたが、どの画面においてもフォローとチャンネル登録のデザインは一貫したものでした。ではなぜ、フォローボタンのデザインを1つのビューでのみ変更したのでしょうか。

ピンク塗りつぶしボタンと、ピンクを縁に使うボタンのデザインで決定的に異なるのは、視認性です。画面上でどんだけ目立つかが違うってことですね。それを前提にこのデザインの違いを考えてみると、おそらく再生のビューではそこまで、フォローボタンを目立たせたくなかったのではないかと考えられます。

じゃあ、なぜ再生のビューでフォローボタンを目立たせたくなかったのでしょうか？考察するに、以下の2つの音声コンテンツの特徴が関係している気がしました。

音声コンテンツの再生ビューの特徴

•音声コンテンツの特性上、再生のビューは再生に特化したものである必要がある。
•ユーザーは再生をしている最中、再生ビューの画面を見ていない。

前者の説明をすると、コンテンツの再生をするビューにおいて再生に関係の無い要素を目立たせるのはご法度なのではないかという仮設を僕は立てました。Youtubeを全画面表示にしたときチャンネル登録ボタンはありますか？music系のアプリの再生画面に、再生に関係のない要素がありますか？つまり、そういう事だと思います。ポッドキャストアプリのapple podcastやspotifyにも、フォローボタンは再生ビューに存在しておらず、番組ビューにのみ存在しています。次に僕があげた音声コンテンツの特性の後者の方を説明します。ユーザーが再生中画面を見ていないため、「再生しながらフォローするという導線」は、画面を注視しているYotubeなどの動画アプリに比べて若干弱く、再生中のコンテンツをフォローしたいと思ったときユーザーは、確実にフォローしようという目的を持って再生画面にわざわざ目を向けるので、あえてそこまでフォローボタンを強調する必要が無いという事です。
この理由から、spotifyやpodcastではフォローボタンをそもそも再生ビューにおいていないのでしょう。

では、一体全体なぜ、そもそもstand.fmの再生ビューにフォローボタンが存在するのか？というつぎの問が生じてきます。ポッドキャストや音楽系アプリと同様の設計思想を持つのであれば、そもそもフォローボタンを再生ビューに持たせる必要は無いわけです。それをstand.fmはわざわざ目立たせないようにしてでも、実装したという所に意味があると思います。

ここからは、stand.fmがフォロー機能をかなり重要視している事が伺えます。何としてでも、再生中のエピソードを持つ番組を即時フォローするという導線を確保したかったわけですから、確実にフォロー機能のアプリ内での重要度は高いと言えるでしょう。stand.fmの発信者は短めのコンテンツを比較的日数に間隔を置かず（人によっては毎日）発信しています。これがpodcastと大きく異なる点で、リスナーの側は毎日投稿される多くのエピソードを追っていく必要があります。その意味でこのアプリにおいて、フォロー機能は非常に重要なのでしょう。だからこそ、無理やり（なんとかして）フォローボタンを再生ビューに実装したと考えられます。

またもかなり長くなりましたが、再生ビューのUIに対する考察をまとめると

📍再生ビューのまとめ
•stand.fmのボタンの構成は音楽、ポッドキャスト系のアプリと類似したものを採用している
•しかし、ハーフモーダルの使い方に関しては、若干疑問が残る。
•音声コンテンツ系のアプリにおいて、フォローボタンは一般的には、再生ビューに含めるべきでは無いが、stand.fmはフォロー機能をかなり重要視しているため、要素として再生ビューに採用している。

おまけで再生中の下部に固定されるフローティングカードのトレースを載せておきます。

収録画面

いよいよ大詰め、収録画面です。

僕は、この収録画面のUI（アナリティクス、共有画面も）について考察するためにわざわざstand.fmを始めました。誰か褒めてください。

収録画面のUI要素は以下です。

📍UI要素
•閉じるボタン
•タイトルテキスト
•LIVEボタン
•右端各種ボタン（質問箱、テーマ、BGM、挿入、切取）
•レターボタン
•先頭へボタン
•録音開始ボタン
•再生ボタン
•下書きボタン
•ゲスト招待ボタン

収録画面こそ、stand.fm特有のビューであると言えるでしょう。そのため、ユーザーの概念モデルを構成する上で、想起されるプロダクトは今までのSNS系やpodcast系、音楽アプリとは異なります。恐らくほとんどのユーザーがボイスレコーダー系のアプリのUIを想起すると思われます。

各種ボタンについての考察については今回のnoteでは置いておいて、僕が一番着目したのは、なんといっても、、、、

「真ん中の時間表記」です！！！

なぜここに着目したかといいますと、先程の概念モデルの話を思い出してほしいです。我々はレコーディングと聞くと、ボイスメモなどのアプリのUIを想起します。しかし、そうしたボイスメモで一番大きく表示されるUI要素は、音の振動を表す波形のシークエンスです。しかし、stand.fmは不必要と思えるくらい真ん中の時間を大きく表示しているんです！！これに理由が無い訳がないって事で考察していきます。

参考として、iphone標準のボイスメモとstand.fmを並べた画像を載せておきます。

波形のシークエンスを大きく表示するメリットと、時間を大きく表示するメリットのそれぞれを考えることで、このstand.fmのUIに見えるデザインの意図が見えてくると僕は考えました。

波形のシークエンスを大きく表示することのメリット
•音量の管理、及び音声の編集がしやすい点

時間表示を大きくするメリット
•収録時間を強く気にすることが出来ること
•編集時などに現時点で再生している時間がわかりやすいという点

この両UIのメリットを鑑みた上で、stand.fmが後者の時間を大きくするUIを採用した理由を考えてみます。結論から言うと、

stand.fmでは、収録時間を発信者に強く意識させる事で、コンテンツの尺をかなり気にさせるようにしており、結果として、短めのコンテンツを発信者が発信するように促している。また、編集機能（切取りなど）自体はそこまで設計上、重要に考えられておらず、あくまで最小限の機能として備えている。

では、なぜ、stand.fmは短めのコンテンツ作成を促しているのでしょうか？

答えは「レター機能」をサービスの中心に据えているからだと推察しました。

レター機能とは、「質問箱」や「Box Fresh」のような発信者への質問をリスナーから集め、配信者はそれに答える形で音声の収録が出来る機能です。

このレター機能の魅力としては、以下のことが考えられます。

発信者側
•音声コンテンツの質を保つ上で課題となる、「話題」に困る事がない。
•リスナーが自分に興味を持ってくれているという承認欲求が満たされる。
リスナー側
•自分の行動に、相手がレスポンスしてくれるという喜び
•自分が困っている事に対する意見を貰える

そして、こうしたレター機能のメリットを活かすためにも、コンテンツの尺は短くあるべきで、そのために時間を強く意識させているのではないかと推測しました。その理由を、例を用いて説明します。

ある発信者がstand.fmの収録に確保できる時間が30分だとします。その発信者に対してレターが5件来ているとして、発信者が時間を気にせずに最初の質問に対して30分使ってしまったとします。そうすると、1/5のレターにしか対応されないわけです。設計者の視点に立つと、レター機能を盛り上げていくためには、まずレターを送ってくれるリスナーを確保する必要があるわけですが、ここでリスナーの視点に立つと、リスナーがレターを送るインセンティブは、「もしかしたら、私の質問に答えてもらえるかも」という期待値に基づいています。なので、先程のケースのように、1/5しかレターに回答が無いと、レターを送るリスナー側のインセンティブがどんどん弱くなっていってしまうんですよね。したがって、レター機能を盛り上げていくには、各エピソードの尺をある程度短めにおさめて、多くのレターに答えてもらえるように発信者を促す必要があるわけです。

質問箱のサービスなどではある程度、文章の量が限られているので、回答の長さには限度がありますが、音声コンテンツの場合、1つの質問に対していくらでも話せてしまうというケースが少なく無いと思います。そうした音声コンテンツの特徴を上手くコントロールしているUI設計である気がしました。

そして、この時間表示を大きくする為に、波形のシークエンスのサイズが犠牲になっているわけですが、ここからは、stand.fmのコンテンツは短めであるため、編集の機能はそこまで必要ない（＝一本撮りの場合が多い）事が考えられます。必要最小限というわけです。

ただ、実際にstand.fmを発信者として使ってみたからこそ分かったのですが、いざ要らない部分の切取りなどを行おうとしたとき、この波形のシークエンスが小さいというのは、かなり使いづらいUIとなっていました。具体的には、以下の点に問題があると感じました。

📍編集時の再生ビューの課題
•切取り時するときに掴む部分が、小さすぎるので、切取り開始から切取り終わりまでが短いときの切取りがかなり難しい。
•波形が小さすぎて、波形で音の判断をするのが難しいかつ、たまに音があるのに、波形上変化が無い。
•切取り開始と切取り終わりの部分に、再生位置を合わせるのが手動（ボイスメモでは、切取り開始位置、終了位置に再生位置を固定出来る）
•たまに、シークエンスがバグを起こして、チカチカする

個人的には、シークエンスにフォーカスしたときにシークエンスが大きく表示されるようなUIか、iPhoneのボイスメモのように、クロップ位置の指定用のUI要素を追加すれば、もう少し使いやすい気がしました。

しかし、この辺りは、stand.fmがそこまで音声の編集を想定していないと考えられるため、開発リソースを割く優先順位が低いのだと推測できます。むしろ、ローンチしてわずかな時間でここまで使いやすいUIであることが素晴らしいと思います！これからの対応に、是非注目したいと思います！！

収録画面のUIについての考察をまとめますと

📍収録ビューのまとめ

•stand.fmはレター機能をプロダクト設計の中心に置いており、そのメリットを活かすために、時間表示を大きく表示し、波形シークエンスは小さめにしている。
•波形シークエンスが小さいことから、stand.fmのコンテンツは短めかつ、一本撮りが多いため、編集の機能を抑えている事が推測できる。
•しかし、こうしたUIのため、いざ編集をしようとなると少し課題が残るが、現時点で総合的にはかなり使いやすいUIである。

アナリティクス

自分が配信を初めてみて気づいたのですが、stand.fmにはアナリティクスの機能があります！視聴回数といいね、コメント数のみではありますが、配信者のモチベーションを高める上で、非常に重要な機能だと思います。この辺りからも、stand.fmが発信者をサポートしているプロダクトである事がわかります。UIについての考察は特に無いです。

まとめ

ご拝読お疲れさまでした！！！自分自身も執筆おつかれさま！！！
正直に言いますと、めちゃくちゃ疲れました。まさか17000字も書いてしまうとは、思いませんでした。その反面、一つのプロダクトに全力で向き合ってみると、かなり学びを得られた気がします。

ここで、UIについて独学で勉強し始めてから1,2ヶ月ほどのひよっこ学習者かつ、頭でっかちな文系大学生が、stand.fmのUIトレースをしてみて分かったことをまとめます。

🛎まとめ
音声コンテンツ市場を伸ばす上でボトルネックとなっているのは、いかに配信者層を取り込むかであり、stand.fmはその課題に対して、以下の方法で向き合っている。
•使いやすいUI
•徹底して、アプリの特徴を伝える設計
•レター機能

そして、現時点のUIでは実装されていないものの、今後、改善されていきそうなUIは

🔥改善されそうなUI
•フィードビューの投稿日時に関する情報
•再生ビューのハーフモーダルの使い方
•検索ビューのキャンセルボタンの色
•番組だけでなく各エピソードの検索機能
•収録ビューの編集周りのUI

おまけ（感想）

stand.fmのUIを研究する為に、自らが配信者になるという行動を僕は取ってみたわけですが、やってみるとなかなか楽しいです。stand.fmが口を酸っぱくしてユーザーに伝えようとしている「あなたも配信をはじめてみよう」というコピーにまんまと引っかかってしまったわけですね。

この「全力でUIをトレース」はシリーズ化していこうと思っています。興味を持っていただけた方は、僕のTwitter及び、stand.fmをフォローしていただけるとありがとうございます！

つぎは、kurashiruの坪田さんに頂いたデザイナー課題に取り組む前に、kurashiruのUIを全力でトレースしていくつもりです！！本当に、長々と僕の駄文に付き合ってくれてありがとうございました。これを読んでくれている未来の誰かの参考になれば嬉しいです！