ステファニーウォルターとポッドキャストエピソード9を壊す：UIフレームワークを使用するにはどうすればよいですか？

公開: 2022-03-10

簡単な要約↬SmashingPodcastのこのエピソードでは、UIフレームワークについて見ていきます。非常に使いやすいアプリケーションのカスタムニーズを、既製のツールのセットでどのように満たすことができますか？ Drew McLellanは、UXデザイナーのStephanieWalterに話を聞いて調べます。

私自身、開発者として、UIフレームワークについて私が気に入っていることの1つは、デフォルトのスタイルが付属していることが多いということですが、プロジェクトで信頼すべきものはありますか？デフォルトのスタイルを使用し、フレームワークを作成した人がそれらのコンポーネントの設計で本当に良い仕事をしたことを信頼するだけですか？今日のポッドキャストエピソードに参加して、UIフレームワークを構築するときに考慮すべきことについてUXデザイナーのステファニーウォルターに話しかけます。

メモを表示

ステファニーのウェブサイト
Twitterのステファニー

毎週の更新

AnnaPrenzelによる「AngularとRxJSを使用してカードマッチングゲームを作成する方法」
SarahDrasnerによる「 JAMstackでヘッドレスWordPressサイトを作成する方法」
「マジックフリップカード：一般的なサイジング問題の解決」 Dan Halliday
Philip Kielyによる「Djangoハイライト：ユーザーモデルと認証（パート1）」
ShajiaAbidiによる「Reactとリーフレットを使用してマップを作成する方法」

トランスクリプト

ステファニーウォルターの写真 Drew McLellan：彼女はユーザー中心のデザイナーであり、モバイルエクスペリエンスの専門家であり、パフォーマンスに特に重点を置いて、楽しい製品とインターフェースを横断しました。彼女は、ルクセンブルク大学、European Investment Bank、BMW、Microsoftなどのクライアント向けのプロジェクトに取り組んでおり、戦略から最終製品に至るまで、これらのクライアントが成功したプロジェクトを視聴者に提供できるように支援しています。彼女はプロダクトデザインのGoogleDeveloperエキスパートであり、数多くのブログ投稿、記事、ワークショップ、会議のプレゼンテーションで知識を共有する熱心な教師です。彼女がエキスパートのユーザーエクスペリエンスデザイナーであることはわかっていますが、彼女がかつてエルトンジョン卿とカーペットを合わせる仕事をしていたことをご存知ですか？私のスマッシングの友達、ステファニー・ウォルターを歓迎してください。こんにちはステファニー、お元気ですか？

ステファニー・ウォルター：こんにちは、私は大破していて、紹介が大好きでした。

ドリュー：それで、私は今日あなたに特定の問題について話したいと思いました、そしてそれは既製のユーザーインターフェースフレームワークを使うことの主題です。今、あなたはユーザーエクスペリエンスデザイナーであり、さまざまなクライアントと協力しています。あなたの仕事は、非常に使いやすいユーザーインターフェイスを作成することで、それらのクライアントが可能な限り最高のユーザーエクスペリエンスを作成できるようにすることです。したがって、既成のツールセットを使用してそれを実行できるという考えは、私には少し難しいように思えます。 UIフレームワークの使用は、作業全体でよく見られるものですか？

ステファニー：ええ、それは私が代理店で働き始めて、今は会社の中で働いているので、特にここ数年で私がよく見たものです。ですから、これらの超大規模なIT技術チームには、現時点で私が最もよく見たようなフレームワークUIがたくさんあります。Material-UIです。基本的に、マテリアルデザインはGoogleデザインの一種のガイドラインであり、マテリアルです。 -UIはAngularのチームですが、Reactのチームでもあります。彼らは、Googleのマテリアルデザインのようなルックアンドフィールを使用して、独自のフレームワークを作成しました。しかし、それはもはやグーグルとは何の関係もありません。まるで彼らのようです、私にはわかりません、彼らはルックアンドフィールが好きだったと思います。したがって、現時点では、これらが私が使用している2つの主要なUIフレームワークです。また、Ant Designと呼ばれるものもあり、非常に人気があります。

ステファニー：それはReactフレームワークです。彼らにもAngularがあるかどうかはわかりません。中国のチームが作ったと思います。また、Reactのコンポーネントやすべてを提供するだけでなく、Webサイトにアクセスするとスクラッチファイルも取得できるので興味深いです。これは、デザイナーの構築や形成を促進または支援するため、実際には非常に興味深いものです。そのフレームワークで使用されるUIコンポーネントへのインターフェース。そうですね、特に大規模なITチームでは、ほとんどの場合デザイナーがいないため、これは私がよく目にするものです。現在、私は基本的にヨーロッパの投資銀行の小さなチームの1人のUXチームです。ですから、UXデザイナーとしての私です。私は開発者、ビジネスアナリスト、すべての優秀な人々のチームと協力していますが、それでもプロジェクト全体で1人のデザイナーです。

ステファニー：私が到着するまで、デザイナーはいませんでした。つまり、これは多くの企業、特に社内製品などに実装されている一種のソリューションです。彼らが通常言うところでは、大丈夫、私たちは本当にそのためのデザイナーを必要としません。内部ユーザーに役立つものが必要です。開発者にとって便利なフレームワークを使用しましょう。ほとんどのコンポーネントはすでに存在し、チームにはデザイナーがいないため、UIデザイナーの役割に取って代わるものです。ええ、それに関する問題は、それで、あなたはコンポーネントを持っているということです、しかしUIデザイナーの役割は、ボタンが赤、緑、オレンジ、青などであるかどうかを決めることだけではありません。通常、UIデザイナーの役割は、ユーザーのニーズを理解する情報アーキテクチャです。つまり、インターフェースを超えるすべてのものです。したがって、この種のフレームワークを使用している場合でも、そのようなフレームワークがUI全体を処理します。つまり、画面に表示される内容を視覚的に確認します。

ステファニー：画面に何を表示するかを理解するために、ある時点で誰かが必要です。画面はどのように動作しますか？ここをクリックするとどうなりますか？ユーザーはどのようにして目標を達成しますか？ポイントAからポイントBにどのように移動しますか？モデルを使用できるため、タブを使用でき、すべてのコンポーネントを使用できます。だから、それはいつも少し複雑でトリッキーなのです。

ドリュー：それは可能ですか、既成のUIフレームワークを使用して使用可能なユーザーインターフェイスを作成できると思いますか、それとも常に少し妥協するつもりですか？

ステファニー：そう願っています。そうでなければ私は使用できないインターフェースを構築しているので、私はそう願っています。したがって、この答えは完全に偏っていますが、そうだと思いますが、それはあなたがやろうとしている妥協のレベルにも依存し、双方に妥協があります。たとえば、Material-UIには非常に特殊なボタンがいくつかあり、ボタンの波及効果があまり好きではないため、現時点では多くのボタンを侵害しています。モバイルでは、ユーザーがボタンをクリックまたはタッチしたときに、ある種の大きなフィードバックが必要になるため、モバイルではうまく機能すると思います。しかし、その場合の手順は、ボタン全体に及ぶ一種の波及効果です。特にボタンがたくさんある場合は、少しやり過ぎです。ただし、これはReactフレームワークに組み込まれているため、削除するのは非常に複雑になるため、この波及効果は維持します。そして、このボタンに別のホバー効果を持たせるために、ここではこの種の厄介なことではない、より微妙なものがあります。それは非常に複雑になります。

ステファニー：それで、これはあなたがする一種の妥協です。しかし、それまでの間、カスタムコンポーネントである特定のものについて妥協することはありません。私が以前働いていた場所では、旅行および航空会社の現在のクライアントです。そして、航空会社には本当に、本当に非常に具体的なニーズがいくつかあります。たとえば、航空会社のカレンダーでは、価格を設定したい、設定したい…特定の日にこの目的地に旅行しない場合、いつ配置するかわからない場合は、この出発地と到着地があり、これらのUIフレームワークのほとんどの基本的なカレンダーは、このようなものを提供していません。ですから、ある時点で、彼らが持っているカレンダーを使用するだけだと言うことができます。以上です。あなたはそれを超える必要があります。それで、妥協のほとんどは基本的に構築されています、私たちは基本的なコンポーネントを使用しますか？ユーザーのニーズに合うカスタムのものを作成しますか？それとも、2つを混ぜ合わせますか？たとえば、カレンダーの場合、カレンダーグリッドを使用するため、基本コンポーネントを使用し、その上にカスタマイズを加えて拡張しました。それで、それはそのための多くのReact開発でした。

ステファニー：そうですね、通常は多くの妥協をします。

Drew：ユーザーインターフェイスフレームワークを使用すると、ある程度の道のりが得られるように思えますが、その結果として本当に優れたユーザーインターフェイスを使用するには、かなりのカスタマイズを行う必要がありますか？

ステファニー：通常。うん。

ドリュー：そのカスタマイズはテーマを超えていますか？

ステファニー：ええ、私の開発者はそれがテーマを超えないことを望んでいました。ユージーンあなたが私に耳を傾けるなら。すべての色を少し変えれば、彼はとても幸せになると思います。しかし、はい、ある時点でカスタマイズを超える必要があります。最初に、UIフレームワークはレゴツールのようなものであり、一種のツールボックスであるためです。そのため、ボックスにはさまざまなコンポーネントが含まれていますが、これではページは作成されません。まだヘッダーが必要です。フッターも必要です。フレームワークになかった追加のコンテンツがまだ必要です。そのため、コンポーネントを必要なものに微調整できる場合があります。私が理解したところによると、カードコンポーネントを使用してモーダルウィンドウを作成していますが、モーダルウィンドウの特徴は、実際にはカードのように動作しないことです。

ステファニー：あなたはそれを少し超えているようなものです。あいまいな背景が必要です。通常、カードがインターフェイスにすでに存在しているときに、クリック時にトリガーする必要があります。このカードコンポーネントを使用しているのは、背景、上部のヘッダーとタイトル、下部のいくつかのボタンなど、必要なものがたくさんあるからです。構造ができたので、少し調整します。しかし、セマンティクス、HTMLについても競合が発生することがあります。たとえば、ボタンの形を持たないボタンが欲しかったので、リンクボタンと同じように、開発者は「わかりました。あなたのhrefリンクのようなリンクを使用します」と言いました。私は言いました｢いいえこれはリンクではありませんボタンです。クリックしても新しいページは開きません。フォームに含まれるすべてのものをクリアします。」

ステファニー：つまり、技術的には意味的な観点から、ボタンである必要があります。 "うん。しかし、それはフレームワークには存在しません。」私は「大丈夫、私は知っているので、私たちは何をしますか？」と言います。ですから、通常、あなたはこれらのささいなことについて話し始めます。私は開発者にもアクセシビリティについて本当に迷惑をかけているので、これは、開発者がうまく機能する基本的なコンポーネントがあることを確認するためのもう1つの追加レイヤーです。しかし、それらは意味的には、gif内のgif内にgifを持つボタンを持ちたくないようなものです。そうしないと、最終的に問題が発生します。

ドリュー： UIフレームワークを使用する新しいプロジェクトを開始するには、おそらく何らかのユーザー調査から始める必要があると思います。

ステファニー：はい。

ドリュー：それは公平ですか？

ステファニー：そうすべきです。必要がある。そうです、通常、必要なすべてのコンポーネントを使用できます。あなたはまだあなたのユーザーがページ上で何を必要としているのかを知る必要があります、彼らはどのようにナビゲートするつもりですか？フローを作成する必要があります。したがって、通常、フレームワークを決定する前でも、私たちが行うことは、ユーザーのところに行き、ユーザーと話し、ユーザーのニーズを理解しようとすることです。ですから、現時点では、ユーザーは銀行の内部にいるので、私は非常に幸運です。ですから、私たちは彼らと多くのワークショップを行っており、それが非常に複雑なインターフェースであることを想像する必要があります。私たちは、10年または15年前に構築されたものから、Material-UIReactを使用してまったく新しい光沢のあるものに移行していると思います。したがって、これは非常に大きな変化であり、この15年間で、何かを求めている人は誰でもサポートに行き、ITチームにそれを実装するように依頼する可能性があることを理解する必要があります。ですから、現時点では、私のインターフェースは、テーブル、テーブル内、テーブル内、他のテーブル、およびテーブルにあるべきではないものを含む400ページのようなものです。

ステファニー：キーバリュー、キーバリュー、キーバリューだけのものがたくさんあるように。したがって、2つの列を持つテーブルを作成します。「いや、それでもっといいことができるかもしれない」みたいな感じです。そのため、現時点で私たちが行っているのは、ユーザーのさまざまな目標を理解するためにユーザー調査を行ったことです。したがって、私たちが特定したのは、彼らがインターフェースで何をするかということです。彼らにはいくつかの計画目標があります。彼らは自分たちの仕事を計画する必要があります。ですから、この作戦がこの会議に行くことを知りたいので、そのスケジュールでそれが必要です。彼らは物事を監視したい、彼らはデータを報告したい。したがって、監視は、データを調べてすべてが正常であることを確認するのと同じです。レポートは、データを活用し、共有したいデータを使用して、同僚とのコラボレーションを行うことができます。また、ユーザーと直接話し合うことで、私たちが発見したすべてのことを行うことができます。

ステファニー：そして私たちが発見したのは、実際に私たちが最後に移行することを計画していたもののいくつかは、ユーザーにとって日常的に最も重要なもののいくつかであるということです。したがって、planificationユーザーの目標は、現時点で最大の目標の1つです。ですから、私たちは本当に、本当にそれに取り組んでいます。そうですね、インタビューを使用しています。現在、シェルを構築する必要があると言って超高レベルになっている段階にあります。ナビゲーションを理解する必要があります。しかし、現時点では、すべてのデータを実際に調べたわけではなく、これが今やろうとしていることです。テーブルがたくさんあるので面白いです。スマートではない方法でテーブルを新しいインターフェイスに配置するだけで完了です。または、わかりました。何を理解してみましょう。それらのテーブルは、ユーザーはこのテーブルを何に使用しますか？

ステファニー：そして、おそらくいくつかのテーブルをデータの視覚化として表示することができます。そのためには、データが意味をなすようにビジネス全体を理解する必要があります。ですから、あなたが素晴らしいフレームワークを持っていて、あなたが言うなら、このチャートを使ってみましょう…私はチャートJSフレームワークと呼ばれていると思います。ヒストグラム、円グラフ、グラフなど、さまざまなものがありますが、ある時点で、決定を支援するデザイナーが必要になります。さて、このデータは、グラフに表示するか、全体の一部を表示したいのでパイとして表示する方が理にかなっていますか、または過去10年間の1つの国の進化を比較したいので意味がありますか数年後、ヒストグラムはより興味深いものになります。したがって、ユーザーがデータをどのように処理したいかに基づいて、まったく別の方法でデータを表示します。

ステファニー：そして通常、それを行うのは開発者の仕事ではありません。私たちの開発者、彼らはとても賢い人です。申し訳ありませんが、私は正直に男性の開発者と協力しています。女性がいればいいのですが、違います。それらのどれも女性ではありません。とても賢い人ですが、彼らは言う資格がありません、わかりました、このデータはそのように表示されるべきです、それ、それ、そしてそれ。したがって、最終的には、何人かのデザイナーがユーザーと話をし、データで何ができるかを理解する必要があります。これは、タブバーまたは左側のナビゲーションであると言うだけではありません。

ドリュー：そして、ユーザーとの会話に基づいてそのような決定を下した後。通常、作成されたプロトタイプまたはデザインをユーザーに戻し、ユーザーがチャートの選択のタイプを理解しているかどうかを確認するために、それらを再度テストしますか？

ステファニー：ええ、私たちは実際にそれをたくさんしました。それは、それが有用で使いやすいものになることがわかるまで、何かを開発しないので、本当に素晴らしいことです。ですからそれは状況次第です。すでにほとんどのコンポーネントが含まれているため、実際に物を開発する方が早い場合、私が通常行うことは、本当に迅速なペーパープロトタイピングを行い、データがなくても迅速であるために物を開発することです。複雑なもの、開発に時間がかかる本当に新しいものの場合は、いくつかの画面を設計し、画面上で直接テストを行います。つまり、InVisionと呼ばれるツールがあります。このツールでは、基本的にすべてのデザインを配置し、さまざまなパーツ間にリンクを作成できます。それはあなたが何をテストしたいかにもよるということです。たとえば、電話をテストしたい場合、InVisionでテストするのは悪夢です。なぜなら、人々は実際にそれらを感じることができないためです。特に、たとえば携帯電話ではそうです。

ステファニー：それで、それはいつも一種の賢いことです。最も速くて安い方法は何ですか？デザインのみをテストする方が速くて安いですか。これで十分ですか？通常、フォームの場合、実際にはユーザーがフォームに入力するフロントエンドにかかるすべての手間のかかる作業を自動で完了するためではありません。フォームの場合は、実際にフォームを作成してテストする方が効率的かもしれません。しかし、新しいことについては、ええ、私たちはたくさんのデザインをします。ユーザーのところに行きます。ですから、現時点では1対1で行っていますが、私のユーザーは本当に忙しい人です。それはヨーロッパの投資銀行なので、彼らはそれほど多くの時間を持っていません。したがって、私たちが通常行うことは、ユーザーと1対1で対応する場合、フォーカスグループのような小さな会議を行うことです。そして、それはまた、あなたが時々一種の対立を持っているので、興味深いです。「そうだね、あんな仕事をしているので、うまくいくと思う」と言う人もいれば、「あんな仕事をしているの？実際にはありません、私はそのようにそれをします。」

ステファニー：それで、部屋に数人の人がいて、会話だけを聞いて、メモを取り、「ああ、それならできるかもしれない」と「このコンポーネントは、私が聞いた。" そして、そのようなもの。

ドリュー：あなたがあなたの製品のためにより一般的な聴衆と一緒に働いているなら。それで、おそらくあなたのような内部ユーザーではなく、もっと一般の人々が、デザイナーが研究をそのように利用できる安価な方法はありますか？ユーザーが誰になるかを直接知らない場合、より簡単な方法はありますか？

ステファニー：製品を作る前に、彼らが誰になるかを知っておく必要があります。そうしないと、マーケティング担当者の仕事をします。しかし、ええ、たとえば、ゲリラユーザーテストをいくつか行いました。たとえば、InVisionを引き続き使用できます。したがって、InVisionでいくつかのプロトタイプを作成してから、たとえばソーシャルメディアを介してユーザーを募集することができます。私は、名前が何であるか、物事を修理する自動車販売店の整備士、そしてクライアントに追加の修理についても知らせるのに役立つ製品のために働いていました。そのため、LinkedInとFacebookにはすでに成長しているコミュニティがありました。だからあなたができることはあなたがそれらの人々を募集することができるということです。オンラインツールのようなツールで会話をしているように、リモートテストを行うことができます。画面共有を行うことができます。だから私たちはいくつかのプロジェクトでもそれをしました。

ステファニー：私が使っていたので、appear.inと呼ばれていたので、前にツールをテストすることをお勧めします。名前をWherebyか何かに変更したと思いますが、実際に言ったのはブラウザです。ユーザーは何もインストールする必要がないので、ユーザーは実際のコンピューターを使用していませんでした。彼らはVMに、Citrixに、そしてマイクを持っていなかったので、私たちがやったことは、彼らが私のツールを使って画面を共有したようなものでした。彼らはプロトタイプをクリックしていたと同時に、私は彼らに固定電話のように電話で直接話をさせました。ですから、採用の素晴らしい日だったので、これはかなり安かったです。10人のユーザーがいたと思います。ええ、顔を合わせることができなくても、たくさんのことができます。私は、Skypeなどで直接多くのユーザビリティテストを行いました。したがって、それを行うには常にいくつかの安価な方法があります。

Drew：使用するUIフレームワークを選択する場合、それが目的のルートである場合、それは開発者だけに任せるものですか、それともデザイナーも関与する必要があるものですか？

ステファニー：私にとっては、チーム全体を巻き込む必要があります。デザイナーのように、開発者、もしあればアーキテクトもいるでしょう。フレームワークの構築方法もこの種のものに影響を与える可能性があるからです。残念ながら、彼らがプロジェクトに到着したとき、ほとんどの場合、フレームワークはすでに決定されていました。いいえ、実際には面白いです。すでに決定されているか、フレームワークの選択を検証するように求められますが、レビューや調査は行いませんでした。彼らは私に彼らのスクリーンさえ見せなかったので、私はプロジェクトに何が含まれているのか全くわかりません。彼らは「ええ、あなたのことをしてください。このフレームワークを使用できます。」わからない。さて、画面はありますか？そのため、最終的にいくつかの画面が表示されました。これは、クラウドに移行したいWindowsネイティブアプリでした。彼らは、「ええ、必要なのはボタンだけで、ほとんどの場合、フォームなどが好きです」と述べました。

ステファニー：しかし、「ええ、このフレームワークに行きましょう。必要なすべてのコンポーネントが揃っています」と言うのは本当に難しいです。または、「コンテンツがどうなるか、ナビゲーションはどうなるかについて大まかな考えがない場合は、行かないでください。」したがって、すべてのコンポーネントが揃っていることが100％確実でない限り、フレームワークを選択する前に、ある種のグローバルな概要を把握しておく必要があると思います。しかし、ほとんどの場合、フレームワークの選択は基本的に開発者が現在どのようなテクノロジーを好むかに基づいていると感じています。彼らはその前にフレームワークの経験がありますか？いくつかのプロジェクトでAntを使用したのは、数人の開発者がそれを経験していて、本当に気に入っていて、Antを効率的に使用していたからです。また、Material ReactUIの場合も同じです。これは、開発者が以前のプロジェクトですでに使用しているため、効率的であるためです。

ドリュー：つまり、開発者が慣れていること、知っていること、テクノロジースタックで何が機能するか、そして優れたユーザーインターフェイスを作成するための製品の要件との間でバランスを取る必要があります。そして、あなたはどういうわけかそれのための理想的なフレームワークを見つけるためにそれらの2つのバランスをとる必要があります。

ステファニー：はい。あるプロジェクトにはある種の特定の要件があります。それは…私はルクセンブルクにいます。ヨーロッパの機関などがたくさんあるので、それらのいくつかには追加のアクセシビリティ要件があります。そして通常、フレームワークが決定されたとき、彼らはフレームワークのアクセシビリティについて実際にチェックしませんでした。そして、プロジェクトの開始から数か月後に、「ああ、この新しい法律があると私たちに言ったので、私たちはすべきです。アクセス可能ですが、その方法がわかりません。」ええのように、それは少し手遅れです。したがって、私にとって、フレームワークを選択するには、プロジェクトの開始時にすべての制約を知る必要があります。アクセシビリティがそれらの1つである場合は、コンポーネントをテストして、それらがアクセス可能になることを確認する必要があります。しかし、私はReactやAngularの開発者ではありませんが、アクセスできないUIフレームワークをアクセス可能なものに変えるのは非常に複雑だと確信しています。すべてのコンポーネントを再構築するのは少し複雑かもしれないので、そのようなことです。

ドリュー：そのプロセスが行われておらず、UIフレームワークがすでに選択されているプロジェクトで作業していることに気付いた場合、ユーザーインターフェイスが、そのフレームワーク内にすでに存在するコンポーネントではなく、そのフレームワーク内にすでに存在するコンポーネントの影響を受け始める危険性がありますか？ユーザーのニーズに駆り立てられていますか？

ステファニー：正直なところ、私が取り組んだプロジェクトのほとんどは、実際にプッシュしようとしても、最終的には多くのトレードオフが発生することになります。つまり、それは主にバランスと開発者との話し合いに関するものです。ですから、通常、私が行うことは、いくつかのワイヤーフレーム、さらには簡単な紙のワイヤーフレームを行うことです。このページでは、それとそのコンポーネントが必要になります。最初に行うことは、開発者にそれを持っているかどうかを尋ねることです。現時点でのフレームワーク？それはどのように見えますか？そして、私たちは一緒に決定します、わかりました、これは仕事をするコンポーネントであるか、またはこれは仕事をしません。微調整しますか？コンポーネントを保持しますが、それが機能するように少し変更しますか、それともゼロから何かを構築しますか？

ステファニー：そして、結局のところ、それはもちろん予算に依存します。したがって、トレードオフを行うことになりました。完璧でなく、問題がほとんどない場合は、ほとんど使用されない小さなコンポーネントでも大丈夫です。しかし、メインナビゲーション、メイン構造、たとえば画面に常に表示されるものについては、これは実際に機能する必要があります。ユーザーは、ユーザーがどのように効率的に機能するかを理解する必要があります。そうです、あなたが言ったように、フレームワークがなかった場合に望む理想的なエクスペリエンスと、手元にあるものと予算、そしてタイミング。これらのスプリントの場合、機能はこのスプリントの最後に終了する必要があり、その後、彼らは「大丈夫」と言いますが、コンポーネントが必要な場合は、このスプリントの最後に機能を終了することはありません。話し合いを始めましょう。次の画面でこの機能を終了しますか？適切に実行するにはもっと時間がかかりますか？そして通常それは本当に依存します。

ステファニー：私が最もイライラするのは、作物修正コンポーネントを使用していることを知っていて、「ああ、心配しないで」と言われたときです。後で修正します。そして、残念ながら、後者は決して起こらないかもしれないことを私は知っていました。だからチームに依存します。しかし、しばらくすると、あなたは経験を積んで、あなたは知っています、これは後で到着するのでしょうか、それとも到着しないのでしょうか？ええ、それは妥協についてです。これらの種類のツールを使用している場合。

Drew：私自身、開発者として、UIフレームワークについて私が気に入っていることの1つは、デフォルトのスタイルが付いていることが多いことです。つまり、すべてのコンポーネントのルックアンドフィールを手伝ってくれるデザイナーが必ずしも必要ではないということです。それは私たちがプロジェクトで頼るべきものですか？フレームワークを作成した人がこれらのコンポーネントの設計で本当に良い仕事をしたというデフォルトのスタイルと信頼だけですか？それとも、これらのコンポーネントを自分でスタイリングしますか？

ステファニー：それは本当に状況次第だと思います。たとえば、Material-UIの問題は、Webアプリのルックアンドフィールが基本的に構成されたGoogle製品になることです。したがって、実際にフォントを変更せず、いくつかの色を変更し、独自のブランドアイデンティティを持ってそれを行うと、他のGoogle製品と同じように見える製品が得られます。ユーザーはGoogle製品に慣れているため、理解に役立つ可能性があります。それで、通常、チームにデザイナーがいない場合、選択肢はありますか？私が見た多くのさまざまな作品のように、それらにはカスタムテーマが付属しているので、少なくとも色を変更することができます。フォントもかなり簡単に変更できると思います。しかし、繰り返しになりますが、色を変更してデザインやアクセシビリティさえもあまり得意ではない場合のように、使用する色が衝突したり、コントラストの問題が発生したりする可能性があります。

ステファニー：たとえば、私はオレンジが大好きですが、たとえば、白いテキストのボタンとして、実際にアクセス可能なオレンジを使用すると、ほとんど茶色がかった色に見えるため、使用するのが最も厄介な色の1つです。そして、この本当に光沢のあるオレンジにしたい場合は、読みやすくするためにその上に暗いテキストが必要ですが、それは一種のあなたのインターフェースを一日の終わりにハロウィーンのように見せます。ええ、私はあなたが笑っているのを見ます。しかし、それは本当です。つまり、常にこの種の妥協点についてであり、開発者であり、フレームワークをそのまま使用したいが、デザイナーがいない場合は、何も持たずにゼロから構築するよりも優れていると思います。使用するのは非常に複雑です。ただし、コンポーネントがあるからといって、優れたインターフェイスを構築できるとは限りません。それはレゴブロックのようなものです。あなたがレゴブロックを持っているなら、それは大丈夫です、しかしあなたは本当に素晴らしい宇宙船をすることができます、あるいはあなたが本当に計画を持っていなかったので一緒になっておらず崩壊する何かをすることができます。

ステファニー：つまり、デザインはそれ以上のものです。デザインとは、画面に何が表示され、どのように機能するかを実際に理解することです。そして、私は実際にそれを行う能力を持っている何人かの開発者を知っています。そのため、ユーザビリティガイドラインに非常に優れており、たとえば、多くのデザインルールを理解しています。したがって、コンポーネントの選択に関しては、彼らはそれが本当に得意です。そして、どのコンポーネントを選択すればよいかわからない開発者を知っており、その仕事をする最初のコンポーネントを選択します。しかし、しばらくすると、それはもう機能しません。たとえばタブのように、一部の開発者がタブを選択するインターフェースがありました。最初はアイテムが3つしかないのが理にかなっていると思います。しかし、画面に12個のアイテムがあり、3行のタブであるタブがあり、それらはすべて同じレベル1のタブであり、タブ内にタブがあります。それで、彼らはコンポーネントを持っていました、彼らがフレームワークを使うのでそれは見栄えがしました、しかしそれは実際には使用できませんでした。

ステファニー：たとえば、モーダルウィンドウのように同じものを持っていました。彼らがデザイナーなしでプロジェクトを構築し、しばらくすると、クライアントはこのモーダルにますます多くのものを求めたと思います。つまり、テーブルのある画面が表示され、[行の追加]をクリックすると、モーダルが開きます。このモーダルには2つのタブがあり、それらのタブの1つには別のテーブルがあり、それに余分なものを追加します。モーダルの上にモーダルを配置できるかもしれません。そして、ある時点で、デザイナーは、モーダルにそれほど多くのコンテンツがある場合、それはモーダルウィンドウであってはならない、と答えるでしょう。ページである必要があります。したがって、コンポーネントがある場合でも、計画を実行し、それらのコンポーネントがすべて連携して機能することを確認するには、一種のアーキテクトが必要です。

ドリュー：デザイナーとして、一部のコンポーネントのスタイルを変更するように求められた場合、すべてのスタイルを変更してみてください。すべてをカスタマイズしますか、それとも焦点を当てる特定の領域がありますか？

ステファニー：色それはあなたが最初に目にするものなので、色は実際にあなたにアイデンティティをもたらすことができると思います。強力なブランドアイデンティティが好きな場合は、少なくともボタンやアイコンなどに製品の色を付けることで、フレームワークをカスタマイズするのに役立ちます。フォントは簡単だと思うので、フレームワークが適切に構築されている場合は、通常、フォントファミリ全体をどこかで変更してから、サイトの残りの部分にカスケードする必要があります。つまり、色とフォントは、フレームワークをすばやくカスタマイズする2つの簡単な方法だと思います。アイコンは個性をもたらすもう1つの優れた方法ですが、私が見たところ、ほとんどのフレームワークにはカスタムアイコンやFont Awesomeが付属しているか、ライブラリがすでに組み込まれているため、難しいかもしれません。これらを置き換えるには、まず、それらをすべて置き換えたい場合は、たくさんのアイコン。したがって、少し複雑になる可能性があります。また、使用するアイコンパックを選択できるフレームワークも確認しました。 Font Awesome、Glyphicons、その他のいくつかのように。つまり、これは非常に簡単にカスタマイズできる種類のものです。

ステファニー：それから、ルックアンドフィールについてです。たとえば、ヘッダーです。通常、さまざまな種類のヘッダー、フッターがあります。そのようなことをどのようにナビゲートしますか。そのため、Material-UI風に見えないように、小さなカスタマイズをすでにたくさん用意しています。たとえば、ブランドのように見えて、境界線の半径を試してみることができます。完全に丸みを帯びたボタンが必要な場合でも、正方形のボタンが必要な場合でも、影のように真ん中に何かが必要な場合でも。そのため、これらのフレームワークのほとんどはCSS変数に含まれているため、通常は簡単にカスタマイズできる小さなものがいくつかあります。これは、これらの波及効果を除いて、多くの労力をかけずにカスタマイズできる種類の小さなものです。嫌いです。私はそれと戦うつもりです。彼らが最終的にそれを変えることを願っています。

ドリュー：そういうことは、当たり前のように見えるかもしれませんが、表面レベルの効果のように見えるかもしれませんが、それは簡単に変更できると思いますか？この場合、変更するのは簡単ではなかったことがわかりますか？ Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. あなたは知っていますか？

Drew: Yup.

Stephanie: It does. わかった。 So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. 動作しない可能性があります。

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.