Slide 1

Slide 1 text

STORES のデザインシステムの これまでと現状 Frontend Talk 〜デザインシステム構築のリアルな裏側〜【hey|note|ANDPAD】 2022/03/10

Slide 2

Slide 2 text

#hey_note_andpad    話し手 藤井 大祐 リテール本部 フロントエンドエンジニア 井出 優太 プロダクトデザイン本部 デザイナー @daitasu @_ideyuta

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

デザインシステムのこれまで 1 現在の課題 2 これからのこと 3

Slide 5

Slide 5 text

デザインシステムのこれまで 1

Slide 6

Slide 6 text

heyができる 2018 STORES.jpとCoineyが統合してheyが誕生した

Slide 7

Slide 7 text

STORES レジ のデザイン開始・どうしよう? 2019 レジは、ネットショップ・決済と一緒に使ってもらうことを目指したプロジェクトなので、全体の体験をどうやって統合していくか も考える必要があった。新しいプロダクト、統合されたブランドとして、どんなデザインにしていくのが良いんだろうか... ?

Slide 8

Slide 8 text

ブランド統合へ 2020 ひとつのブランドの中に、複数の製品があり、それらをまるっと提供することでより価値を大きくするという戦略を実行していくた めに、象徴としてのブランドをまずは統合した。カラーパレットやブランドイメージも更新され、さて....

Slide 9

Slide 9 text

ネットショップ管理画面のデザインリニューアル 2020 ブランド統合時に決定されたカラーパレットを使ってスタイリングを考えたり、既存の課題を解消しながら、レジが入ってくること に備えてリニューアルをおこなった。STORES らしいデザインを考え始めた初期的な段階のデザイン。

Slide 10

Slide 10 text

リニューアルを進めながらわかったことをふま えて、目指したい方向を考えはじめた...

Slide 11

Slide 11 text

当時の思考のdump 2020 5 我々はどこにいきたいのだろうか... 前提 ● サービスが4つある(ネットショップ・ターミナル・レジ・予約) ● プロダクトが12こある ○ ネットショップ 3つ(ストア・ダッシュボード・ストアデザイン) ○ ターミナル 4つ(管理画面・iOS/Androidアプリ・SDK・請求書決済) ○ レジ(iOSアプリ) ○ 予約 4つ(管理画面・予約サイト・管理画面アプリ・顧客向けアプリ) 課題 ● ブランドは統合されているけど、同じルールでプロダクトがデザインされていないのでツール の学習コストが高い ○ 現在は併用ユーザーが少ないのでクリティカルではない ● ルールが多数あると管理コスト・属人性が高くなる ● 新しく作るプロダクトが従うべきルールがない ● 横断的なルールがないので局所で迷うことが多い ○ ブランドガイドラインのみ ● プロダクト横断的な体験設計はどこでどうやる? ● どうすれば無視されない共通ルールを作れるか ○ 開発・デザイン横断の専門部隊がないと難しそう? ○ どうやって運用するかをセットで考える必要がある ■ 漸進的に適用できるのかとか(ECは今後はできそう) ■ ターミナルはどこかでリプレイスが必要かも ○ デザインシステム自体はとにかく先にできていないと何もできない どう管理するか ● 各プロダクトのUIは統一的なデザインシステムに則った方が良いか? ○ 理想的には則った方が良い ■ ツールを利用する学習コストが減る ● プラットフォーム(web/iOS/Androidなど)の原則には基 本的に従って作る ■ 車輪の再発明がなくなることでデザイン・開発コストを下げられる ○ 新たに作るプロダクトに関しては則る ■ レジ ■ 共通管理画面 ■ このためのデザインシステムは必要 ● 作る ● 効率的に管理するには? ○ デザインシステムがある プロダクト横断的な体験設計 ● 各プロダクトから1人連れてきて考え続ける感じ? ○ 空いてる誰かをアサインして、各プロダクト担当にレビューしてもらうとかそういう 感じになりそう ● デザインチームだけで完結しなそう

Slide 12

Slide 12 text

ひとりのユーザーが複数のプロダクトを横断的に使用する

Slide 13

Slide 13 text

当時の思考のdump 2020 5 デザインシステムは、どこまでの領域をカバーし、どういった役割を持つのだろうか...

Slide 14

Slide 14 text

素案をまとめた 2020 11 まだエンジニアからのフィードバックを受ける前の素案。どういうところを目指したいかという話が中心だった。

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

#hey_note_andpad    2020年末 当時の状況 ● STORESレジ(iPadアプリ)はデザインシステムに則る ● ウェブアプリもこれからはデザインシステムに則ったUIにして いきたいな ● プロダクトそれぞれフレームワークが異なる(そもそも作って る会社が違ったので)けどどうする? ● デザインシステムの実装はどう進めていくのが良いのか...?

Slide 17

Slide 17 text

#hey_note_andpad    ウェブ、どうしよう M&Aや内製でプロダクトは増えていく予定だし、統一するにしても横断 組織もない。小さく各地ではじめられる方が良いのではなかろうか...

Slide 18

Slide 18 text

#hey_note_andpad    tailwindcssを起用 ● utility-first CSS framework ● カスタマイズ可能なユーティリティ クラスのみを吐き出す ● jsやhtmlは提供しない ● config統一で吐いたユーティリティク ラスを各プロダクトで利用する ● いつか共通ライブラリへ移植できた らいいね

Slide 19

Slide 19 text

ID基盤プロジェクト・フロントエンドはCTOとideで実装 2021 4 STORES のアカウントを統合していくために、ID基盤をリリース。 デザインの細かいところを決めつつ、tailwindを使って本当にこれでいけるのかを試していった

Slide 20

Slide 20 text

レジリリースに向けて、管理画面の実装がはじまる 2021 レジは、ネットショップのシステムを拡張して作っているので、商品の管理や注文の管理がひとつの製品の中でできるようになって いる。そのため、ネットショップだけ利用したい人、レジだけ利用したい人も迷わないように設計を変えていく必要があった。

Slide 21

Slide 21 text

#hey_note_andpad    当時の状況 デザインシステムは検討中のUIもたくさんある でもレジのリリースは迫ってきている

Slide 22

Slide 22 text

#hey_note_andpad    デザインシステムにどこまで対応するか 1. これまでの既存デザインにする 2. tailwindは使わずに既存のコンポーネントを デザインだけ新しくする 3. tailwindで新規にSTAND UIを作る

Slide 23

Slide 23 text

#hey_note_andpad    デザインシステムにどこまで対応するか 1. これまでの既存デザインにする 2. tailwindは使わずに既存のコンポーネントを デザインだけ新しくする 3. tailwindで新規にSTAND UIを作る

Slide 24

Slide 24 text

#hey_note_andpad    Action:デザイナーとの連携を密に、叩き上げていく ④ configリポを修正し、各プロ ダクトに愚直にコピペ ① tailwind configを最低限のみ確定 ② デザイナーとの昼会を毎日実施 ③コンポーネントごとにstaging確認 デザインの変更差分を 愚直にSync tailwind config ID基盤 ネットショップ・レジ 管理画面 …

Slide 25

Slide 25 text

レジも無事にリリース・スタイリングが一定完成する 2021

Slide 26

Slide 26 text

各地で改善が進んでいたり、ガイドラインを書いたり、 UIコンポーネントのアップデートが進んでいたり 2021 ~22

Slide 27

Slide 27 text

#hey_note_andpad    STAND 現状の構成 config Component  Library  EC/レジ 予約 ID 基盤 レジアプリ 予約アプリ STAND Web STAND iOS STAND Regi 各地で色々頑張っている...

Slide 28

Slide 28 text

現在の課題 2

Slide 29

Slide 29 text

#hey_note_andpad    課題がいっぱい ● 今はまだUIコンポーネント集。作ったけど、課題もたくさん出てきた ● 適切なUIよりも既存のUIで組み合わせる方を選択されてしまったりも ● イラストとか楽しさとわかりやすさを注入していくにはどうすれば ● コンポーネント以外のデザインルールはデザイナーの脳内 ● 今後の変更差分をどうやって同期するの ● デザインシステムを改善していくチームの目標・評価は ● エンジニアの専任チームがない ● アップデートの運用の仕組みが整ってない ● 事業と比較されると優先度が低く見られてしまう

Slide 30

Slide 30 text

#hey_note_andpad    トライ:UI改善 stand act2 UI 改善案の検討

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

#hey_note_andpad    トライ:ドキュメント作成

Slide 35

Slide 35 text

#hey_note_andpad    トライ:ドキュメント作成 理念 エクスペリエンスバリュー STORES の景色 デザイントークン  ロゴ・シンボル  カラーパレット  タイポグラフィ  … コミュニケーションガイドライン  ボイス&トーン  用語  … ウェブ管理画面  UIコンポーネント  設計ガイドライン  開発ガイドライン モバイルアプリ  … レジ  … ストアフロント  … サービスサイト  …

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

これからのこと 3

Slide 40

Slide 40 text

#hey_note_andpad    その先へ デザインシステムを磨き上げていくチームと、事業価 値をデリバリーしていくチームをうまく接続して、高 い品質の製品を早く届けられるように。 ● UIデザイナー(スペシャリスト) ● デザインエンジニア ● プロダクトデザイナー ● フロントエンドエンジニア

Slide 41

Slide 41 text

#hey_note_andpad    その先へ ユーザーの学習を助け、デジタルプロダクトを使いこ なし、商売や仕事が楽しくなる人を増やせるように。 ● LXデザイナー ● プロダクトデザイナー ● コミュニケーションデザイナー

Slide 42

Slide 42 text

#hey_note_andpad    募集中 https://hello.hey.jp/ フロントエンドエンジニア デザイナー