食べチョク開発者ブログ

食べチョクエンジニアによるプロダクト開発ブログ

ふりかえりからデザイナー同士のミーティングを改善しました

デザイン

こんにちは、松久です。

以前、「デザイナー同士で行う 3 つのミーティング設計」というお話を書きました。そこから、半年ぐらい運用していくなかで、変えたことがあります。

変わらないこと

大きく 3 つのミーティングがあることは変わりません。

  • プランニング・交通整理
  • Designer Team Discussion
  • Monthly Update

ミーティングの数も変わらず、時間も変わっていません。

変わったこと

Designer Team Discussion が少し変わりました。 以前は話したことを「📝🍵🍡」の絵文字をつけて、Slack のデザイナーチャンネルにメモしていました。そこから、取り組むことを esa に書き出して Monthly Update で進捗を確認していました。この方法だと、頻度が月 1 回のため成果を出し続けることが難しかったです。 月に 1 回の進捗確認だと、忘れてしまったり、進まなかったと気づくのが 1 ヶ月後になる可能性があります。そこから対応策を決めると、さらに 1 ヶ月かかり、対応までの時間がかかります。デザイナー同士で検討するのにも時間が必要な場合は特に時間がかかります。 このことに、Monthly Update という月 1 回のふりかえりで気づきました。

この問題の対応として、 Designer Team Discussion で気になり話し合いたいことも、見つけた不具合も全て GitHub の issue にすることにしました。issue にしたことで、週 3 回の「プランニング・交通整理」のミーティングで確認することができるようになり、進み具合や、進めるのに障害になっていることを以前より早く把握できるようになりました。

GitHub Project に「🧵Talking」というレーンを作りました。このレーンには、話し合いが中心となる issue を入れておくことにしました。

このレーンにある issue を Designer Team Discussion の月曜日に話しています。月曜日は、全員揃う日であること、週の始まりで週の予定を調整しやすいことが理由です。

現在は、この方法で少しづつですが、確実に「カイゼン」を進められています。

おわりに

自分たちのやり方に、より良い方法がないか Monthly Update というふりかえりから、気づいて別な方法に切り替えていくことができました。

ふりかえりから、自分たちのやり方を定期的に見直して「食べチョク」の改善を進めていきます。

RubyKaigi参加者向け飲食店情報

ようこそ！松本へ！

こんにちは！ビビッドガーデンの美味しいものハンター兼エンジニアのy-hakutakuです。 弊社は今週5月11日〜13日にかけて開催される RubyKaigi 2023 で ローカルフードスポンサー として協賛しています。 オフライン会場ではブース出展をしており、地元生産者さんの食材やプレゼントありのクイズ企画を実施していますのでぜひお立ち寄りください！

せっかく松本まできたし、美味いものを食べたい

今年は外のランチ推奨とオーガナイザーの松田さんもおっしゃっていたので、お店の情報はあればあるほど助かると思い、安曇野にルーツがあるy-hakutakuが紹介していきます！

そば

榑木野

昔からの有名店。松本駅側にもあるので、あずさに乗る前にいかがでしょうか。 https://www.kurekino.co.jp/tenpo/ekisha/

みよ田

松本、上高地周辺の郷土料理に「とうじそば」を提供しているお店。ご当地グルメハンターにおすすめです！ https://www.ohtaki-gp.jp/brand/brand14/

ワインバー

peg

学生時代の先輩のおすすめのお店。ワインで酔いたい方はこちらへ🍷 https://tabelog.com/nagano/A2002/A200201/20020569/

居酒屋

山女や

地酒を飲みながら、串はいかがでしょうか。南信地方の「ザザムシ」や「蜂の子」などもあります🐛 https://tabelog.com/nagano/A2002/A200201/20000078/

松本つなぐ横丁

複数の店舗が併設されているタイプ施設。色々楽しみたい方はいかがでしょうか。 STORESさん主催のアフターパーティの会場でもあります。 https://hey.connpass.com/event/277763/ https://matsumoto-yokocho.jp/

大衆食堂

たけしや（焼きそば）　

焼きそば通にも一目置かれる名店です。わざわざここに来るために松本に来る焼きそばマニアもいらっしゃるそうです。 https://tabelog.com/nagano/A2002/A200201/20001590/

白雪（食堂）

松本周辺って普通サイズが大盛りということも。今はそういうお店もだいぶ減っていますがこちらは現役です！ ガッツリいきたい方はぜひ！ https://tabelog.com/nagano/A2002/A200201/20005440/

せいこうえん (中華料理店)

駅地下の昔ながらの中華料理店です。飲んだ後の〆にもお食事にもいかがでしょうか！ https://tabelog.com/nagano/A2002/A200201/20011076/

焼き鳥

鳥心

「焼き鳥を食べるならここ！」と学生時代の先輩に教えてもらったお店です。 https://tabelog.com/nagano/A2002/A200201/20003244/

洋食

どんぐり

シルバーが金属バケツで置かれ、一緒に入っているどんぐり通信を読みながら注文を待ちます。 メニューの名前にはマスターのご家族の名前が冠されたものもあり、あたたかさを感じるお店です。 https://tabelog.com/nagano/A2002/A200201/20000428/

カレー

メーヤウ

カレーの名店。ここのカレーを食べに松本まで来たこともありました。辛味が苦手な方は非推奨です。 また、会場からは少し離れているので、向かう方はタクシーで。満席の時は近くの桐店へGO！ https://www.facebook.com/maeyaomatsumoto

ラーメン

おおぼし

こってりとあっさりのラーメンのある名店。ばりこてが個人的にはおすすめです！ https://tabelog.com/nagano/A2002/A200201/20025262/

うなぎ

山勢

うなぎのみのお店、地元の工場などで繁忙期に差し入れとして利用されたりもします！ https://tabelog.com/nagano/A2002/A200201/20021045/

焼肉

明月館

松本の焼き肉の名店。地元民に愛される名店です。私もいきたい！ https://tabelog.com/nagano/A2002/A200201/20003701/

和食

蔵

ちょっと高価格帯ですが、和食や郷土料理をじっくり味わいたい方へいかがでしょうか。 https://www.matsumotokura.com/

ビストロ

オー・クリヨー・ド・ヴァン

個人的名物はステーキとフライドポテト。パリのビストロ感を強く感じるのは外のラタンチェアからかも。 https://crieur-japon.com/menu/

スイーツ

マサムラ

シュークリーム。懐かしい感じ。地元民なら知っている名店。会場近くにあるので糖分の補給にどうぞ。 https://tabelog.com/nagano/A2002/A200201/20000074/

喫茶店

珈琲美学 アベ

全国区になった純喫茶。サイフォンコーヒーやパフェが有名。電車待ちにいかがでしょうか。 https://tabelog.com/nagano/A2002/A200201/20001420/

お土産

開運堂

祖父母は必ずここでお土産を買っていました。 https://www.kaiundo.co.jp/shop 「これはうまい」という商品名のくるみ饅頭がオススメです。 https://www.kaiundo.co.jp/products/detail/2510

竹風堂

北信地域の和菓子屋さん。有名なお布施の栗を使った商品が有名です。 栗鹿の子や栗羊羹など、マストバイだと思います。 https://chikufudo.com/shop/491/

以上、ざっと紹介いたしました。 マップも合わせて公開します。

また、松本駅周辺の飲食エリアの大体のイメージも載せます。

会場周辺地図

まとめ 松本駅周辺は飲食店が密集しており、夜の散策もきっと参加者同士の交流においても楽しい場所かと思います。 RubyKaigi 2023、ご参加の方はぜひ松本グルメをご堪能ください。

私も初日だけですがブースでスタッフとしておりますので、是非お話しさせてください。 松本名物のお話や、食べチョクの美味しい商品などもご紹介できるかと思います。

それでは会場でお待ちしております！

FigmaとSCSSで色の定義を合わせるための運用方法

デザイン

こんにちは、松久です。

食べチョクでは、デザインツールとして Figma を使っています。色の定義を Figma の Color Styles で管理しています。 管理はしているものの SCSS には反映できていない状態でした。このままだと何が管理されている色なのかエンジニアとデザイナーの認識が揃わなくなります。そこで、Figma の Color Styles と、SCSS で用意した色の変数を合わせられる状態を作っていくことにしました。

色を定義するまで

1 年前ぐらいに UI の色の定義の再確認をして、一部曖昧なところは残りつつも SCSS の変数の定義をしました。 決まっていない部分があったままだったのですが、最近、未確定部分も定義して運用されはじめました。

SCSS の色の変数をまとめる

当初、variable.scss ファイルに色の定義だけではなく、いろいろな変数がまとまっていました。 今後、@use を使うことを想定して、役割ごとのファイルに分割しておくことにしました。また、Stylelint などで指摘するときも、どのファイルを確認すると良いか伝えやすくなることを配慮しました。

Stylelint で色の指摘をする

定義済みの色を直接指定しようとした場合は、Stylelint のプラグインを作って指摘することにしました。 定義済みの SCSS を json にすることも検討しましたが、追加や変更することは多くないので、そのまま書きました。

const stylelint = require("stylelint");
const ruleName = "tabechoku/use-ui-color";
const messages = stylelint.utils.ruleMessages(ruleName, {
  reject: (color, definedColor) =>
    `${color} は ${definedColor} が定義済みです。定義されているSCSS変数を利用してください。`,
});
const meta = {};
const colors = {
  "#ffffff": "$color-gray0",
  "#fff": "$color-gray0",
};
const ruleFunction = (primary) => {
  return (root, result) => {
    const validOptions = stylelint.utils.validateOptions(result, ruleName, {
      actual: primary,
    });
    if (!validOptions) {
      return;
    }
    root.walkDecls((decl) => {
      const matched = decl.value.match(/#.*/);
      if (!matched) {
        return;
      }
      const definedColor = colors[decl.value.toLowerCase()];
      if (definedColor) {
        stylelint.utils.report({
          ruleName,
          result,
          message: messages.reject(decl.value, definedColor),
          node: decl,
        });
      }
    });
  };
};
ruleFunction.ruleName = ruleName;
ruleFunction.messages = messages;
ruleFunction.meta = meta;
module.exports = stylelint.createPlugin(ruleName, ruleFunction);

指摘されるのがうっとうしい

Figma の Inspect に表示されるのをコピペすることが多く、Stylelint に指摘されるのはうっとうしく感じそうです。

「/ Primary/$primary2 /」から$primary2が使われていることがわかる

Figma の Inspect では Color Style が使われているところには定義名が表示されるので、SCSS の定義名と合わせて気付けるようにしています。 理想は、Zeplin のように Inspect に変数名で表示されることですが、できないのが残念です。あとは、Prettier にフォーマットしてもらう方法もあるのですが未着手です。

おわりに

Figma の Color Style で定義した色を運用するために、Stylelint で指摘することにした話でした。まだ問題はありますが、いろいろな色が実装されることは減らすことができました。

個々のデザイナーの力をより発揮しやすくする取り組みをすることで「食べチョク」の改善に向き合っていきます。

今年もやります!! RubyKaigi 2023の"Local Food Sponsor"。長野の絶品食材をご堪能あれ

こんにちは。プロダクト開発チームの Engineering Manager 兼 人事の @hirashun です。

今年もビビッドガーデンはRubyKaigiに"Local Food Sponsor"として協賛します。Rubyコミュニティと長野の地に感謝を込めて、地元長野の絶品食材をお届けします！

産直通販サイト「食べチョク」が「RubyKaigi 2023」にLocal Food Sponserとして協賛。当日収穫した新鮮なりんごなど長野県のこだわり食材を会場で配布。｜(株)ビビッドガーデン／食べチョクのプレスリリース

昨年に続き、やっていきます！

利用率No.1の産直通販サイト「食べチョク」を開発/運用するビビッドガーデンではリリース当初からバックエンドをすべてRubyで開発しており、ユーザーに迅速なサービス提供ができる恩恵を最大限にあずかっています。

昨年スポンサーとしてRubyKaigiに初参加しコミュニティの熱の高さととそこに薪をくべ続ける価値を再認識しました。ビビッドガーデンとしても引き続きRubyとそれを支えるコミュニティに貢献し続けたいと考えています。

そしてRubyKaigiは開催される都市自体を楽しむお祭りでもあります。その土地の魅力を伝えることも大事なポイントです。

昨年は想像以上に反響があり、多くのRubyistに三重の魅力とおいしさをお届け出来たという実感がありました。 感想を教えてくれた皆さん、お話させていただいた皆さん、本当にありがとうございました！

ビビッドガーデンとしては活動の継続に踏み切りました。やっていく！

より多くの人に楽しんでもらいたい

オフライン参加の方だけでなく、オンライン参加の方にも楽しんでいただけるように、以下の2つのスポンサー内容を準備しました。

  • 日替わりで長野の食材を会場にて配布
  • 長野の特産品を抽選で毎日5名の方にプレゼント

それぞれ説明していきます！

日替わりで長野の食材を配布します

昨年は大変多くの方に楽しんでいただきました！

が、反省として「初回の休憩ですべて配りきってしまう」「秒で売り切れる」というのがありました。 なので今年は1.5倍です。より多くの皆さんに届けたいと思います！

Day1「幻の林檎」ピンクレディ®︎とフリーズドライセット

シャンパンのような食味、重厚感のある食感。
懐かしさと新しさのハイブリッド。
ぜひお召し上がりください。

安曇野ファミリー農産へのレビュー・商品：長野県｜食べチョク｜産地直送(産直)お取り寄せ通販 - 農家・漁師から旬の食材を直送

Day2「食べる宝石」有機ドライほおずき

見た目もかわいく、ビタミンＡ、ビタミンＣやビタミンＢ群のイノシトール、カロテン、鉄分などが含まれ、
いわゆる「スーパーフード」と呼ばれて注目されています。
見ても良し、食べても美味しいほおずきはきっと皆さまをとりこにするでしょう。

百笑農房へのレビュー・商品：長野県｜食べチョク｜産地直送(産直)お取り寄せ通販 - 農家・漁師から旬の食材を直送

Day3「最終日にうれしい」たっぷり野菜が溶け込んだ玄米入り無添加スープ

種をまいて畑で実った野菜を丸ごといただく感覚を味わってほしいと思います。
食欲がないときや風邪気味のときにもおすすめです！

のらくら農場へのレビュー・商品：長野県｜食べチョク｜産地直送(産直)お取り寄せ通販 - 農家・漁師から旬の食材を直送

是非毎日お越しください！ブースで待ってます。

長野の特産品を抽選で毎日5名の方にプレゼント

その場ではお渡しが難しいけどこれだけは味わってほしいという長野の逸品をいずれか1品プレゼントします。 オンラインの方にもお届けできればと思い、Twitterで応募、その後当選された方に食べチョクを通じて生産者さんより直接発送します！

一例を載せますが・・・

トロリとろける信州サーモン
ナガノパープル＆シャインマスカットの宝石箱
信州白馬豚燻製詰め合わせ

欲しい。

こちらは3日間、毎日当たります！ぜひご応募いただければと思います。

応募方法は「食べチョク開発部アカウントのフォロー」と「会期中に #rubykaigi と #食べチョク を付けてツイート」です。

twitter.com

RubyKaigiの感想、欲しい食材等、思い思いのつぶやきをお待ちしております。
※当選された方には食べチョク開発部アカウントよりDMをお送りさせていただきます
※対象者はRubyKaigiに参加している方とさせていただきます
※本当に当たります！届きます！

おわりに

RubyKaigiが終わった後も、長野の生産者の方々が作ったこだわり食材に思いを馳せていただけると幸甚です。
気になった方がいましたら是非こちらを覗いていってください。
https://www.tabechoku.com/areas/nagano

ビビッドガーデンは「生産者のこだわりが正当に評価される世界へ」というビジョンのもと、一次産業の課題解決を推し進める会社です。
引き続きRubyをはじめとした技術を活用しながら、日本中の生産者の方々のこだわりがより多くの人に伝わるように、プロダクトを改善し続けようと思います。

ビビッドガーデンのことが気になりましたらこちらも是非ご覧くださいませ！
https://note.com/vividgarden_corp/

それでは皆様、当日スポンサーブースもしくはTwitterにてお会いしましょう！

バナー作成をデザイナー以外でも作成する運用をはじめました

デザイン

こんにちは。松久です。

キャンペーン、ニュースリリース、LINE など様々な場面で使われる画像は、デザイナーのみが制作していました。デザイナーだけで制作するには限界があり、作成の一部をデザイナー以外でできるようにする取り組みを行っているお話です。

画像を作成することが増えてきた

いろいろな施策が実施される体制になり画像の作成数が増えてきました。 急ぎの画像作成も増加し、一ヶ月間で UI 以外のデザイナーの取り組みの半分が画像作成になっていることもあります。 種類、目的が複数種あり、以下のような画像を作成しています。

  • サイトトップのバナー
  • ニュースリリースの画像
  • LINE のリッチメッセージ
  • LINE のリッチメニュー
  • 各種広告
  • メルマガ

キャンペーンとなれば、これらの画像の作成が必要となります。 キャンペーンではなくても、普段の運用でも必要となる時があり、デザイナーでは作成しきれない量が発生している状態です。

発生した問題

デザイナーだけでは作成しきれないため、いくつかの問題が発生しました。

  • 開始したいタイミングに間に合わない
  • 制作期限がはっきりしているので他の施策よりも優先順位が上がり、プロダクトについての施策の優先順位が下がる

そこで、マーケティング担当の方や、いくつかの部署の方に画像を作ってもらうことにしました。問題の一部は解決しましたが、新しい問題が出てきました。

  • 様々な人が様々なツールで作成しているため共通した色などの管理が困難
  • いろいろな「食べチョクらしさ」が発生する
  • デザイナーに画像制作に関する質問や、確認依頼がくるが、急ぎの話になる（確認しきれない・作ったほうが早い）

これらの問題解決のため、デザイナーチームであらかじめ Figma でテンプレートを作り、テキストや画像の差し替えを各担当者にしてもらう体制に移行をはじめました。

Figma でテンプレートを用意した

最初から、全種類の画像のテンプレートを作ることは難しいので、定型があるところから作り始めました。

ツールは Figma にしました。

  • 担当者に edit 権限があったこと
  • デザイナー側で共有している色のライブラリーなどがそのまま使えること

今回は、Figma の edit 権限を持っている人がマーケティングチームにいたので、そこから今回は始めることにしました。 Figma から始めることで、デザイナーがすでに共有している色のライブラリーなども使うことができ、試すための敷居は低めでした。

テンプレートを用意して、担当者に説明をして調整をして運用に進んでいます。

Figmaで用意したテンプレート

おわりに

問題が 0 になったわけではなく、Figma について知ってもらう必要や、edit 権限を持つ人を増やす取り組みも必要そうです。運用していくなかで見つかる問題にも対応を続けていく予定です。

今後もいろいろな取り組みで、個々のデザイナーの力をより発揮できる組織になり「食べチョク」の改善に向き合っていきます。

Figma の操作を方法学んでデザインデーターができるまでの過程を知る

デザイン

こんにちは、松久です。

食べチョクでは Figma をデザインツールとして使っています。デザイナーが作った Figma のデザインデータを見てエンジニアはHTML/CSS を書いています。このとき、わかりにくいデザインデータを見かけるときがあります。解決の糸口をみつけるために、Figma の使い方を知ろうと取り組んでみた話です。

何から始めるかを決める

新しい技術を学ぶ時は、チュートリアルがあればチュートリアルから始めるのを基本にしています。 Figma のチュートリアルとして、公式のYouTube動画を今回は使いました。このYouTube動画だけでチュートリアルとしては十分な量があります。全部はできませんでしたが、必要に応じて学ぶことができそうです。

Tutorials: Explore design features in Figma - YouTube

私はここから始めて一通りの操作を学ぶことができました。

www.youtube.com

Figma のようなソフトウェアは、動画で操作しているところを見ることができるため理解がしやすいです。公式の動画なので、Figma が想定している使い方の基本を知ることができるのも安心です。 動画は、英語なのですが、YouTube には自動翻訳機能があるので英語が苦手でも、日本語訳を表示させながら学ぶことができました。

残念なのは、全体像の説明がないので全体のどれぐらいを学んでいるのかはわかりません。学びたいことは、なんとなく思い浮かんでいたのですが、全体像の説明があると、後どれぐらい時間が必要なのか想定ができるのでありがたいです。

UI のトレースをしてどうやってデザインデータを作るか試してみる

操作方法について学んだあとに、いくつかのサイトの UI をトレースしてみました。 トレースの目的は、どんなことに気をつけて UI を作っているのか観察し、トレースすることで、デザインデータをどんなふうにすると良いのか感じ取ることを目的として行いました。

行ってみて、Figma の AutoLayout、コンポーネント、Variants が、マークアップではどんなふうに置き換えられるのか想像しながらデータを作ってみることができたのは大きな体験でした。

YouTube にあるチュートリアルでは、レイヤー名を常につけています。見ているときは「こまめに名前つけてるなあ」と見ていました。トレースをしてみると、名付けがあとになっている自分がいました。そして、あとからつけようとすると面倒くさい…。時々ある「Group 831」という数字のレイヤー名にとても納得しました。

実務のデザインデータを作る

トレースをしたあとに、実務でも UI のデザインデータを作ることになりました。自分が作ったデザインデータでエンジニアがマークアップをするのを見るのは新しい体験でした。

実際のUIデザインデータの一部

作ってみると、話し合いからデザインデータを作る流れで実装まで一通りのデザイナーの体験をしてみて、見えていなかった作業もわかりました。 例えば、モブデザインの後は、データの整理をしないと使いにくいデータ（例えば、レイヤー名から表示個所がわかりにくい、テキストのサイズが複数混ざっているなど）ができること。margin/padding についてデザイナーが理解していないとデザインデータとして表現できないこと（例えば、レイヤー同士の距離で margin を表現することと AutoLayout で padding を表現すること）を感じました。

おわりに

デザインデータはどうやってできるのか、実務で使ってみることで頭の中で知っていたこと以上のことを感じることができました。情報として知るのではなく、上手くいえないですが、実感のある情報となりました。

今後もいろいろな取り組みで、個々のデザイナーの力をより発揮できる組織になり「食べチョク」の改善に向き合っていきます。

ペアデザインとモブデザインを行いデザインデータを作る

こんにちは。松久です。

デザインデータを作るとき、デザイナーが一人で作業をすることもありますが、複数のデザイナーや、デザイナー以外の職能の人と一緒に取り組む事も少しづつ増えています。 現在、どのようにデザインデータを作っているのかを紹介します。

デザインデータができるまで

食べチョクで、デザインデータができるまでの大まかな行程は下記の通りです。

  1. 施策の目的を整理する。資料を集める。
  2. 施策の目的にそったデザインの初稿を作る
  3. 関係者で見ながら作って確認する（ モブデザイン・ペアデザイン ）
  4. デザイナー同士で確認・検討をする（デザインレビュー）
  5. 関係者で合意する（ デザインが確定 ）

今回は 3〜4 の工程で取り組んでいることを紹介していきます。

UI のためのデザインデータは認識合わせのためのドキュメント

デザイナーが作っている「デザインデータ」の役割は、バナーなどのグラフィックとUIでは異なります。 バナーなどではデザインデータは完成品となりますが、UI を作るときのデザインデータは、プロダクトを作るための中間成果物で、意図を伝えるドキュメントです。 デザインデータを使い、プロダクトマネージャーと成果物（= プロダクト）について共通の認識を持つために使います。エンジニアとは、HTML や CSS などを作るための設計図のような役割（ 1px を正確に表した図面ではなく意図を伝えるための図）で、認識を合わせるために用意しています。

職能を制限せず複数人でデザインをするモブデザイン

デザインデータを作るとき、エンジニア、プロダクトマネージャなど複数人で Figma を見ながらデザインすることを少しづつ増やしています。

GitHub の issue でデザインデータを依頼者に連絡しても意見交換で数日経ってしまうことがあります。複数人集まって見ながらデザインする方法であれば、何ができるのか伝わり、納得感を関係者で持つことができ、複数視点で確認できるようになります。 デメリットは、複数人の時間をいっぺんに使うのでコスト面とスケジュール調整が必要なことです。

進めるコツは、デザイナーは話しながらデザインをして黙って作業をしないことです。話を聞いて受け身で作業だけをするのが目的ではないからです。 もう1つのコツは、1時間を目安に終わらせること。話を聞きつつ、Figma を操作して画面を作るのは頭と手を同時に動かすので疲労が大きいです。話している方も目の前でできていくので白熱しやすく疲れてきます。ファシリテーションと Figma の操作は別な人がする方のが良い可能性もありますが、デザイナーの理解としては話しながら Figma で作るのが良いと感じています。

デザイナー同士複数人でデザインする

デザイナーは毎日「Designer Team Discussion」というミーティングをしています。ここで取り組んでいるデザインについて相談したり、一緒に作ることがあります。 目的を達成するためのデザインになっているか、他の人へ説明する機会になっていることが、一番大きいメリットです。あと、他の人の Figma の操作方法を見ることができるのもいい点です。

デザインレビューをする

UI については、「Designer Team Discussion」で確認して終わりになることも多いのですが、バナーなどはデザインレビューを必須にしています。 Slack に専用のチャンネルがあり、Workflow から依頼できます。デザイナー全員にメンションされますが、レビューはレビューワーを指定してレビューすることが多いです。

Slackのワークフローを利用したデザインレビュー依頼

デザインレビューの本もありノウハウが増えてきていますが、デザイナー以外がするのはまだ未挑戦です。今はデザイナー2人、もしくは、3人以上ですることが多いです。

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

Amazon

おわりに

デザイナーだけでデザインを行うのは難しいと感じています。 取り組む業務の知識、どんな表現が技術的に可能なのか、ビジネスとして取り組む事のバランスの落とし所を探すために、デザイナー以外を巻き込んでデザインに取り組むことが大切になってきていると感じています。

今は、Figma などのツールを土台にデザインについてのコミュニケーションを促進させていくことで、プロダクトをより良い状態にリードすることを、デザイナーに求めている状況になってきました。 今後もこのような取り組みで、組織でデザインを行えるようになり「食べチョク」の改善に向き合っていきます。