imajo

行動経済学 / UX / engineer(Flutter, Rails) / PdM

imajo

行動経済学 / UX / engineer(Flutter, Rails) / PdM

  • プロダクト開発のヒント

    プロダクトの設計をする時に辞書として参考できるように、行動経済学の事例を集めたnoteです。アイディアが出ない時に使ってください。

ものづくりをするにはアウトプットではなくインプットの量を増やせ

自分がものづくりを進めるにあたって意識していることです。 全てを実践できているわけではないし、メンタルの調子によっては普段できているのにできなくなることもあります。 この記事でのインプットとアウトプットの定義アウトプットはキーボードを打っている時。つまりものづくりをしている時。 インプットはキーボードを打っていないがデジタルの前にいる時。記事やAIなどから情報を得ている。 考える時間は、PCから離れぼーっとしている時。ソファーに寝転がったりシャワーを浴びている時。 時間配

imajo

    • タスク管理ツールを使いこなせてないと感じたら始めるタスクリセット法

      個人タスクの管理ツール、使いこなせていますか? 私は使いこなせていませんでした。 いろんなツールを試し、なんとか使いこなそうという一心でした。 タスクを管理する、というタスクが1番大変なのです。 試行錯誤の結果、メモ帳とちょっとしたルールを設けることでタスク管理が楽になりました。 そのルールとは1日1回、全てのタスクをリセットする(消す)方法です。 名付けてタスクリセット法です。 なぜ使いこなせないか?タスクリセット法の説明の前に、課題を理解しておきます。 なぜタスク管理

      imajo

      • 個人開発スタートします。 "何を作る?"を決めるアイディアの条件

        MokurenというChrome拡張を個人開発している@imajoです。 もう1つアプリを作りたいな〜と考えています。しかし、個人開発する上で最初に困るのが"何を作るか"だと思います。 私がアイディアを出す時の条件の考え方をnoteにしました。 個人開発を考えてる人はぜひ参考にしてみてください。 個人開発ならではの視点、含んでます。 課題ドリブンまずは、課題ドリブンであることです。個人開発だと忘れがち。 どんなプロダクトも解決する課題があって、ユーザーはその課題に困ってい

        imajo

        • 個人開発を始める前に決めておかないと後悔すること(お金の話編)

          MokurenというChrome拡張を開発している@imajoです。 開発して早、2年くらい経ちました。今振り返ってみて「もっと早くから決断しておけばよかったなということ」をnoteにしました。 個人開発を始めようと思ってる人は是非参考にしてください。 リリースするかどうか当たり前の話ですが、個人開発ではリリースせず自分や友人だけで使う選択肢もあります。 しかし、個人的にはどんなに小さなプロダクトでもいいし、恥ずかしいと思っていてもリリースすべきだと思います。 なぜなら、リ

          imajo

        ものづくりをするにはアウトプットではなくインプットの量を増やせ

        imajo

        • タスク管理ツールを使いこなせてないと感じたら始めるタスクリセット法

          imajo

        • 個人開発スタートします。 "何を作る?"を決めるアイディアの条件

          imajo

        • 個人開発を始める前に決めておかないと後悔すること(お金の話編)

          imajo

        マガジン

        • プロダクト開発のヒント
          5本

        記事

          【プロダクト開発】報告しずらいリーダーになってしまった話

          個人開発を友人とやっています。 私はモチベーションやコミットできる量からリーダー的なポジションをしていました。 そんな中で、メンバーの作業が終わってない時に「報告しずらい」と言われてしまいました。いつの間にか「報告しずらいリーダー」になっていたのです。 それぞれのメンバーが他に仕事を持っており、コミットできる量が違う。モチベーションも人によって違う。そんな状況から、なかなか進まないプロジェクトと自分たちで決めた締切もあり、「焦り」が「イライラ」に代わってしまいました。 そ

          imajo

          【プロダクト開発】報告しずらいリーダーになってしまった話

          imajo

          Push遷移かModal遷移か

          実装しててPush遷移にすべきかModal遷移にすべきか迷う時があります。 気にかけないと全てpush遷移前提の実装になってしまいますが、言語化しておけば適切な遷移ができます。 PUSH遷移 アプリの目的は基本一つで、それを達成する画面までをPush遷移を利用します。 例えば、noteアプリは「noteを閲覧する」タスクを達成するために一覧からpush遷移で詳細に潜り込みます。 情報は左から右に流れる原則があるため、画面は右から出てきます。これは「一覧画面→詳細画面」とい

          imajo

          Push遷移かModal遷移か

          imajo

          Mokurenでこだわってるユーザー体験を紹介します

          私たちはMokurenというミニマムなプロダクトを作っています。 MokurenとはChrome拡張です。 GitHubのIssueをサイドバーで開けるようにしてくれます。 シンプルなプロダクトですが、細かいユーザー体験もこだわってもいます！ 当たり前すぎて気づかれないところから、『これは画期的だ』というものまで紹介します。 ①オンボーディングで成功体験を作らせるまず最初はMokurenのオンボーディングです。 インストール直後のユーザーはこんな感情を抱きます。 このタ

          imajo

          Mokurenでこだわってるユーザー体験を紹介します

          imajo

          インタビューで意識すること

          インタビューで意識すること 沈黙を恐れない 感情ではなく行動を聞く リンクを踏むように深掘りしていく 『沈黙を恐れない』わかっていても難しい。 慣れるのが一番早い。 『感情ではなく行動を聞く』 嬉しかったとか大変だった...とかでは課題の大きさが掴めない。 しかし、行動は嘘をつかない。 『その時どう思いましたか』を『その時何をしましたか?』に変える。 『リンクを踏むように深掘りしていく』 このnoteが参考になった 「この前何人かでスキーに

          imajo

          インタビューで意識すること

          imajo

          具体と抽象を行き来すると60点から80点になる

          プロダクト開発は難しい。 設計だけを考えていると悩む時間が増える。 手を動かすばかりだと、使われないものが作られていく。 具体だけではだめだし、抽象だけでもだ。 具体と抽象を行き来しないといけない。 なぜだろうか。 具体と抽象はそれぞれを強めるヒントになるからだ。 行き来すると60点から80点になる話をする。 具体と抽象とはプロダクト開発における具体と抽象とはなんだろうか。 具体とはまあ、UIだったり実装だったりユーザーが触れる部分。 抽象はプロダクト全体の設計だったり、

          imajo

          具体と抽象を行き来すると60点から80点になる

          imajo

          noteのスキを消したら本当にスキに出会えた話

          スキの数だけを見てnoteを選んでませんか? みんなと同じものばかり読んでいたら、特別な出会いを逃してしまいます スキの数が多いnoteを良いと思っていました。確かにみんなが良いと言っていれば良いnoteです。だからと言って、みんなが(まだ)良いと言っていないnoteが悪いnoteだとは限りません。 このnoteではスキの数に頼らない出会いと、そのためのツールを紹介します。 スキの数に頼らない出会いは、「みんながいいと思ったから自分もいいと思う」をなくし、自分だけの思考を

          imajo

          noteのスキを消したら本当にスキに出会えた話

          imajo

          最近読んだ面白いnote vol.1

          最近読んだ面白いnoteを3つ紹介するコーナーです。 なんと初回です。 ジャンルに決まりはありません。 でもIT界隈寄りです。 あえて決まったジャンルを読まないことで、新しい知見を溜めています。 余白をデザインするtakashi itoさんのnoteです。 余白の話。 シンプルと言われているデザインは余白がうまく使われています。その余白は見る側に考える余地を与えています。 その中でも面白いと思ったのが「見た目の余白」ではなく、「思考の余白」。 例えば、ディレクターがデ

          imajo

          最近読んだ面白いnote vol.1

          imajo

          UXライティングの神note1つでどこまで自分のプロダクトに応用できるか

          1つの神noteに出会いました。その記事でUXライティングという言葉を知りました。 プロダクトをより良くする者として感動させられ、自分のプロダクトに活用したいと思いました。 しかし、数日がんばったところでUXライターになれるほど甘い職業では無いと思います。ですが、何年も修行しているうちにMokurenはクローズしちゃうかもしれません。今すぐ活用したいのです。 幸いなことに…? Mokurenは課題を抱えています。その課題とはログイン時の離脱率の高さです。その性質上、Gi

          imajo

          UXライティングの神note1つでどこまで自分のプロダクトに応用できるか

          imajo

          UXライティング

          先日UXライティングに出会いました。とてもいい方で今後の私の人生を支えてくれるでしょう。 しかしもう少し歩み寄らなければなりません。そのためにいつでも振り返られるように、とある神noteに書かれている内容をリストアップしました UXライティングのイメージユーザーの行動の矢印をテキストで作ってあげること。 プロダクト内での目的の達成を、テキストでサポートすること。 みやすくするコツ無理に文字を入れなくてもいい。ユーザーにメンタルモデルがあるならアイコンでもいい。 長った

          imajo

          UXライティング

          imajo

          タスク管理をやめられない完璧主義

          タスク管理に時間を取られてしまう。もっと少ない時間でやれることを知っているのに、なぜか時間をかけてしまう。 すでにやることリストには緊急度の高いタスクがあるのに。だったら、すぐタスクに取り掛かればいいのに、タスクの整理をしないといけない衝動に駆られる。 タスク管理ツールのリストは綺麗に、さらには完璧に整理されていて、常にそれを維持したい。 タスクが整理されているのは良いことだ。やり忘れなんてものとは無縁になるし、上司に怒られないのが一番のメリットだろう。 タスク管理の

          imajo

          タスク管理をやめられない完璧主義

          imajo

          ユーザーにとって、悪いPUSH通知の3つ

          唐突ですが、あなたのスマホはこんな感じになっていませんか? 同じアプリの通知が溜まったままの状態です。 PUSH通知はプロダクトにとってユーザーへの大切な外部トリガーである一方、PUSH通知過多はユーザーにとっていつのまにかスルーするもの、無視するものになってしまいます。 その習慣を無視する習慣とよんでいます。 プロダクトに置いての習慣化とは、内発的トリガーを作りあげることです。つまり、PUSH通知や必要以上の広告を利用せずとも、ユーザー自身でプロダクトのことを思い出し、

          imajo

          ユーザーにとって、悪いPUSH通知の3つ

          imajo

          DAZNの通知は5分前だけど、使いづらい?

          ユーザーを行動に移させようとする場合、特に強力なものとして"緊急性"があります。行動経済学の用語に当てはめるなら希少性です。 DAZNの通知 Daznは必ず試合の5分前に通知が来ます。5分という数字はユーザーの設定では変えられません。1時間前、その日の9時…には変更できないのです。 この制約は、ユーザー目線だともっと早く来てくれたほうがいいと思えます。自由度高く設定ができるのは、一見すると便利に思えます。 しかし、「通知が来たらすぐにアプリを開かないと！」という感覚を

          imajo

          DAZNの通知は5分前だけど、使いづらい?

          imajo