翻訳アプリNaniを開発していく中で考えていることについて、頭の整理も兼ねて書き出してみることにしました。この文章はAIを使わずにすべて開発者本人が書いています。
ツールとしての立場をわきまえる
Nani翻訳は業務やコミュニケーションの主役ではありません。あくまでも伝えたいことをスムーズに伝え、知りたいことをスムーズに知るための脇役のツールです。
ユーザーの欲しいものを最短で提供し、シュッとその場の出番を終えるのが理想的な形です。
最短で出番を終えられるよう待ち時間を最小限に、負荷なく使えることが大きな方針となります。
すごそうなUIより、楽なUIに
開発初期にかなり迷った部分ですが、Nani翻訳ではあえて「チャットらしさ」を感じられるUIに寄せています。
従来の入力↔結果が横並びの翻訳UIを大きく拡張したようなデザインにしておけば、より新時代の翻訳ツールらしさや、「ただのLLMのAPIラッパーではない感」を演出できたと思います。
しかし、いくつかの形を試行錯誤していく中で、AIチャットらしさのある上から下へと要素を積んでいくUIが最も直感的で、深堀りしやすく、戻りやすく、取り消しやすく、扱いやすいという結論にいたりました。
スクロールはいいものだ
スクロールというのは現代のインターネットにおいて、最も負担の小さい操作だと考えています。
ボタンやリンクを押すという行為は心理的なハードルが大きなものです。ボタンを押せば、画面いっぱいに広告が表示されるかもしれません。想定していたものと違うページが出てくるかもしれません。戻ろうとしても元の位置に戻れないかもしれません（スクロール位置がリセットされるとか）。
それに比べてスクロールは安全寄りの操作です*。
戻りたくなったときにすぐに元の位置に戻ることができます。 段階的に情報を拾っていくことができます。 人々はたくさんスクロールすることに慣れています。
未来感のあるデザインとレイアウトで表現したくなる気持ちが湧くこともよくありますが、一番使いやすくて楽な形を追求していくと、最終的にスクロールを前提として単純なUIに行き着くことがよくあります。
* ときどき遭遇するスクロールしていくとポップアップが表示されるやつ、人々にスクロールまで警戒させてしまうことになるのでよくない
設定や機能を増やせばユーザーにとっての複雑さも増していく
設定項目（プリファレンス）や機能の追加は、コードベースだけでなく、ユーザーにとっての複雑さや認知負荷も高めます。特に新規ユーザーやライトユーザーにはこの影響を受けやすい傾向があります。
AIの進化で複雑なコードベースであっても、ガンガン機能追加することも可能になりました。同時に、ユーザーにとっての複雑さは気づかないうちに深刻化しやすくなりました。
Nani翻訳を開発していく中で、トップページのファーストビューにボタンが一個増えるようなものについては、本当にやるべきかしばらく寝かせて考えるようにしています。
機能追加による価値向上と、増す複雑性、その2つをやや長い目で天秤にかけた意思決定にはいつも難しさを感じています。
デフォルト設定がほとんどの人にとってのベストになるように
ほとんどのユーザーは、設定をいじらないままアプリを使い始めます。アプリの挙動に許容範囲以上のストレスを感じたときにようやく設定を探しに行くかもしれませんし、そこで離脱するかもしれません。
ユーザーが目的もなく設定を開いて「どれどれどんな設定があるかな」と覗きに来てくれることを前提にすべきではありません。
デフォルト設定のまま使うことが、ほとんどのユーザーにとって最も快適な体験になるようにアプリを設計すべきです。ユーザー体験に大きく影響する設定値であれば、最初のオンボーディングでどちらかを選んでもらうという手段もあります。
「どの部分を設定可能にするか」、「デフォルト値をどうするか」、「どこで設定を切り替えられるようにするか」「どのように気づいてもらうか」などの点は毎回ややこしい課題になります。
操作をブロックしない
自分はブロックされない体験が好きです。待ち時間の間にも、他の何かの操作を行いたいのです。
Nani翻訳でも、できる限りブロックを行わないようにしています。翻訳が進行しているときも別の翻訳文の入力ができ、中断したくなったらすぐに中断でき、雑に操作してもなんとなくやりたいことができる形が理想的です。
使い方を説明文に頼らない
悲しいですが、機能の使い方や注意点について、ていねいで詳しい説明を書いてもほぼ読んでもらえません。
もちろん長文による説明が必要になるシーンもあります。それが許容されるような種類の文章もあります。たとえばこの記事は「読み物」という前提があるため、こんなふうに長々と書いていても気合いを入れて読んでもらえたりします。しかし、アプリの中の説明文を読むとき、ユーザーは「早く使い方を理解して、その機能を使いたい」と思っているわけです。説明文を読むことは目的ではなく、負荷でしかないのです。
自分の中のルールとしてスマホで4行を超えるような説明文は基本的に読まれないし、存在だけで「ややこしい」という印象を持たれる要因になると捉えています。
まずは長文を使わずに表現できないか検討し、それでも長文が必要なら、複数の段階に分けて見せたり、強弱をつける（特に大事な一文と、補足文を分けるなど）ことで、少しでも読む負担を抑えられないか考えるようにしています。
汎用性を犠牲にして、ハマると快適な体験に
Naniでは翻訳言語の設定のほかに母国語の設定というものがあります。これはUI上の言語でもありますが、同時に文章の言語判定や、翻訳の解説文、次のアクションを提示する際の大きなヒントになります。
たとえば設定で母国語: 日本語 + 翻訳言語: 英語としている場合、デフォルトで以下の挙動になります。
- 日本語以外の文章（例: 英語やスワヒリ語）→ 日本語へ
- 日本語 → 英語へ
1の日本語へ翻訳するパターンであれば、ユーザーは原文（英語やスワヒリ語）の内容を把握する目的で翻訳している可能性が高いため、その内容を把握するための追加アクションを提示します（「要約する」など）。
2の他言語に翻訳するパターンであれば、ユーザーは他言語でだれかに文章を伝えたいと考えている可能性が高いため、シーンに応じたニュアンス別の翻訳例を複数提示します。
これは左右横並びでテキストを表示し↔で切り替えられる従来の翻訳UIに比べて、汎用性に欠けている面もあります。
たとえば他言語から他言語（例: 中国語 → スペイン語）へと翻訳したい場合には、追加でポチポチと操作してもらう必要があります。
これを楽にするためのアップデートは今後やる予定
しかし、せっかくの個人開発です。自分の考える理想の体験を遠慮なく試していくスタンスで開発しています。
少しでも速く
ツールの性質上、ボトルネックは完全にAIのAPIの待ち時間ですが、それ以外の部分では10ミリ秒でも速く結果を表示したいという気持ちで開発しています。
このあたりのチューニングは自分が好きな作業の一つで、個人的な嗜好から優先順位が高くなっている部分でもあります。
作業に煮詰まったときには、息抜きがてらサーバー側のパフォーマンスチューニングや、入力の遅延の改善や、ショートカットの反応速度の改善などを行っていたりします。
新しい機能をつけるときには、既存の別機能の速度に影響がないか、毎回チェックしています。
10ミリ秒を削っても体感的にはほぼ変わりませんが、ビジネス的にはコスパが悪い部分に好きなだけリソースを投入できるのは個人開発の醍醐味です。
主観を拠り所に開発する
Naniを開発するうえで最大の指針にしているのは「自分ならどう感じるか」という主観的な感覚です。自分とは違う感覚を持つ人を満足させることは諦め、同じ感覚を持つ人に刺さるものを作ろうと割り切っています。
まだ自分でも満足できない部分がたくさん残されており、焦りやもどかしさを感じることがよくありますが、じっくりと時間をかけてNaniを育てていきたいと思います。