一言まとめ: APIの設計で悩んだらUXデザイナーに聞け！

APIのインターフェースほど直接的にデベロッパーエクスペリエンスに影響するものはなかなか見当たらないかもしれません。
デベロッパーエクスペリエンスはユーザーエクスペリエンスの一種だと思います。

ユーザーエクスペリエンスとは

ユーザーエクスペリエンス (UX) はそろそろ用語として広く知られるようになってきましたよね。

とはいえまだ理解がふわっとしている方もいらっしゃると思います。Noteの中だとこの辺りの記事が好みです。

見栄えがいい ≠ UXがいい

UXデザイナーの方にお話を聞いてなるほどなーと思った話があります。空港の手荷物受け取り所での待ち時間が長く不満が高かったものを、導線をわざと長くしてたくさん歩かせることで待ち時間を減らしたら不満が減ったと言う話。

見栄えが良いこととか使い勝手が良いことで満足度は上がるかもしれないけど、それだけがUX向上ではないと言うことを示す逸話として非常に良い話だと思います。

APIとデベロッパーエクスペリエンス

APIは開発者に向けて公開されるシステムのインターフェースです。

APIを使ってアプリケーションロジック (UI部分) とビジネスロジック (バックエンド) 部分を分離し、アプリケーションロジック部分を単独でリリースできるようにすることで、UI部分の開発とデプロイがしやすい構造を担保してくれるものです。

UIがシステムの顔だった時から、APIがシステムの顔になります。直接システムを使うのは開発者です。

ではここの使い勝手が良いことで何ができるのか。
API戦略とAPIプロダクトで書いたようなことができるようになります。

逆にAPIの使い勝手が悪いことで何が起こるのか。
PayPalのようなことが起こります。

大事なことは引用しておきましょう。

引用元はこちらです。

つまりAPIクライアントの開発がものすごく非効率になるわけです。
ではデベロッパーが開発に集中できるようにするためにはどうしたらいいか。ここがデベロッパーエクスペリエンスの考え方に通じる部分になります。

デベロッパーエクスペリエンスに関してはこちらにいい記事があります。

APIのインターフェース設計はUX設計の考え方を参考にしよう

デベロッパーエクスペリエンスがUXの一種であれば、UXの設計の方法や考え方がそのまま活用できます。

URLの命名規則 = ラベリングシステム

これは悩む方が多いようですが、これこそUXデザイナーに聞いてみてください。
ラベリングシステムとしてベストプラクティスがまとめられています。

例えばURLで /users のようにCRUDで操作できるデータオブジェクト (私はデータオブジェクト型と呼んでいます) は英単語の複数形がよく活用されます。逆にスペルチェックのような機能 (ファンクション型と呼んでいます) は動詞から始まる名称が活用されます。

上記の「ラベリングシステムの一貫性」を参照すると、構文法のところに書いてありますね。動詞と名詞が混在すると気持ち悪いので、何らか意味があるはずだ！と人は思うんですね。したがって混在させない、混在するのであればそれは意味がある混在である必要があります。

設計プロセス

プロセスもUXデザインの手法を取り入れる組織が増えています。

JPMorganChaseはUX設計手法を使ってAPIのインターフェースを設計しています。Googleでヒットしたのでもしよろしければこちらのプレゼンテーションをご覧ください。

大事なことはイテレーティブに繰り返し検証すること、一回で決めないことです。
例えばOpenAPIを書いて開発者に見せてフィードバックをもらうだけでも多くの知見を得られます。ここが紛らわしかった、ここがわかりづらかった、逆にここはわかりやすかったなど。

設計チームを組んで取り組むのも非常に効果的です。一人で設計をしていると、考えることがありすぎてだんだん細かいところに気を配ることが難しくなったりしますが、チームで当たるとそれを避けることができることがあります。

UXデザインの世界もモブプログラミングの考え方を取り入れたプラクティスが出てきていると聞きました。そのままAPIに適用できるかは私が不勉強でコメントできませんが、少なくともモブプログラミングの考え方を使って設計したチームは直感的に使えるよいAPIを設計していらっしゃいました。