制作物紹介2020年2月2日に「パパダッシュ!!」というWebアプリを作成しました。このWebアプリは家事・育児で悩む人がパートナーに向けてヘルプを出しやすくするサービスです。※私にはヘルプを出す奥さんもいないのに、思いつきで作ってしまいました。この記事では個人開発に興味をもっている方向けにパパダッシュをリリースするまでの考え方と出してみた結果についてご紹介します。最後にリリースした後のユーザーの反応リリースの告知は自分のtwitterのアカウントで行ったくらいですが思った以上の反応をいただけました。2020自分の見立て通り、困ってる事と解決の方法が結びつけれそうで多くの方から好評を頂いています。いう考えから作ったのか自分で作っておいてなんですが、機能的にはテンプレートをチェックしてそれをページとして公開できるだけなのでシステム的にはどこにでもある平凡なものです。好評であったかを振り返ると自分のデザイン(設計)がユーザーにフィットしたからだと自画自賛します。Webデザイナはかっこいい画面を作るのではなく課題解決を目的とすることが本来期待されてる役割だと考えています。今回考えていた夫婦間の課題は、「相談のしにくさ」と考えていました。仲が悪いわけでもないのに「相談がしにくい」とはどんな状況なのかを考えたときに、「申し訳無さ」といった罪悪感があって言い出しにくいという仮設を立ててこのアプリを設計しました。そこでアプリのようなテンプレートで書き出せれば、言い出しやすい(メッセージで送りやすい)のではと思いこのアプリの設計が始まりました。ユーザーは「家事・育児の負担が大きい人」「外で働き、家事・育児をサポートする人」の2軸で考えました。このアプリで重要なのは言うまでもなく「家事・育児の負担が大きい人」です。この方が言い出せなければ、サポートができない状況になるのでなるべく考えず簡単にフォローを依頼できるという体験を重要視しています。サポートする人が自然にフォローの依頼を受け取れる気持ちになれるかというあたりを次のフェーズで重要視して設計しています。この2つの体験が概ね問題なければこのアプリで達成したいことは実現できるので、それらを実現するフローや機能を精査してつくりました。ユーザーから好評だったところ一番多かったのが、「これなら私でもできそう」といった自分が気がついていないアプリ自体のニーズです。チェックして送るだけなのでそのシンプルな設計が受け入れられました。リリースする前はシンプル過ぎて「これなら直接メッセージを送るわ」とか言われたら仮設が大外れになるのでその点が受け入れられてよかったです。あと「家事・育児の負担が大きい人」の「今の気分」を必須の選択制にしてるところがピンポイントで褒められました。これは「家事・育児の負担が大きい人」の振り返り的な意味と「外で働き、家事・育児をサポートする人」がどのくらい今大変で助けを求めてるかの指針になるため必須の機能として入れていました。気分の選択制はアプリならではの機能なので設計がフィットしていてすごく嬉しいです。以外だったこと私は過去(2017年)に「俺の嫁が可愛い」というサイトを作って、人生できっと最大であろうバズを起こしたことがあったのですが、その時の印象に引っ張られてか今回作ったパパダッシュも「優しいインターネットの世界をまた作った」などを言われることが多かったです。2020コンチさんがまた優しい世界を作ってる!流石だなぁ。2020他にも俺の嫁が可愛いを作った人はいつも穏やかな世界を作るなど、べた褒めされてしまい自分が褒められてる感覚が実はあまりなかったりします。自分としてはニーズがあるもの(課題解決をできるもの)を作るのは当たり前とか自分のスキルが活かせて嬉しいみたいな感覚で、優しいとか世界平和みたいな感覚で作っていないので「第三者からだとそう見えるんだ...」というのがとても驚きでした。Webデザイナがアプリを一人で作るのか改めてお断りしますが、私はWebデザイナであって、エンジニアではないです。エンジニアでなくてもパパダッシュくらいのWebサービスは作れます。誤解というよりは私の信念なのですが、令和のWebデザイナは設計だけではなく、改善も求められてると考えています。Webデザイナはコードが書けなくても良いみたいな風潮があるのは知っていますが、自分としてはコード書けないWebデザイナは半人前という目で見ています。(ケースに寄りますが)このあたりの話はこの記事の本筋ではないのでご興味ある方は下記の記事を御覧ください。Webデザイナーのコーディング不要論のついて思うこと現役Webデザイナーが将来性とキャリアについて考えてみた私が自分でコードを書く理由は改善のためです。私はそれほど優秀なデザイナとは思っていないのですが、改善は得意と自負しています。そのため、基礎設計を最速で行い仮説検証をしてサービスを育てられます。その品質の担保のために自分でコードを書いて仮説検証をする必要があるという考えの元、今のスキルに行き着きました。仮説検証において優秀なエンジニアが必要かと聞かれたらそれほど重要度は高くないですが、仮説検証において優秀なデザイナが必要かと聞かれたら必須だと答えます。理由はあえて言わなくてもいいと思うのですが、一発目で作ったデザイン(設計)でうまくいくなんて無理ですし、リスクが高すぎます。そこで設計しかできないデザイナが改善をしようとしたときにコードを書くという壁が出てきます。コーダーやフロントエンドエンジニアがいたらデザイナはコード書けなくても大丈夫みたいな話を聞きますが、個人的にはその論調には否定的です。コーダーやフロントエンドエンジニアをユーザーに受け入れられるかどうかわからない仮説検証でデザイナが振り回して一体何割の人がついてくるのかが疑問だからです。ストレートにいうと自分で設計したものなら自分で責任持って作ろう。それができないなら自分でお金払って完成させよう。そのための「プロのデザイナ」だろう。いうくらいの心づもりがデザイナには必要だと思っています。※私個人の考え方です。そのため私は自分で仮説検証をして改善をするためにCSS/JavaScript、解析周りといったスキルを身に着け今のようなアプリを作れるスキルを身につけました。このあたりはWebデザイナという言葉で括るよりはUXデザイナーのほうがニュアンスは近いかも知れません。いう技術構成で作ったか技術には疎いので、そんなに自信をもって強調するするものでは無いのでですが以下の構成で作りました。(サーバー)この構成で作った理由はこの書籍を読んだからです。モバイルアプリ制作入門ionicは2年前にホウビンゴというアプリを作りました。当時のことは下記にまとめていますのでご興味がある方は御覧ください。Webデザイナーが3日でスマホアプリを公開した方法このとき読んだionicの本は先程紹介したionic本の過去作です。新しくなったionic本はionic4対応でコードが直されているのと、firebaseを使った開発が書かれているのでその点だけでも十分な価値の情報でした。余談ですが、ionic本を読んでからionic3で作ったホウビンゴをバージョンアップさせています。書籍の中でfirebaseはAuth認証とDatabeseについて書いてあり、パパダッシュ!!でもそのあたりのコードがかなり参考になっています。コピペで作ったとは言わないですが、パパダッシュ!!のコードはこの書籍に書いてあることが7,8割だと思います。リファクタリングについてやコンポーネントの作り方など、まだまだパパダッシュ!!に落とし込めていないコードもあるので、そのあたりは今後進めていきたいと思います。本を読むだけでは自分はなかなか理解が薄いので、こうやってアプリを作って理解力を高めています。前作は3日で作ったのですが、今回は年末年始を書けて作るつもりだったのがおもったよりfirebase周りで手こずってしまいモチベーションが落ちてしまいましたが、日を空けて本を読み直したらなぜかスラスラ頭に入ってきたので、そのままの勢いでリリースまでできました。今回は画面の数も少なかったのでmiroで必要そうな画面を書き出して導線を整理しました。ユーザーの導線、緑のところはシェアされてそれを受け取ったユーザーの導線として分けています。普段ならSketchなどを使って画面を作りながらやっていくのですが、ionicがUIフレームワークなのでインブラウザデザイン中心で作りました。インブラウザデザインは時間はかかると思われやすいのですが、やってみると改善が当たり前なので本質的なところに気が付きやすく最近はこっちでやるほうが最終的に質が高いものを出せると思っています。苦労したところログインしてる人とそうでない人はページにアクセスした時の挙動の管理に結構頭を悩まされました。基本的にはfirebaseのDatabeseには振り回されっぱなしで、正直ionic本がなかったらパパダッシュ!!のリリースはできなかったと思います。(というか作ろうとすら思わなかったかも)試行錯誤と言えば聞こえは良いのですが、やってみて失敗を繰り返したからこそionic本に書かれてたことが理解できていきました。いった意味ではすごく価値のある情報でした。今後もログインやDBをつかったWebサービスはつくっていくのでこの苦労は決して無駄にならないと思います。数も作って慣れていきたいです。マーケティング戦略で気をつけたところWebサービスやアプリは使ってもらってなんぼなのですが、まずは認知をしてもらうことが何より重要と考えています。今回の場合は仮説を立てたものの自分の周りでユーザーになってくれる人はいないので、なんとかユーザーをネットで見つけるというのが重要な課題でした。余談ですが、私自身妻も子もいないのでユーザーと程遠いところにいます。なんで作ったかと聞かれたら「思いついちゃったから...」みたいな軽い気持ちです。twitterでシェアを多くもらうためには下記のことが重要だと考えました。わかりやすい(思えやすい・口にしやすい)サービス名アカウント登録なしでも始めて体験できるユーザーに刺さりやすい言葉を使うシェアしやすいLP・ツイートを用意しておくパパダッシュ!!というサービス名についてサービス名は当初sosとselfをかけ合わせたような名前で考えていましたが、口にしにくい、読みにくいなどあまり乗り気ではなかったです。最初はパパとかママとかサービス名に使えばいいかと考えていたのですが、多様な家庭環境があるので閉鎖的イメージのサービス名はやめようと考えていました。利用シーンを想像してる中で「パパダッシュ!!」と思いついてしまい、めちゃくちゃしっくり来たので意識をかえてこのサービス名にしました。口にしやすい・覚えやすいサービス名としてはニーズを抑えたものだと自負しています。リリースしてから反発や疑問を投げられましたが、説明したら納得はしてくれました。リスクはあるのは承知の上での決断ですが、結果的はこの「パパダッシュ!!」というサービス名があったからこそこれだけの反響を得られたと思っています。集客の戦略パパダッシュ!!については初動が今後の命運をかけるといっても過言ではなかったので、目標は一人ガチユーザーを見つけてその人からフィードバックをもらうということです。コミュニケーションを取れるユーザーは何人かと繋がれたのでここ数ヶ月はこの人達と向き合って改善はできるので大成功です。成功するためには運だけでなく戦略も必要で、シェアをもらうための戦略で一番シンプルなのが共感です。今回はこのツイートに乗ることで世間的に共感されやすい時期にリリースすることにしました。今日リリースしたパパダッシュ!!ですがこの投稿みて作る気が起きました。※もともと中途半端には作ってたけどリリースするまでのモチベーションに仕上がったのはこちらの投稿のおかげです。2020これだけのシェア数のある投稿ということはそれだけ共感しているユーザーがいるということなので母数としては文句のない戦場で戦うサービスだというのは証明されていました。あとはここからどれだけシェアをもらえるかです。シェアをもらうためにはパパダッシュ!!が有用なサービスと理解してもらう必要があるのでアカウントの登録不要なゲストアカウントのようなものを準備しました。これが功を奏して、ログインユーザーの8割はゲストアカウントでログインをされています。一応リリース4日時点で600人弱の方がゲストアカウントでパパダッシュ!!を試してくれています。シンプルな設計なので、クリックを数回するだけで全容が見えるので多くの方がサービスの中身を理解してくれました。こんな感じで利用キャプチャ動画を作ってくれる人もいるので嬉しい限りです。2020個人サービスの製作者の集客方法としては「持たざる者」の集客方法というのがとても参考になります。以前バズった「俺の嫁が可愛い」はこの記事にかいてある「任意拡散タイプ」になります。反響がとても取りやすいサービスだったので、自分のツイート以外でもサイト内の投稿がシェアされてどんどん人を呼び込むようなサービスになっていました。今回のパパダッシュ!!では任意拡散を狙ってはいますが、コンテンツでのシェアはほぼ期待できません。コンセプトに対しての任意拡散になります。私が次に狙ってる任意拡散はユーザーが実際にパパダッシュ!!を使って「楽になった」「改善された」という投稿をしてくれることを狙っています。ユーザーがそういったパパダッシュ!!で解決できたという投稿をしてくれたら私のシェアの比ではないと予想しています。私のフォロワーは技術者系が多いのですが、当事者であれば似た悩みを抱えてる信頼関係のあるフォロワーが」いるはずなので説得力が段違いになります。そのためにはきちんとユーザーの課題解決に向き合ったデザイン(設計)が必要になるのでやりがいがありますね。シェアしてくれた属性の変化について2月2日にパパダッシュ!!は公開したのですが、初日は知り合いの技術者が中心にシェア・いいねをしてくれました。3日は知り合いでなくても、Webデザイナ、個人サービス開発系の方々から反応をもらえました。この頃から、ママWebデザイナーといった方々から反応をもらいはじめました。4日からはマタニティ垢の人たちにも届いて、ユーザーの声が拾いやすくなり成功を感じました。その後5日までは順調に伸びたのですが6日に落ち着いたって感じです。シェアの数字で見ているところシェアはされたらされただけ嬉しいのですが、私はもう一つ数字を別の視点で見ています。それはリツイートといいねの比率です。俺の嫁が可愛いの投稿のときに気がついたのですが、リツイート数の方が多いです。これは自分が見たい・好きを超えて積極的にシェアしたい良いコンテンツの傾向なのでは?と仮説を立ててバズった投稿を見ていますが、リツイートの方が多いのはかなり珍しいです。2017パパダッシュ!!もシェアの反応を見てたのですが、リツイートのほうが多くなることはなかったです。言え、リツイートがいいねの倍以上あるのでそれなりに共有したい良いコンテンツを作ったのではないかと自負しています。今後の改善ユーザーから頂いたフィードバックを中心に改善した後は、サポートする側をいかに舞い込みやすくするか、手伝いやすくするかの改善をしようと思っています。リリースしてみて思ったのですが、この点の設計がまだ甘いもっと改善できそうという気持ちがあります。改善ではないのですが、Android版・iOS版のアプリを出す予定です。ionicで作っているので、いつでも出せるのですが検証が増えてしまうので、タイミングは躊躇しています。できれば好意的なレビューで整えたいのでパパダッシュ!!のファンができてからアプリ配信を考えようと思っています。マネタイズについていくつか考えているものはあるのですが、マネタイズはおそらく買い切りの機能解放になると思います。いえパパダッシュがきちんとユーザーの課題解決につながると自信が持てたタイミング以降でだすのでまだ先になると思います。最後にパパダッシュ!!で今回のような反響をいただけたのはデザイナとしてとても自信がつきました。俺の嫁が可愛いの反響が大きすぎて、一発屋感が自分のなかでずっと合ったのですがこの数年間で身につけたスキルは誠実にユーザーと向き合ってるものと証明できました。ものすごいアプリを作ったわけではないですが、自分が今後やっていきたい分野での小さな成功体験をできました。今回ionic本で学んだfirebase周りの知識を活かせれば作りたいと思っているサービスがまだまだ作れそうですので、今年はそういったアウトプットの年にしていきたいと思います。パパダッシュ!!は未熟なサービスですが、結構いい線ついてるサービスだと思いますので今後とも宜しくお願いします(ゝω・)パパダッシュ!!ツイートこの記事を書いた人conti大阪で東京の事業会社でフルリモートワークで働いているWebデザイナーです。副業とか好きで週末フリーランスしてます。コードを書くのが得意なのでプログラマーに愛されるデザイナーってよく言われます。ジムに通う人向けに筋トレログアプリを作った最近ionicでアプリを公開していなかったのですが、ようやく一つ公開できました。先月からジムに行き始めたのですが、ジムにいつ行ったか、何をしたかを思い出せないので記録をつけれるWebアプリを作りました。制作物紹介nuxt.jsで使うLPをさくっと作るためのフレームワークを作った最近nuxt.jsにハマりっぱなしで、今後どんどんnuxt.jsでサイトを作って行くくらいに依存しています。制作物紹介イベントサイトをnuxt.jsとsteinhqでサクッと作ってみた。先日旅行先で偶然、日本酒ゴーアラウンドという日本酒を楽しむイベントがありました。このイベントは様々な地域で行われているものの、Webサイトの掲載はその地域の主催者によって情報配信されているようでした。運用ノウハウ開発cntlog。