バックエンドエンジニアから社内初の「デザインエンジニア」になった話

サムネイル

はじめに
- 自己紹介
- デザインもエンジニアリングもやっていきたい → 「デザインエンジニア」を名乗らせていただくことになった
デザインエンジニアの仕事とは？事例から定義してみる
フルサイクルエンジニアリングなチームでやっているデザインエンジニアとしての仕事
最後に

はじめに

自己紹介

2021年度新卒で入社し、DMMポイントクラブのWebチームでエンジニアをしている佐藤(X: @SANdglAss1229)です。普段は、GoでAPIサーバーを書きながら、AWSやフロントエンドも少し触っています。

所属するポイントクラブチームには、スマホアプリを開発するチームやマネージャーも含めて総勢20名ほどのエンジニアとデザイナーがいます。フルサイクルエンジニアリングを提唱しており、施策立案、実装、分析、また施策立案とサービス開発の全プロセスを、エンジニアとデザイナーだけのチームで進めています。詳しくは弊チームの同期が書いたフルサイクルエンジニアリングを実践する開発組織のオンボーディング設計をご覧ください。チームでの取り組みについては、技術書典に出した本DMM PointClub Tech Book #1にもまとまっています。筆者はその中の「UXライティングとドメイン駆動設計」という章で、ユビキタス言語ドキュメントをUXライティングのガイドラインとして運用しようとしている話を書きました。実は、筆者はエンジニアリングだけでなくサービスのUIデザインやUXライティングのプロセスにも携わっています。

デザインもエンジニアリングもやっていきたい → 「デザインエンジニア」を名乗らせていただくことになった

ソフトウェアサービスを開発する際には、施策・機能の「要件定義」と、それらを実現する「デザイン」を作るプロセスが含まれることが多いと思います。UIデザインやクリエイティブの作成などのデザイン業務は、もちろん基本的にはポイントクラブ専属のデザイナーが行なっています。しかし筆者は、デザイナーのいる開発チームにエンジニアとして在籍しながら、デザインの仕事もしてきました。具体的には、スマホアプリ版・Webサイト版・キャンペーンLPなどのUIデザインに関する壁打ちやレビューです。またUXライティングについては、ボタンのテキスト・ユーザーへのお知らせ・Xのポストまで、サービスに関係する全ての日本語をレビュー・校正しています。

もちろんエンジニアとして新卒で入社したのですが、インターンや副業でBtoB SaaSのUIデザインを行なっていたこともあり、配属先でも「デザインのプロセスに携わりたい」と思っていました。そして今のチームで、キャリアパスをあえて定めないままやりたいことをやり続けさせていただいてきました。

そして今年の12月、チームで正式に「デザインエンジニア」の肩書きをいただきました 。
デザインエンジニアというのはけっこう珍しいロールなのではないでしょうか。社内のいろんな人に聞いてみてもこの肩書きを持つ社員さんを知っている方はいませんでした。おそらく約900人いるDMMのエンジニアの中で1人目なのでは と思っています。とは言ってもDMMは「職能チーム」ではなく「プロダクトチーム」なので、もしかしたら「デザインエンジニア」もしくは似た動きをしている方が既にいる可能性は大いにあります。ぜひともお話させていただきたいので、ご連絡をお待ちしています。

この記事では、前半に他社事例に基づいて「デザインエンジニア」という肩書きを持つ人の仕事を俯瞰・整理し、さらに自身のどの強みを生かしながらチームやサービスにどのように貢献するのかを明確にしていきます。後半では、筆者が現在行なっている仕事やチームの仕組みについてご紹介します。
ちなみに、筆者がUIデザインに興味を持ったきっかけとなったのはWEB+DB PRESS plusシリーズオブジェクト指向UIデザイン ――使いやすいソフトウェアの原理やその著者の企業ブログソシオメディアです。エンジニアの方々にこそデザインを面白いと感じていただけはずなので、よければご一読ください。
また、UXライティングについては『あつまれどうぶつの森』の世界観をつくるUXライティングや wordrabbit監修 UXライティングガイドライン UXライティングとは何かがオススメです。

いらすとやでデザインエンジニアと検索 — いらすとやにも「デザインエンジニア」の素材はまだないようです

デザインエンジニアの仕事とは？事例から定義してみる

「デザインエンジニア」と検索してヒットする記事や採用関連ページでは「UIの実装とデザインをやる人」と書かれていることが圧倒的に多いです。また、以前に筆者が話したことがある他社のデザインエンジニアさんもこのパターンでした。しかし、筆者はそこを目指してはいません 。現在フロントエンドを専門としておらず、今後もその予定はありません。「それでもデザインエンジニアと言えるのか」についても、この章で見ていきましょう。

ゆめみオープン・ハンドブックデザインエンジニアの定義 ↗

フロントエンド/iOS/Android/Flutterエンジニアといった「UIを開発する職種の能力」を持った人が、UIデザイナーといった「UIをデザインする職種の能力」を併せ持ち、双方の能力を発揮して活動するマルチスタックエンジニアの事を「デザインエンジニア」と呼ぶ

Webであろうとアプリであろうと「ユーザーが触る画面を実装しているエンジニアであること」が前提 のようです。できあがったUIデザインに一番近い立ち位置なのはそれを実装するエンジニアなので、当然といえば当然です。「フロントエンドをメインでやっていて、デザインにも興味がある」という方は少なからずいらっしゃるのではないでしょうか。

続きを見てみます。

期待されること

エンジニアなので、主体は「UIを開発する事」

デザインから開発を全て行うというわけではない

スケジュールや体制によってはデザインから開発まで全部やっても良い

その上で、ゆめみではデザインを社外の人もしくは社内で行うため、各デザイナーとスムーズに連携や意思疎通ができる事 が求められる

プロトタイピングを必要とするプロジェクトにおいては、テクニカルプロトタイピングの開発 （デザインツールからエクスポートしたものではなく、デザインデータからUI部分に関する開発）を行う事が期待される

UI部分を実装する人がデザインの知見を持っているので、「デザイン→その実装」をスムーズに繋ぐことが期待されています 。さらに後に続く「フェーズ別の活躍イメージ」の項にも記載がある通り「デザインをもとに実装する」というだけでなく、異常系や状態変化を加味したデザインの提案やデザインシステムとしてのコンポーネントライブラリを開発することが求められているようです。

デザインエンジニアに必要な5つのこと ↗

Ubieでデザインエンジニアをされている方の記事です。必要なのは下記の5つとのこと。

アプリケーションの実装とデザインの知識・経験があること

デザイナーとエンジニアの通訳をすること

デザインシステムに関する知識

わかりやすいドキュメントを書く能力

プロトタイピング

1つ目の「 アプリケーションの実装 」については、以下のように補足されています。

その中でもCSS、アクセシビリティ、ウェブフォントなどの知識があるとより良いと思います。これらはデザインと開発両方の知識が必要になる分野でありユーザー体験の重要な部分を担うところでもあるため、デザインエンジニアがこれらの開発をリードすることが求められるはずです。

ここでもやはり、フロントエンドエンジニアであることが前提になっています。この方がフロントエンドエンジニアなのもあり、やはりその仕事は「デザインの知見を持ちながらフロントエンドを実装すること」のようです。

一方で2つ目の「デザイナーとエンジニアの通訳をする」は筆者が今やっている仕事でもあります。やりがいや楽しさだけでなくサービス開発における意義も見出しているポイントなので、とても共感できました。

デザインエンジニアに求められる役割は組織ごとに様々ですが、多くの場合エンジニアとデザイナーの間に入って両者の関係をつなぐ役割を担うことになるはずです。エンジニアとデザイナーの間に溝が生まれてしまうのは両者が違う言語を使っていることが原因です。その溝を埋めるには両者の主張を適切に翻訳し円滑にコミュニケーションできる能力が必要になってきます。

個人の考えですがUIデザインに対しては「機能要件というinterfaceを満たす実装を現実世界に生み出すこと」「ドメインオブジェクトのユースケースに行為者(ユーザー)を違和感なく巻き込むこと」のようなイメージを抱いています。つまりデザイナーは「理想」としての(=ソフトウェアでの実装その一切を全く念頭に置かない)UIデザインを提示することが求められている と思っています。

しかし現実は既に動いているシステムの実装に依存したり、連携する別のシステムによる制約があったり、工数や予算の限界が決まっていたりする ことが多々あります。デザインエンジニアは、これらの技術的な制約を理解しながらデザインに携わる人として「理想の提示」と「現実の制約」の間で発生しうる手戻りをあらかじめ避けることができる人、といったところでしょうか。

冒頭で紹介した「フルサイクルエンジニアリング」の「フルサイクル」にはもちろんデザインというプロセスが含まれています。ポイントクラブでは施策担当になったエンジニアがユーザーストーリーを考えたり、PRD(Product Requirements Document: プロダクト要求仕様書)を書いたりするので、サービスとユーザー間のインタフェースを定義・作成するといった行為をしているとも言えると思います。こういった「コードを書く以外のスキル」を持ったエンジニアがサービス開発をすることの強みが、次に紹介するGoogleの記事で説明されています。

INTERVIEW Why Google Needs UXEs ↗

「デザインの知見を持ちながら領域を跨いで仕事する人」のことを、GoogleはUXEs(User Experience Engineers)と呼んでいるようです。拙いですが、日本語訳もつけてみました。

User experience engineers, or UXEs, occupy an ever-evolving niche at Google. As creative all-rounders, they bring a balance of design savvy and technical design expertise to their roles; as thoughtful problem solvers, they apply their unique crossover skill-sets to projects across all stages of development, from intent to implementation. Prototyping is one of their superpowers. They have a knack for getting things done.

UXEsはGoogleで進化し続けるニッチな分野を占めています。クリエイティブなオールラウンダーとして、デザインに精通し技術としてのデザインの専門知識をバランスよく発揮します。また意図から実装まで、プロジェクトの全ての開発段階にわたってクロスオーバーなスキルセットを用いて思慮深く課題を解決する人です。スーパーパワーの一つとしてプロトタイピングを行ない、物事を成し遂げるコツを体得しています。

とんでもないスーパーマンのように書かれていますが、言っていることは「デザインのプロであることに加えて多様なスキルセットを持ち、プロジェクトで横断的に活躍する人」といったところでしょうか。もう少し具体的なソフトウェアエンジニアとしての仕事内容の説明が続きます。

Need a new tool built to support a Figma integration? Ask a UXE. Need to research some new technology and determine feasibility? Ask a UXE. Need a functional prototype for user testing? Ask a UXE. Need to build a front-end using the latest technologies and platform best-practices? Ask a UXE.

Figmaへの統合をサポートする新しいツールの構築が必要？UXEsに聞いてください。新しいテクノロジーを研究し、実現可能性を判断する必要がある？UXEsに聞いてください。ユーザーテスト用の機能的なプロトタイプが必要？UXEsに聞いてください。最新技術とプラットフォームのベストプラクティスを用いてフロントエンドを構築する必要がある？UXEsに聞いてください。

ここまでに見た記事に共通する仕事内容として「デザインシステムの構築」と「プロトタイピングの作成」が挙げられています 。デザインエンジニアのキャリアパスやキャリアラダーのようなものがあるとすれば、プロトタイピングの作成は手を動かすジュニアレベルの作業、そしてデザインシステムを構築するとなるとサービス・組織といった高いレベルの視座を持っている ことになりそうです。ジュニアには少し荷が重く、ミドルレベルといったところでしょうか。

The process of creating a new feature can sometimes feel like a negotiation between sides: designers are trying to pitch the best version of a feature based on what they've learned about users, and engineers have to adjust that to fit within the way the existing product code has been written. UXEs act as a communication bridge—a translator—who can often see and propose solutions to problems that realize all the user benefits while avoiding major engineering challenges.

新しい機能を作るプロセスは、両サイド間で交渉しているように感じることがあります：デザイナーはユーザーについて学んできた知見を基にベストなものを提案しようとしますが、エンジニアはそれを既存のコード要件に収まるように調整する必要があります。UXEはコミュニケーションの架け橋=翻訳者として機能し、エンジニアリングにおける課題を回避しながらユーザーの利益をすべて実現する解決策を検討・提案できることが多々あります。

つまり、デザイナーとエンジニアという別々の専門家が「現実的な良い落とし所」をすり合わせる必要があるけれども、両方の脳を持つUXEsはそれを単独でうまく見つけ出せるということです。これは筆者もデザインエンジニア的なムーブを始めてからずっと感じている強みであり、メリットだと思います。ソフトウェアエンジニアとしてフロントエンド・バックエンド・ネイティブアプリ・インフラなど、いろんな領域を知っていれば知っているほど、全体として良いアーキテクチャ設計や実装ができるようになるのと同じ、といったイメージでしょうか。

この記事は、この後もとても良い文章ばかりで引用し始めるとキリがないので、この辺で切り上げます。次に別の企業の事例を見てみましょう。

カミナシで活躍する『デザインエンジニア』の3つの重要な役割とは？ ↗

それまでは私も、デザインエンジニアとは「デザイナーとフロントエンジニアの仕事を1人でこなすこと」と思っていましたが、重要な役割があることに気付いたんです。もちろんデザインエンジニアは、エンジニアとしてもデザイナーとしても、きちんとアウトプットができる人のことではあるのですが、私が考えるデザインエンジニアには大きな役割が3つあると思っています。
①デザイナーとエンジニアのコミュニケーションの架け橋
②さまざまな観点を取り入れたデザインシステムの構築
③スピーディーで高精度なプロトタイピング

今までに見てきた内容と非常に似ています。1つ目はさらにこう解説されています。

デザインエンジニアは「デザイン」と「エンジニア」のバイリンガルであるため、高度に専門化されたデザイナーとエンジニアの間のコラボレーションの質を劇的に高めることができます。
例えば、デザイナーがプロダクト上の課題に対して新しい技術的な解決策を提示することや、仕上がってきたデザインに対してエンジニアがより理解した上で実際のプロダクトに落とし込むことなどです。
このようにデザインエンジニアが翻訳することで、コラボレーションを介してそれぞれの可能性を広げることもできるようになります。

この部分もUXEsと共通するところがあります。そして2つ目と3つ目は例に漏れずフロントエンドエンジニアの担当領域です。

デザインシステムとは、デザインの原則と、UIパターンやコンポーネントなどからそれらの実装コード、運用まですべて備えたもので、プロダクトチームでエンジニアとデザイナーの“共通言語“となるものです。
これを構築するためには、プロダクト、デザイン、エンジニアリングからの観点をそれぞれ配慮した上で俯瞰的な設計にする必要があります。
いずれかに偏ったものにしてしまうと、その後の運用にさまざまな問題を招いてしまいます。三者それぞれの考え方や定義をデザインシステム内に落とし込んでつなぎ合わせてデザインし、さらにコーディングと運用までの一貫性を担保するには、デザインとエンジニアリング両方のことをよく知っている人が必要なのです。

やはりデザインシステムの構築はサービスや組織のレベルでの貢献と言えそうです。そうなると必然的に少しエンジニア歴(あるいはデザインエンジニア歴)の長い人が取り組む組織課題のような気がします。

プロトタイピングについては、ユーザーやステークホルダに常に触ってもらえるフローが既にあるなら精度を高める価値がありそうです。しかし、ポイントクラブはドメイン駆動開発の開発者集団でありながらドメインエキスパートにも自分たちがなっていくというチームなので、現状ではそこまで優先度の高い仕事ではないような気がしています。

さて、最後に「例のあの図」をオマージュした記事を紹介します。デザインエンジニアの強みがかなり伝わるのではないでしょうか。

デザインエンジニア概論「”デザインエンジニア思考”でつくるブランコ」 ↗

「デザインエンジニア概論」と題された連載の第5回であるこの記事では、あの有名な「顧客が本当に欲しかったブランコ」の図をもじってデザインエンジニアの有用性が解説されています。なお、この記事における「エンジニア」とはソフトウェアエンジニアを指すわけではありません。しかしながら「専門的なスキルを持ってものづくりをする人」というもっと一般的なくくりに通底している考え方だなと思ったので紹介します。

詳しい説明は元の記事を見ていただくとして、以下に引用する箇所だけでも心当たりのある方が多いと思います。

顧客からは庭の木に遊具（ブランコ）をつくってほしいと依頼がありました。遊具をつくるにあたっての顧客の要求は以下の３つです。

”スタイリッシュ”なブランコであること

子供が使っても”安全”であること

設置費用が”低価格”であること

依頼を受けたエンジニアとデザイナーはそれぞれ検討項目を分担してブランコを開発することにしました。

(中略)

最終的な成果物を作成するにあたっては、デザイナーとエンジニアの提案を１つにまとめる必要があります。２つの提案にはいくつかのギャップがありますので、このギャップを埋める作業が「すり合わせ」です。

(中略)

時間切れにより議論半ばで成果物が仕上がりましたが、顧客要求に従ってつくられた成果物であることは間違いありません。しかし、この製品が顧客を満足させられるのかは不明です。

デザイナーとエンジニアは、それぞれのスキルをもって要件を満たす実装を考え、互いの提案の問題点を指摘して折衷案に落ち着きます。最終成果物は要件を満たした実装になったものの、自分たちやユーザーが改めて見てみると「なんかもっとこう...良い感じにならなかったのか...」と思うところがある結果となったようです。サービス開発においてこういうことは頻繁に起こります。仮に開発者たちもユーザーも誰ひとり改善した方がいいと思っていなかったとしても「もっと良い実装」がある可能性は0ではありません。

かたやデザインエンジニアはというと、1人でデザインとエンジニアリングを混ぜこぜに思考します。これこそ「1人の人間が2つのスキルを持っているからこその強み」です。

デザイナー思考では、主に"スタイリッシュ”の要求について考えを巡らせたり、さらには要求にはない要素を加えることでより質の高い体験を顧客に提供できないかなどを考えます。結果、以下の内容を開発で考慮することに決めました。

座面が主役のプロダクトにする

座面に付加価値を持たせる

非常に抽象的ですが、デザインエンジニアはデザイナー思考だけで提案を固めません。自身が応じるべき全ての要求について考えていないことを知っているからです。

(中略)

エンジニア思考では、主に”安全”、”低価格”の要求について考えを巡らせます。結果、以下の内容を開発で考慮することに決めました。

使用中にロープが切れてはいけない

使用中に枝が折れないように補強が必要

原価設定に費用を収める

デザイナー思考同様に、デザインエンジニアはエンジニア思考だけで提案を固めません。

ここまで上手くはいかないにしても、筆者もデザイナーとエンジニアの両方の思考を量子的に(=同時にぼんやりと)したり、交互に考えたりすることがよくあります。

つくるものが一つにも関わらず、デザイナーとエンジニアにはそれぞれの「制約」や「要件」が存在し、これらの”ギャップ”が両者の分断と成果物の食い違いを生み出す要因です。

一方、領域横断的な思考ができるデザインエンジニアがチームにいる場合は、”ギャップ”の少ない検討が可能です。

これは、前回解説した開発期間の短縮メリットと合わせて、デザインエンジニアの起用によって期待される効果の一つです。

さて、ここまで多くの事例を紹介してきました。ここまでの内容を踏まえて説明すると、筆者は「フロントエンドに詳しい」デザインエンジニアとしてサービス開発に貢献したいのではなく「つくるものの要件や制約を、領域横断的な思考で検討できる」 デザインエンジニアを目指しています。この「要件や制約を領域横断的な思考で検討」するには、フロントエンドエンジニアとしての技術力よりも、むしろバックエンドの文脈で語られることの多いアーキテクチャ設計やモデリングの知見が役立つのではないでしょうか。特に冒頭でも紹介したオブジェクト指向なUIデザイン(扱うモノ=オブジェクトがまず存在し、それらに対して働きかけをするのがユーザであるという考え方)を目指すとなると、システム設計のモデリングとUIのデザインはもはや同じ行為をしていると言っても過言ではないと考えています。アプリケーションが扱うドメインに登場するオブジェクト、それらが持つプロパティを考え、それらの相互作用としてユースケースが発生する。ドメインとユーザという異なるもの同士がインタラクションするには、文字通りインタフェース=界面が必要です。その界面を両者にとって違和感なく、もはやそこに継ぎ目があることすら意識しないような「自然な」インタフェースを模索する、という行為がUIデザインである。デザインという言葉の原義である「計画に形を与えること」は、ドメイン領域をソフトウェア化しようとする行為と非常に近しいと筆者は考えています。

バックエンドエンジニアでもデザインエンジニアの仕事ができそうだな...と少しは思っていただけましたでしょうか。

ちなみに、今まで見てきたようなエンジニア、特にソフトウェアエンジニアのことをDesign Technologistと呼ぶこともあるようです。詳しくは新卒2年目のエンジニアがDesign Technologistを名乗ることになった話やIndeed Design: What Is a Design Technologist?などをご覧ください。

フルサイクルエンジニアリングなチームでやっているデザインエンジニアとしての仕事

「このチームでデザインエンジニアになりたい」という意志が固まったのは、今のチームメンバーとマネージャー陣のおかげです。当初は「デザインエンジニアというロールありきの開発フローや組織図を組むと属人性が高すぎるし、再現性が低すぎる」「仮に自分が抜けたらまた元に戻ってしまうどころか、むしろ元に戻すのに手間がかかってしまう」という大きな懸念があったため、言い出さずにいました。

この懸念を払拭するには、少なくとも既存のメンバー全員にも同じように「そういう仕事」を多少なりとも担当してもらい、ポイントクラブの開発体制として定着させることが必要だと考えています。さらにこれから新たにメンバーとなる方に「そういう仕事」へとオンボーディングして興味を持ってもらえるところまで整備できて、ようやく再現性や持続性が高まっていると言えるのではないでしょうか。

実際に所属のWebチームへこの気持ちを軽く打ち明け始めたところ、たいへん嬉しいことに、全員が多かれ少なかれデザインエンジニアの仕事内容に興味を持っているようでした。本当に全員でやっていくという空気感を醸造するため、デザインに関する知見の共有・開発フローの整備・仕事内容のドキュメント化なども1人目である筆者の責務だと感じています。そもそもエンジニアとしてマネージャー陣に採用していただいたのにもかかわらず、デザイン業務もやらせてもらい、挙句には肩書きまでいただきました。良い仕事をして恩を返していきたいです。

次に筆者が現在している仕事や、手探りながらも整えられつつある組織の仕組みについて紹介します。

ユーザーシナリオの作成や体験設計から参加し、実装面の制約を検討しておく

ポイントクラブでは、施策(≒新機能実装)の最初にユーザーシナリオやユーザーストーリーマッピング、カスタマージャーニーマップといったツールでユーザー体験の全体像について構想します。ユーザーがとる一連の行動と各ステップでの思考・感情を想像し、それを満たす「機能要件」を洗い出していきます。このフェーズでは、必須な要件だけでなく、あればグッと良い機能になりそうなアイデアやリリース後にでも追加したいという仕様がたくさん出てきます。

ポイントクラブでは、デザインに取り組む際にとにかく選択肢を広げる「発散」と、そこから良い結論へと絞り込む「収束」という2段階のプロセスで分けて考えるようにしています 。詳しくは、ダブルダイヤモンドとは？デザイン思考の実践的なフレームワークとその活用例などをご覧ください。

エンジニアでもある筆者だけは、このときに実装的な制約も頭の片隅に置いています。実装難易度がなんとなく分かる人がいると「収束」のプロセスでアイデアの優先順位を決めるときに工数見積もりの観点を加えることができます 。

もちろん、理想のユーザー体験やUIを設計することが最優先事項なので、無意識のうちに発想を狭めてしまわないように「発散」の段階ではエンジニア的な思考に基づく意見は出しません。ただ「現実的な」機能開発計画にすることも、限られた工数や予算でサービス開発していくにはとても重要です。要件の優先順位を決め、デザインに盛り込み、エンジニアに実装依頼が舞い込んで初めて「これはちょっとできないですね」「これをやろうと思うと、別のところも修正しないとですね」という制約が発覚して優先順位決めに戻る、ということは往々にして起こります。「どこかのプロセスでエンジニアが参加していれば防げた手戻りだったな...」というつらみを生まないために、この段階から筆者も参加しています。

WFの段階でデザイナーと壁打ち

冒頭でも言いましたが、情報系だった学生時代からデザインが好きでインターンや副業でUIデザインを少しやっていました。DMMに入社して配属されてからも、自分から希望してデザイナーの方々の壁打ち相手になっていました。デザインは1人で悩み始めると「良いデザイン」にいつまでも着地できず、ゲシュタルト崩壊してきたような感覚になりがち です。そんなときにデザイナーの方に「作ったデザインがなんかイマイチなんですよね〜」と声をかけられ、ああでもないこうでもないとUIを練っていると、とても良いデザイン案が出てくることがあります。もちろん、デザイナー同士でも良いデザインになる可能性は十分ありますが、登場するオブジェクトを整理したり、ドメインのモデリングやドメインサービスやユースケースの実装から着想を得たり、データの数やEmpty State(データが0件の時のUI)を想像したりするエンジニアっぽい思考から良いアイデアが出てくるのです。もちろん「筆者に壁打ちしてもらえれば、いつでも良いアイデアを出します」というわけではありませんが...。

逆に筆者からデザイナーに「ここのライティングがいまいちしっくりきてない」と相談することもよくあります。UIデザインやUXライティングには絶対の正解がないだけでなく、どうしても制作者個人の感覚に依存した「良い」「良くない」の判断になってしまう特性があります。そのため、他の人にレビューされない(そしてUIの実装者もその良し悪しを判断しない)ままユーザーに届くと、本当は良いと思ってもらえるはずだったのに「使いづらい」「分かりにくい」という第一印象からもう二度と使ってもらえない可能性もあります。

早くユーザーに価値を届けたいから急いだのに、急いだ末にユーザーフレンドリーなインタフェースやライティングになっていない 、という悲しい事態は避けたいものです。

デザイナーと共にデザインレビュー

ポイントクラブには4名のデザイナーがいますが、普段デザインの作成業務をしているのは、2023年12月現在では2名です。開発計画には、常に10〜20の施策が並行で走っており、デザインが必要なキャンペーンや機能開発案件にはその2名のうちどちらかにワイヤーフレームからUIデザインまでを作成していただきます。このワイヤーフレームが完成した翌日から、デザイナー朝会でもう1人のデザイナーと筆者で毎日レビューをしていきます 。ユーザーが触っているところを想像して懸念事項を挙げたり、Figmaのプロトタイプ機能でいちユーザーとして触ってみたりします。

このときに筆者は、デザイナーの顔をしてレビュワーの頭数を増やすと同時に、エンジニアの顔もしています 。似た実装を思い浮かべて当たっているスタイル(CSS)が似ているか、文字数やデータ数の最大値・最小値あたりでもレイアウトが崩れないか、ローディング時のスケルトンサイズをどこに合わせていくつ出すか、既存の実装やシステム都合による制約がないか、などを考えます。ワイヤーフレームの完成段階まで来るとUIの段組みはそうそう変わらないので、フロントエンド的な視点がメインになっています 。

またこの段階から「ユーザーがわかりにくい可能性のある箇所」がぼんやり浮かび上がってくることが多いのですが、UXライティングでかなり良いUIに変貌することがあります。

UXライティング

UXライティングとは、ざっくり言うと「ユーザーがUIで読むすべての文言・文章」であり、筆者はUXライティングを「文字のUI」だと考えています 。すなわち、UXライティングはデザインの対象であり、ユーザーのことを考えてきちんと作り込まれている必要があります 。同じUIデザインでもそのボタンに書かれたラベル1つや注意書きの文章1つでユーザーの印象や想像する挙動は大きく変わり、その積み重ねがサービスの「使いやすさ」や「愛着」といったマクロの印象に繋がっていくと考えています。

これも筆者1人の手作業でやっていては再現性が低い上に属人性が高く、チームの仕組みとして健全ではありません。そのため、ライティングのレギュレーションドキュメントを書いたり、ユビキタス言語ドキュメントをライティングのガイドラインとして併用したりと、再現性を高め属人性を下げる取り組みをいくつか試しています。ゆくゆくは、github.com/textlint/textlint が走るSlackワークフローを作ったり、ポイントクラブのレギュレーションやガイドラインに沿いながら校正をしてくれるようなChatGPT用のプロンプトを整備したりもしたいなと思っています。

ちなみに、チームメンバーを集めて勉強会を開いたり、何度かレビューを受けたりしたからか、最近はメンバーからレビュー依頼が来た初稿の時点でかなり良いライティングになっていることが多い ので、とてもうれしいです。