UXチームMailChimp：創造性とロードマップ[本のパート7]

[ TL; DR ]



[本の最初の部分 ]

[本の第2部 ]

[本の第3部 ]

[本の第4部 ]

[本の第5部 ]

[本の第6部 ]

[本の第8部 ]

創造性とフロントエンド

ジェイソン・ビアード



UXニュースレターでは、テンプレートライブラリと、それが高速反復を実行し、MailChimpの一貫性を保つのにどのように役立つかについて頻繁に書きました。 既存のパターンに基づいて開発することは、レゴでのゲームのようなものです：作業を開始すると、特定の要素が互いにどのように通信する必要があるかを正確に知っています-しかし、パターンを破って異常なソリューションを作成することが役立つ場合があります。 このアプローチがMailChimpでどのように実装されたかについて、いくつかの例を共有したいと思います。



テキスト配置アイコン







左、右、中央、幅に揃えるためにアイコンを追加する必要がありました。 セットに 4つの新しいアイコンを追加することもできますが、それは簡単すぎます。 私は創造的になってCSSで作成することにしました。 CSS Shapes拡張機能の使用は一般的な方法ですが、そのようなフォームは通常、変更された要素に背景色を追加することで作成されます。 代わりに、セット内の他のアイコンと同じ方法でテキストのサイズと色を継承できるように、整列したダッシュ（長いおよび中）を擬似要素として使用しました。 面白かったし、CSS（ Codepenのアイコンのデモ版）で数行だけでした 。



アニメーション時計アイコン







より洗練されたフロントエンドクリエイティブは、1回のツイートの結果です。 マルダフは、彼にとって個人的な挑戦がティエリーブランパンの提案であると判断しました。



MardavはD3.jsと呼ばれるJavaScriptライブラリをしばらくいじり、通常は複雑なグラフとデータの視覚化に使用されます。 すでにD3を使用してグラフを作成することを計画していたため、時計アイコンを使用した演習は素晴らしいトレーニングでした。 Mardavはプロトタイプを作成し、驚くべき開発チームの助けを借りて、彼はアプリケーションの多くの要素で使用するカスタムDojoウィジェットになりました。



ブロードキャスト時間を13:45または7:30に設定すると、時計アイコンにその時間が反映されます。



ユーザーがこのおもしろい詳細に気付くとは思わず、 Little Big Detailsでそれについて話したときに非常にうれしい驚きを覚えました 。 アイデアをありがとう、テリー（ Codepenの時計のデモ版）。



新規ユーザー向けのアニメーションGIF







私たちは常にビデオチュートリアルを使用して、新しいユーザーにMailChimpの仕組みを教育しました。 これらのビデオのほとんどは2分以下しか続きませんが、場合によっては数秒で目的に必要な時間がさらに短くなることがわかりました。 アニメーションGIFはこれに最適です。したがって、2013年の再設計以来、必要に応じてアニメーションGIFを使用して、新しいインターフェイス要素がどのように機能するかを示してきました。



残念ながら、PhotoshopでスクリーンビデオをGIF形式で保存すると、結果のファイルのサイズが非常に大きくなる可能性があります。 Federicoが新しいエディターの「組織的社会化」プロセスの一環として一連の短いビデオを作成したとき、かなり積極的な圧縮設定を使用しても、ファイルが1MB以上を占めることが判明しました。 これはビデオにとってはかなり重要ですが、簡単なアニメーションチュートリアルにとってはかなり重要です。 そこで彼は、GIF形式でのスクリーンキャストの他の例を探し始め、偶然露出写真プラットフォームからの手紙を偶然見つけました。



写真コンテンツを含む露出レターの2つのGIFファイルは、網膜ディスプレイ用に作成され、重量は171KBと401KBのみでした。 FedericoはExposureのLuke Beardに、これを達成するために使用したものを尋ね、「 cockos.com/licecapだけが最高だ」と答えました。



最初は冗談だと判断しました。 サイトは90年代に作成されたかのように見え、それ以来何も変わっていません。また、その会社は、製品は言うまでもなく「Cockos Inc.」という名前を選びました。 「Licecap」（fu！）という名前で-これはすべて、これが機能するという自信を持って私たちを刺激しませんでした。 しかし、魅力のない名前の下で、フリーソフトウェアが隠れていたため、FedericoはGIFファイルの書き換えを試みました。1MBではなく、182KBしか占有しなくなりました。 問題は解決されました（ありがとう、ルーク、そしてあなたを疑ってすみません）。



可能な解決策について考えるのにもう少し時間をかけることを恐れないでください。



予算と期限により、問題の最も明白な解決策に傾くことがありますが、常にそうなるとは限りません。 次にフロントエンドタスクで作業するときは、他のソリューションオプションを検討してください。 異常なことをしてください。 特にユーザーを満足させることができる場合は、あらゆる機会を利用して新しいテクニックとテクノロジーを適用してください。 そして、他の誰かが同じ問題をどのように解決したかを恐れることはありません-この方法であなたがどんな新しいスキルを学べるか、あなたは決して知りません。

リリースサイクルとロードマップ

フェデリコ・ホルガド



MailChimpの私たちはすぐに前進する必要があります-これは、私たちが取り組んでいることと、仕事がどのように行われているかに当てはまります。 効率的に実行できるプロジェクトを計画に追加し、常に正しいことを行う必要があります。 適切なアイデアと、信頼性が高く、同時に柔軟なソフトウェア開発プロセスを組み合わせると、本当に高速を実現できます。



リリースサイクルは常に進化していますが、現在は5週間かかります。新機能の開発には4週間、「フリーズ」および品質評価には1週間かかります。 MailChimpで深刻な問題を引き起こす可能性のあるモノリシックソリューションを作成する誘惑を避けるために、開発者の時間を制限します。 6か月から1年にわたって開発されたソリューションと比較して、4週間のプロジェクトの量ははるかに少なく、テストははるかに簡単です。 さらに、時間制限があるため、管理しやすく「ビジョンの少ない」タスクを使用することを好みます。 しかし、常にそうではありませんでした。



古いアプローチ：時折の計画



MailChimp開発部門でリリースの管理を始めたとき、アップデートは通常、単一のリリースリリースサイクルの一部として設計および開発されました。 そのとき、1サイクルに5週間ではなく4週間かかりました。これは、UXデザイナーと開発者に送信できるデザインを作成するのに1週間しかなかったことを意味します。 設計と開発が1サイクルのフレームワーク内で実行されると、そのための精神的な準備が困難になります。詳細が見逃され、ボリュームと用語が不明な理由で増加するため、作業が緊張します。 さらに、何度も何度も設計に戻らなければならなかったため、中間リリースを作成するというアイデアを放棄することは非常に困難でした。



新しい方法：次に何が起こるかを知っています



リリース計画の初期の頃から状況は少し変わっています。 最後の目標の1つは、次のステップについての理解を深めることです。 現在、開発プロセスと設計プロセスを「分離」するよう努めています。 プログラマーとCEOは、UXデザイナー、デザイナー、および開発者によって慎重に研究された後にのみ重要な機能の開発を引き受けることを知って、はるかに快適に感じます。



サイクルの最初から、デザイナーに貴重な洞察を提供する大規模なタスクが、開発者の関与により設計されています。 それらを初期の段階で設計プロセスに関与させることは、単に実装できないアイデアについて考えるエネルギーを浪費する可能性が低いことを意味します。 UXデザイナーと同じようにアイデアを生み出し、作業の進行状況や製品の機能について議論する際に役立つ素晴らしいプログラマーがいることがわかりました（すぐにはわかりませんでした！）。



正しい目標設定



早送りとは、特定のタスクを実装するためのあらゆる努力が作業に貢献することを意味します。 アイデアをあきらめることは多くの時間を費やすので、私たちは着手したものを注意深く評価する必要があります。 開発するものについてすぐに合意に達する唯一の方法は、この質問に答えるのに最も役立つ人と話をすることです。 通常、私たちは次のことを心配します：「このアイデアを実現することは可能ですか？」、「今すぐそれを行うことは正しいですか？」、そして最も重要な質問：「それをする価値はありますか？」



リリースをリリースするために、MailChimpのチーフエンジニアであるEric MuntzとCEOのBen Chestnutを集めて、可能な機能と改善点について話し合います。 UXチームの研究やプロジェクトからアイデアが生まれることもあれば、プログラマの発見に基づいていることもあれば、クライアントと頻繁にコミュニケーションをとるベン自身が新しいアイデアを投げかけることもあります。 私たち3人は、高レベルの機能について考え、選択した方向に関連して作業量を推定しようとします。 私たちは、それぞれの新しい大きなアイデアについて議論することで、同じ質問に答えようとしています。



重要なのは、これらが高レベルのアイデアであっても、私たちがしばらくの間考えてきたことに基づいているということです。 たとえば、OnStageと呼ばれるアプリケーションの起動から数か月後にMailChimpにコメントとコラボレーションの可能性を追加することにしました。 OnStageはうまく機能し、あまりうまく機能しないことがわかり、これらのアイデアを使用してMailChimpの改善計画に含めました。 それを実現することを決定するとすぐに、私たちはしたいことをすぐに定式化することができました-これにより私たちは努力を集中し、重要なアップデートを迅速にリリースすることができました。



間違った方向を向いた場合



もちろん、開発中のものが最終リリースに到達しない場合もあります。 「間違った方向を向いている」ことを理解した場合、リソースを他のタスクに迅速に転送できるように、できるだけ早く作業を停止することにします。 通常、すでに作業を開始しているタスクの作業を停止する場合、その理由は時間の不足であり、方向の誤った選択ではありません。 開発を停止することにしたときはいつでも、「パーツバスケット」に行ったことを、いつでも復活できる他のプロジェクトに追加します。



だから何かをしましょう



以下は、5週間の開発サイクルで作業することの意味のより詳細な概要です。 私にとって、このプロセスは大学で学期論文を書くことに似ています。最初は、私には多くの時間があるように思えます。 それから私は自分がどれだけのことをしなければならないかを理解し始め、締め切り前の最後の夜に私はベストを尽くして良い作品を書きます。



1週間：リリースと計画



最後のリリースからコードをデプロイするために、ここ数日間を費やしました。 サポートチームと絶えずコミュニケーションを取り、Twitterとメールをチェックしてフィードバックをできるだけ早く見つけ、迅速に対応します。 おそらく、リリース後の最初の数日間で修正する必要のあるいくつかのバグを見逃しました。 私たちは次のサイクルで何をすべきかを伝え、決定しようとしますが、今週は最新リリースでミーティングを開催します。



2週間：より多くの計画と少しの開発



原則として、前のサイクルのタスクがいくつかあります。次のリリースサイクルで取り組む大規模プロジェクトの設計の詳細に関連する問題を解決しながら、すぐに対処できます。 時々、設計作業を終えると、新しいタスクを引き受けます。



3週間：何かを開発しているふりをする



そこから物事が形になり始めます。 この期間中、私たちは多くのことを伝え、新しい機能の導入の詳細を概説しようとします。



週4：本当に開発中



期限に近づいています。 開発を開始する時が来ました。



週5：フリーズ！ 再計画



リリースの前の1週間に開発を完全に「フリーズ」したいたびに、品質評価チームは非常にクールに働き、非常に多くのバグとエラーを発見したため、今週だけが最終的に完成します。



私は、最後までプロジェクトを最小化するためだけにチーム全体を開発することを強制する企業についての話を聞いたことがあります。 チーム全体の作業を終了することは、おそらくプログラミングに携わる人々が行うことができる最も意気消沈することであり、これは完全に非生産的であるという事実は言うまでもありません。 私たちは、購読しているものを注意深く実装するために最善を尽くしています。 チームが行うことに費やした時間とエネルギーを尊重しますが、このエキサイティングなスピード感も気に入っています。