AI translation
I'm writing an essay. For a while after releasing the app, Lily hadn't shown it to anyone. She had posted announcement tweets on social media and told friends "I'm working on it." But she had never actually handed over her smartphone and said "try using this." She was afraid...
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
I'm writing an essay. For a while after releasing the app, Lily hadn't shown it to anyone. She had posted announcement tweets on social media and told friends "I'm working on something." But she had never actually held out her phone and said "try using this." I think she was afraid. Afraid of getting stuck. Afraid of being asked "what does this mean?" The thought of imagining herself responding "you don't understand?" made her stomach churn. She overcame that fear when she attended a small gathering for indie developers. In the corner of the venue, she said "would you like to try using this?" and held out her phone. Those 5 seconds until the person took it. Today I'm writing about that.
It took six months from the moment I first had the idea until I released the app. I worked on it little by little every night, reviewed the design comprehensively on weekends, and finally reached a state where I thought "this will work."
I implemented all the features I'd decided on initially. I reviewed the design many times. Color combinations, button sizes, tone of text. I checked every single thing myself and refined it until I thought it was "easy to use."
But looking back now, that sense of "easy to use" was entirely Lily's. It was the feel of touching it when you know the design and know how to use it. It's the same as saying "I won't get lost" when you have a map in your head—I wasn't thinking about people without maps at all.
People often say you should have a user perspective. Lily knew the words too. I'd thought about personas and written user journeys. But that was always about "someone Lily imagined," completely different from the moment a real, different person touches the screen for the first time.
There's a phrase called "the curse of knowledge." People who know something well find it hard to imagine how someone who doesn't know it feels. The creator is the person in the world who knows most about their own app. That's precisely why it's hardest to step outside your own map and look at it. I understood that in my body only when I handed over the phone.
During the event's break time, I spoke to someone who was also doing indie development. "Would you mind trying this out?" I was surprised at how nervous my voice sounded.
They kindly said "sure," and took the phone. From that moment, 5 or 10 seconds—or what felt much longer in my perception—of silence continued. Lily watched the other person's face as they stared at the top screen, barely breathing.
"Where should I start?"
That one sentence froze me. There were 4 buttons lined up on the top screen, and to Lily it was an obvious layout. But to them, it wasn't clear which was the entrance. The 4 buttons looked equally important.
After that, small "stumbles" appeared here and there. A finger would pause for just a moment before pressing a button. On one screen, they wouldn't notice it could scroll and would just stay still. On parts I thought "they'd definitely understand this," their finger would waver uncertainly.
Analytics tools can tell you which screen users leave from. But they can't tell you "why they stopped there." When you're watching in person, that "why" comes through in the other person's expression, their finger movements, and sometimes small sounds that slip out. Information that would never appear in data viewed through a screen was right there.
During the test, even when the other person got stuck on something, they didn't immediately say it out loud. They'd think for a bit, try touching again, and only when they still couldn't figure it out would they finally ask "how do you do this?" During that time before they asked, something was happening inside them, but it didn't become words.
Articles about how to do user testing often say "have them think out loud." That's true, but it was hard for Lily to ask a stranger "please talk while you think." So at first I just watched quietly beside them, and only when the stumbling lasted a long time would I gently ask "is there anything that bothers you?"
Kind people will say positive things even when they're struggling. "I think it's easy to use." "The design is cute." Those words are simply delightful, enough to make me feel like it was worth coming.
But in terms of information to improve the work, the silence of that stumbling moment was far more valuable. Not words, but watching finger movements. Remembering where they stopped. Observing what they could see the moment they realized "oh, this is it." Those things never appeared in data.
To be honest, the biggest reason I didn't want to show it to people was that I "didn't want them to get stuck." I wanted them to use it smoothly. When they got stuck, it felt like the me who made it was being rejected.
But when I actually showed it, the feeling of "I found a place to fix" was stronger than the feeling of being rejected. I even felt grateful that they got stuck. And besides, they were taking time to try it out. That act alone was incredibly appreciated, and feelings like being rejected or being tested almost completely disappeared.
In the 5 minutes after handing over something I'd spent six months making, I found 3 places where the design needed revision. The navigation on the top screen, visual hints for scrollable screens, and the delay in feedback for a specific operation. All of them were "obvious problems once you mention them."
If I'd stayed afraid of showing it to people and spent another six months stacking on features, the scope of fixes would have been much larger. People often say it's better to fail early. But the word "failure" felt heavy, and I couldn't quite move. When I reframed it as "it's better to be embarrassed early and small," it became a bit easier for Lily to move.
That night, there were 3 things I wrote down in my notes.
The first was that the entrance on the top screen wasn't clear. Because I'd lined up 4 buttons equally, it didn't convey what to do first. The fix was simple—I narrowed it down to 2 and emphasized only the first action.
The second was that on scrollable screens, it wasn't obvious that they could scroll. Content was cut off at the edge of the screen, making it look like it ended there. I changed it so that content was slightly visible at the edge, showing that there was more below.
The third was that there seemed to be nothing happening while waiting for the operation result to return. There was no indication that processing was happening, and it seemed like they thought it was broken.
All of them were "of course" kinds of fixes. But I wouldn't have noticed without being told. Or maybe I wasn't trying to notice. I was completing everything within my own map, not even imagining where someone without a map would look on the screen.
I want to show the revised screens to that person again. I want to see how they've changed. That's become my next motivation.
Indie development is mostly solitary. Thinking of ideas, designing, implementing, testing—all alone. I continue because I like it, but there's also a sense of getting stuck somewhere. The feeling of moving forward without anyone telling you if you're right or wrong.
Those 5 seconds were a moment when I stepped slightly outside that "solitude." My creation was moving in someone else's hands. The places where they got stuck, the places where it worked well—I could see it all right in front of me. Just that made the six months of solo work feel a little rewarded.
Places where they couldn't use it well are places to fix. Places where they used it well are places to trust. Both are important, and both can only be confirmed outside the screen.
I want to hand over my phone again. Next time I think I'll be able to say from the start "please tell me where you get stuck." My hands, which were shaking back then, have calmed down a bit. Just that feels like I've moved forward quite a bit.
Lily (@bokuwalily) — Indie developer. Making iOS apps and web services in tandem with AI.
エッセイを書きます。 アプリをリリースしてから、しばらくの間、Lilyは誰にも見せていませんでした。SNSに告知ツイートを投げたこともありましたし、友人に「作ってるよ」と話したこともあります。でも「実際に使ってみて」とスマホを差し出したことは、一度もなかったのです。 怖かったのだと思います。詰まられたくなかった。「ここ、どういう意味ですか」と聞かれたくなかった。作った本人が「え、わかりませんか」と返す場面を想像するだけで、胃のあたりがむずむずしました。 その怖さを乗り越えたのは、ある個人開発者向けの小さな集まりに参加したときでした。会場の隅で「よかったら使ってみてください」と声をかけて、スマホを差し出した。相手がそれを受け取るまでの、あの5秒間。今日はその話を書きます。
最初にアイデアを思いついてから、そのアプリを公開するまでに半年かかりました。毎晩少しずつ進めて、週末にまとめて設計を見直して、ようやく「これで行ける」という状態にたどり着きました。
機能の一覧は最初に決めたものをすべて実装しました。デザインも何度も見直しました。色の組み合わせ、ボタンの大きさ、文言のトーン。全部ひとつひとつ自分で確認して、「使いやすい」と思えるところまで仕上げました。
でも今振り返ると、その「使いやすい」という感覚は、全部Lilyのものでした。設計を知っている人間が、使い方を知った状態で触ったときの感触です。頭の中に地図がある状態で「迷わない」と言っているのと同じで、そもそも地図のない人のことを、何ひとつ考えていませんでした。
ユーザー視点を持ちましょう、とはよく言われます。Lilyも言葉としては知っていました。ペルソナを考えたり、ユーザージャーニーを書いたりしたこともあります。でもそれはあくまで「Lilyが想像した誰か」の話で、実在する別の人間が画面に初めて触れる瞬間とは、全く別のことでした。
知識の呪縛、という言い方があります。何かをよく知っている人は、それを知らない人の気持ちを想像しにくくなる。作り手は、自分のアプリについて世界で一番詳しい人間です。だからこそ、自分の地図を外して見ることが、一番難しい。そのことを、スマホを渡して初めて身体で理解しました。
イベントの休憩時間、同じく個人開発をしているという方に声をかけました。「よかったら使ってみてもらえませんか」。自分でも驚くくらい緊張した声が出ました。
相手は快く「いいですよ」と言って、スマホを受け取ってくれました。その瞬間から、5秒か10秒か、体感ではもっと長い沈黙が続きました。トップ画面を見つめている相手の顔を、Lilyはほとんど息を止めたまま見ていました。
「どこから始めればいいですか?」
その一言で、固まりました。トップ画面には4つのボタンが並んでいて、Lilyには当然の配置でした。でも相手には、どれが入口なのか見えていなかった。4つのボタンが等価に見えていたのです。
その後も、小さな「詰まり」がぽつぽつと現れてきました。あるボタンを押す前に一瞬だけ指が止まる。ある画面でスクロールできると気づかずに、そのまま静止する。「ここは絶対わかるだろう」と思っていた部分で、相手の指がふわっと迷う。
分析ツールでは、どの画面でユーザーが離脱したかは分かります。でも「なぜそこで止まったのか」は分からない。目の前で見ていると、その「なぜ」が相手の表情と指の動きと、ときどき漏れる小さな声で全部出てくるのです。画面越しのデータには絶対に乗ってこない情報が、そこにありました。
テスト中、相手は何かに詰まっても、すぐには声に出しませんでした。少し考えて、また触ってみて、それでも分からなかったときにようやく「これってどうやるんですか」と聞いてくれる。聞いてくれるまでの間、その人の中では何かが起きているのですが、それは声になりません。
ユーザーテストのやり方を書いた記事には「口に出して考えてもらいましょう」とよく書いてあります。それは正しいと思いつつ、初対面の人に「考えながら話してください」とお願いするのは、Lilyには難しかったです。だから最初は静かに隣で見ていて、詰まりが長く続いたときだけ「何か気になる部分はありますか」とそっと聞く、というやり方にしました。
親切な人ほど、困っていてもポジティブなことを言ってくれます。「使いやすいと思います」「デザインかわいいですね」。その言葉はシンプルに嬉しくて、それだけで来てよかったと思えるくらいです。
でも作りを良くするための情報という意味では、詰まった瞬間の沈黙の方がずっと価値がありました。言葉ではなく、指の動きを見る。止まった場所を覚えておく。その人が「あ、これか」と気づいた瞬間に何が見えていたかを観察する。そういうことが、データには絶対に現れないことでした。
正直に言うと、人に見せたくなかった一番の理由は、「つっかえてほしくなかった」からです。スムーズに使ってほしい。詰まられると、作った自分が否定されるような気がしていました。
でも実際に見せてみると、詰まった場所でLilyが否定される感覚よりも、「直す場所が見えた」という感覚の方が強かったのです。むしろ、詰まってくれてよかった、とすら思いました。しかもその人はわざわざ時間を使って触ってくれている。その行為自体がもうすごくありがたくて、否定されているとか自分が試されているとか、そういう気持ちはほとんどなくなっていました。
半年かけて作ったものを、初めて人に渡してみた5分間で、設計を見直すべき場所が3つ見つかりました。トップ画面の導線、スクロール可能な画面の視覚的なヒント、そして特定の操作のフィードバックの遅さ。どれも「言われてみれば当然」の問題でした。
もし人に渡すことを怖がったまま、さらに半年かけて機能を積み上げていたら、修正の規模はずっと大きくなっていたはずです。早く失敗した方がいい、とよく言います。でも「失敗」という言葉が重くて、なかなか動けませんでした。「早く小さく恥をかいた方がいい」と言い換えたら、Lilyには少し動きやすかったです。
その日の夜、メモに書いたことが3つあります。
ひとつ目は、トップ画面の入口が分からないこと。4つのボタンを等価に並べていたせいで、最初に何をするべきかが伝わっていませんでした。直し方は単純で、2つに絞って、最初のアクションだけを強調するようにしました。
ふたつ目は、スクロールできる画面でそれが分からないこと。下に続きがあるのに、画面の端でコンテンツが途切れて終わっているように見えていました。少し内容を見切れさせることで、続きがあることを示すように変えました。
みっつ目は、操作の結果が返ってくるまでの間に何も起きていないように見えること。処理中であることを示す表示がなくて、壊れたと思われていたようでした。
どれも「そりゃそうだ」という修正ばかりです。でも言われなければ、気づかなかった。というより、気づこうとしていなかったかもしれません。自分の地図の中だけで完結させていて、地図のない人が画面のどこを見るかを、想像すらしていませんでした。
修正した画面を、またあの方に見せたいと思っています。どう変わったかを確かめたい。それが今、次のモチベーションになっています。
個人開発って、ほとんどの時間がひとりです。アイデアを考えるのも、設計するのも、実装するのも、テストするのも、ひとり。それが好きで続けているのですが、どこかで煮詰まる感覚もある。自分が正しいのか間違っているのか、誰も教えてくれないまま進んでいく感覚。
あの5秒間は、その「ひとり」から少しだけ外に出た瞬間でした。自分が作ったものが、別の人の手の中で動いている。詰まった場所も、うまくいった場所も、全部目の前で見えた。それだけで、半年間のひとり作業が少し報われた気がしました。
うまく使ってもらえなかったところは、直す場所です。うまく使ってもらえたところは、信じていい場所です。どちらも大事で、どちらも画面の外でしか確かめられませんでした。
またスマホを渡したいです。今度は最初から「どこで止まるか教えてください」と言えると思います。あのとき震えていた手が、少し落ち着きました。それだけで、ずいぶん前に進んだ気がしています。
Lily（@bokuwalily）― 個人開発者。AIと二人三脚で、iOSアプリやWebサービスを作っています
