いいUXはいいデザイナーから!
今回はプロダクトのUXを向上させるために必要なことについて先週開催されたMercari Design Talkで発見があったため記事にしたいと思います。
1, 導入
2, いいプロダクト作れるチームとは
3, デザイナーって何するべきなの?
4,おまけ
1,導入
私はよくプロダクトを発想することがあり、その際に様々なプロダクトのデザインを見て回ることがあります。その中で、このUIデザインいいな、このデザインフロー、ページフローのUXいいなと思うことがあるのですが、具体的に何がいいのかは考察できても、それがどのような工程で作られているのか分からず、自分で再現する方法を探していました。
以前Navigation UIの作り方という題の記事を描きました、あれは自分一人で作るという前提でした。しかし、仕事というのはそうもいきません。ましてやより大規模なサービスのを作るとなればなおさら一人では限界が来てしまいます。一人でできることには時間という制約があり、その制約の中で各々が自分の得意なことをチームでこなす必要があります。これはWeb業界以外にも言えることです。
ではどのようなチームがより良いUXのプロダクトを作れるようになるでしょうか。
今回はこのことについて12/7に開かれたMercari Design Talk #3 の内容を踏まえながら考察していきたいと思います。
2, いいプロダクト作れるチームとは
ズバリ言いましょう。優秀なデザイナーがいるチームです。
とはいったもの、嫌々そんなデザイナーだけじゃうまくいかんでしょうと、言いたい気持ちはわかります。しかし、どんなに実装の早いエンジニアとマネジメント力のあるマネージャーとビジョンのあるプロデューサーがいても、目にみえるデザインがなければプロダクト作ることすらできません。つまりデザイナーは絶対条件ではなく、最低条件なのです。
多くの企業はデザイナーをあまり重要視しておらず、外部に発注したりや事業部の方がデザインを作ったりしています。こうなってくると前者は自分の作っているプロダクトに完全な熱量を割いてくれないですし、後者はデザインのプロではないのでなかなかうまく要件定義が進まなかったりなどはザラにあります。
大切なのは、自分のチームに同じ目線のデザイナーをジョインさせることなのです。
ではデザイナーがいることでプロダクト開発にどのようなワークフローが生まれるのかみてみましょう。
こうしてみると、いくつかのワークフローにおいてデザイナー重要な役割を果たしているのがわかると思います。デザイナーがPMともに過去と現在のUXR(UX Research)を行い(Discovery)、そこからプロダクトの戦略(Strategy)や軸(Concept)を練っていく。それが終わってようやくWire framingに入り、PMやDeveloperからFeedbackを得て、最終デザインを完成させ(Finalization)、ようやく実装が始まる(Dev Support)のです。つまり、デザイナーとはただ見た目を起こすだけではなく、そのプロダクトについて抽象的な部分と具体的な部分のどちらについても語られる人間にならなければならないのです。それこそが良いデザイナーなのだと私は考えます。
3, デザイナーって何するべきなの?
ではプロダクトを通してデザイナーどのようなフロー踏んでいるのかはわかりましたが、よりその具体的なスコープの中身をMercariさんの資料を参考に見ていきます。見てみたいと思います。
何やらDesign review なるものが二つあるみたいですね。
オープンなFeedBackの場と、ClosedなFeedBackの場でクオリティを上げるようです。
前者では、デザインの視野を広げられそうですし、デザイナー通しのコミュニケーションにもなって楽しそうです。後者ではゴールまでぶれないように人数を絞ってFinalizeしていくのは非常に効率的で良いと思いました。詰まるところ、デザイナーも一人ではなくチームとなって視野を広げていく必要があるということですね。Design Reviewを行うことで、プロダクトのブラッシュアップはもちろん、UXの向上やデザイナー同士の関わりを増やし、チームもプロダクトも丁寧に豊かに育てることができそうです。エンジニアはよく開発チームを組みますが、デザインとなると一人だけなんてこともザラにあります。しかしそうではない、デザインチームあって然りですね。
UX DesignerとUX Researcherの違いは一枚目の画像を参照
UX designer まとめ
4,おまけ
最後にMercariさんが考える、議論の仕方について共有して終わりにしたいと思います。
デザインとは見た目を作る作業なので、どうしてもその議論は見た目の良し悪しの話に傾いていきがちです。そんな時に気を付ける、というよりかは意識することがあります。それが、課題/仮説で始まって、課題/仮説の解決が達成できているかの確認で終わるという流れを徹底することだそうです。
こうすることでどの議題においてもそのデザインの良し悪しではなく、根本的な部分の議論ができるわけです。エンジニアリングにおいても、コーディングの良し悪しではなく、そもそもそのコードはユーザの課題/仮説を解決するに足るコードなのか、という視点でみるということだと考えます。デザイナーはこのような視点で議論をする力も求められるというわけです。
終わりに
いかがでしたでしょうか。自分は駆け出しフルスタックエンジニア(?)として活動する中でいつもデザインの質というもの考えていました。今回は将来的にどのようにデザインにアプローチをかけるべきなのかのヒントを掴むことができたと考えています。もしデザイナーとして働いてみたいと考えている方のヒントになるものを残せていたら大変嬉しいです。ここまで読んでいただきありがとうございました。
どこに置く? Navigation UI
分かりやすい Navigation UI ってなんぞや?
メニューを作ってみたけどなんだかまとまりかける...
かっこいいNavigationのUIを見つけたけど、どうにも自分のプロダクトに落とし込めない...
と悩んだことはないでしょうか?
今回は 「どこに置く?Navigation UI」ということで個人的に考えるNavigation UIの作り方について記事を書きたいと思います。
< Navigation UI とは >
Navigationと聞くとどんなものを思い浮かべるでしょうか。
様々ある方と思いますが、その役割は大きく分けて二つあると考えています。
1) そのアプリで何が見れるのか “ Veiw Navigation “
2) そのアプリで何ができるのか “ Action Navigation ”
次で具体的に見ていきましょう。
<要件の分類/分析する>
例えば以下のような要件定義のスマホタスク管理アプリがあるとします。
・アプリの設定画面
・有料プラン登録の機能
・ユーザーにアカウントを持たせ、TaskContetのPostできる機能を入れる
・Taskに期限を持たせるためにカレンダー情報を付ける
・Taskにtodo/doing/doneの三つの状態を持たせて任意に状態を変更できるようにし、TaskPostsを状態に依存して表示できるようにする
・ユーザのTask達成情報などアナリティクスを見れるようにする。
こちらを少し分解して先ほどの二つの要素に分類してみます。
1) “ Veiw Navigation “
・アプリ情報を表示
・有料プラン登録情報を表示
・アカウントの情報を表示
・TaskContentの情報を表示
・カレンダーからTask情報を表示
・TaskPostsの情報を状態に依存して表示
・Task達成情報などアナリティクスを表示
2) “ Action Navigation ”
・有料プラン登録できる
・Task ContentをPostできる
・Taskにカレンダー情報を追加できる
・Taskにtodo/doing/doneの三つの状態を変更できる
次に、先ほど出た項目を分析して以下の二つを考えます。
1) 何に依存するか
2) ユーザーがみたいのはどれか
1)
Task → ユーザー
TaskPost機能 → ユーザ&Task
カレンダー → Task
Task状態 → Task
アナリティクス → Task&ユーザー
ユーザー → アプリ
有料プラン → アプリ&ユーザー
アプリ設定 → アプリ& ユーザー
2)
要件 : 優先度
Task : 1
TaskPost機能 : 2
カレンダー : 3
Task状態 : 4
アナリティクス : 5
ユーザー : 6
有料プラン : 7
これらの分類/分析を元に根拠立てて組み合わせ、UIを作り上げるとこのような配置になりました。
順番に追っていきましょう。
1, Footer ツールバー
まず、ユーザー優先度の高い項目(カレンダー/Task状態/アナリティクス)かつTaskに依存するもの(カレンダー/Task状態/アナリティクス)は使いやすい手元に来るべきですので、いわゆるツールバーとして下にまとめるべきでしょう。
しかし、ユーザ優先度の高いTaskPost機能は他の項目と違いAction Navigationですのでより強調されるとユーザーは見やすいかもしれません。そのため大きなボタンにします。
2, Main(真ん中の部分)
こちらは言わずもがな一番優先度の高いメインコンテンツであるTaskを表示させるべきです。
2,Header
ユーザーの情報はどうでしょうか。こちらもユーザーが頻繁に使う項目かと思いますが、依存先がアプリであるため、Taskに依存する他のNavigationとは区別するべきです。しかし、同じアプリ依存である会員登録やアプリ設定はユーザー情報よりも優先度が低いため区別して配置するとより使いやすいかと思います。(ハンバーメニューに画像ではまとめています)
最後まで読んでいただきありがとうございました。
今回は自分の個人的なNavigation UI配置の仕方について書かせていただきました。
また次の記事でお会いしましょう!
【styled-components】フロントエンドでstyled-componentsを使ってみた!
今回はReactでフロントエンドを開発した際にstyled-componentsを使用してCSSを適用させたので、こちらについて「使ってみて良かったこと・使ってみて良くなかったこと・疑問に思ったこと」書かせて頂こうと思います。
そもそもstyled-componentsとは、CSS in JS(JavaScriptの中でCSSを定義すること)の拡張機能ライブラリのことです。Reactのようにコンポーネント(< >で宣言された部品のこと)単位でstyleを管理・適用することできるため様々なメリットがあります。レスポンスの改善や高い保守性、ミスの気づきやすさなどが例に上げられます。
1, 使ってみて良かったこと
まず、タグではなくコンポーネントで要素とstyleが結ばれているため、何に対して何を書いているかが分かりやすかったです。また、一つのファイルの中にHTMLとCSSを記述できるため、検索がしやすく大変便利に感じました。あとはCSSをネスト化して書けるのが最高です!scssなど触ったことがありましたが、Reactの機能の中でネスト化して記述できるのはとても使いやすかったです。
2, 使ってみて良くなかったこと
HTML→CSSで今まで記述していたのですが、styled-componentsは先にstyledが来るため、少し違和感を感じました。確かに見やすいですし記述量も少なく、ファイル内検索もしやすいんですけど、、、。
どことなくバックエンドプログラマーの方の思考で作られたモノのように感じます。これは慣れなのかもしれませんが、ちょっと現時点では違和感が残っています。
3, 疑問に思ったこと
生のHTMLにおいてたまに共通のstyleと、固有のstyleを分けて適応したい時があり、1つのタグに2つのClassを付ける場合があります。今回もそれを使おうと思っていました。しかし、styled-componentにおいては、宣言されるコンポーネント名は一つであり、HTMLでいうClassのようなものが一つしか付与できませんでした。そのため、違う名前にしたコンポーネントに半分同じ内容のstyleを書かなければならず、とても不便に感じてしまいました。これを解決する方法はないのか、と疑問に思ったという感じです。
以上、今回はstyled-componentsについて書かせて頂きました。styled-componentsは宣言的でとても見やすいのでかなり好みの書き方でした。他にもTailWindなども使ってみたいです。
今回疑問に感じた部分は調べてみたいと思います。解決方法がわかり次第、こちらの記事を更新したいと思います。ありがとうございました!
shinshi_onigoori
【Webバックエンド】アーキテクチャの構造について。
今回は開発している中で学んだ、Webバックエンドのアーキテクチャ構造について復習を兼ねて書きたいと思います。特に今回はsrc(source)についてです。
まず、ここで言うアーキテクチャとはsrcフォルダーの構造そのもののことを言います。これは各会社やプロジェクト、個人によって作り方は様々なのですが、ある程度のレイヤー構造の型は存在しています。そのため、一概にこう!とは言えませんが、自分が学んだものをメモ的な形書きたいと思います!
レイヤー1, adapter
adapterはフロントエンドから見た入口、つまりバックエンドの玄関口になるところです。ここに書かれたプログラムはフロントからの情報を受け取り、返す処理が書かれます。具体的には、検索ボタンが押されたら検索の結果を返せ、と命令するイメージです。このような処理は主にadapterフォルダーの直下にcntrollerと名ずけられたファイルで書かれることが多いです。
レイヤー2, usecase
usecaseでは、adapterでは書けなかったシステムの振る舞いを書きます。つまり、次に出てくるdomainの機能群を使ってどのような処理をadapter(controller)に返すか、の処理を描きます。具体的には、ID取得の機能使ってそれを元にデータをデータベースから引っ張ってきてそれをcontrollerに返す、といった処理を書きます。
レイヤー3, domain
ここでは業務知識が書かれます。つまり、ある分野の機能群をまとめるところです。具体的にはコンテンツ管理するという機能群を書くとして、その中にID取得、投稿、編集、削除の機能をセットしておく、というイメージです。
レイヤー4, entity
ここでは、データ定義を管理します。言ってしまえばデータそのものが入っている場所です。具体的には、domainを参考にすると、IDのデータ、投稿の中にあるタイトル、メインテキスト、画像、動画、投稿日時、などといった中身のデータを定義しておく、というイメージです。
レイヤー5, infrastructure
ここではバックエンドの根幹となる部分の処理を書きます。例えばMySQLなどとの交信の処理や、Firebaseなどとの認証の処理、などが挙げられます。
以上5つのレイヤー構造要素について書かせて頂きました。私自身としても、まだinfrastructureで記述されることなどがまだはっきり分かっていない部分もあるので勉強を続けていきたいと思います。ありがとうございました!
shinshi_onigoori
【デザイン】見やすいデザインの4原則
今回は最近学んだ「見やすいデザインの4原則」について書きたいと思います。こちらはWebだけでなく、ポスターやパンフレットなどにも使えることのように感じましたので復習も兼ねて書きたいと思います。
1, 近接
こちらは同じ系列の情報、似たような情報をグループ化してまとめるということです。例えば、人物紹介のページあった際、名前と自己紹介は近づけて他と区別という具合ですね。こうすることでどこまで一つのコンテンツなのか見やすくなります。
2, 整列
こちらは言わずもがな、コンテンツを揃えるということですね。正確には、見えない線を意識することで要素を揃えるということです。視線の移動が少なくなり、見ている人の快適性が上がります。また、テキストエリアで使うと、プラグラフシェイプもハッキリするようになり、見た目がかっちりして格好が良くなりますね。
3, 対比(コントラスト)
こちらはヒエラルキーと言ってもいいかもしれません。これは要素に強弱をつけてあげることで、視線的かつ情報的な優先順位をつけてあげることです。これをすることで伝えたいことに目がつきやすなると同時に、強弱の抑揚による快適性を上げられます。
4, 反復
こちらは要素を繰り返し使うことでデザインに一貫性を持たせることができるようになります。そうすることで見ている側も直感的に情報を掴み取る事ができるようになり、快適性が上がります。
以上、今回は見やすいデザインの4原則について書かせて頂きました。今回はテキスト関連の見やすいデザインについて描きましたが、他にも魅せるデザインについても学んでおりますので、また次の機会に書きたいと思います。ありがとうございました。
shinshi_onigoori
【HTML/CSS】CSSで要素or複数要素を中央に持ってくる方法の研究
CSSでコンテンツを中央に持ってくる方法は二通り知っているのですが、その2つのやり方を復習もかねて書いてみます。
まずは justify-content: center; になります。
こちらはdisplay: flex; をかけることによって記述することができるものになります。(display: flex;とは子要素を左詰めにするプロパティです。)どちらも中央寄せにしたい要素の親要素に記述することで適用されます。しかし、この場合display: flex;をかけると、子要素が左詰めになってしまうため、複数個ある子要素をそれぞれ中央にしたいとおもったときは使えません。
そんな時に使うのが、もうひとつの中央に揃える方法、margin: auto;になります。こちらは中央にしたい要素に直接記述します。これを書くだけで左右のmarginを均等に分配してくれるため、中央に要素が持ってこれます。コツとしては、複数要素の場合はそれを囲うようにして親要素を追加しその親要素にmargin: auto;を記述することです。そうすることで要素が縦に並んだまま全て中央にきます。注意点として、margin: auto;をかける場合その要素のwidthが定義されていないと反映されないというということが挙げられます。こちらに注意して使用してみましょう。
今回はCSSで要素を中央に持ってくる方法について書かせて頂きました。他にもpositionを使った方法などございますが、それについては別途書いて見たいと思います。ありがとうございました。
shinshi_onigoori
フロントエンジニア志望の学生がブログを始めます
皆さんこんにちは!
しがない大学生のshinshi_onigooriと言います。
これからエンジニアリングを中心に日々学んだことや気づいたこと、やってみたいことなどを書いていけたらと思っております。
まだまだ無知な部分があり拙い文章を書くこともあるかもしれませんが、暖かく見守って頂けると幸いです。また、内容について気になることがあればぜひ教えて頂けると嬉しいです!
shinshi_onigoori
2023/05/16