#デザイン
デザイナーが素早く戦力になるために心がけているキャッチアップとアウトプット
こんにちは、フリーランスプロダクトデザイナー@ShikiCheriです。今回は参画したプロジェクトの制作事例を紹介しつつ学んだこと、自分が心がけているキャッチアップとアウトプットのコツについてまとめました🎉
インプットフェーズとアウトプットフェーズで心がけたい"誤解を作らない仕組み"そんな状況下、短期間で着実に事業を前進させるために2つのフェーズで意識していることがあります。
参画直前：
こ
デザインレビューのガイドラインを作りました -レビューフロー編-
こんにちは。hacomonoのプロダクトデザイナーのかんちゃんです。
組織に所属しているデザイナーの方であれば、レビューのガイドラインが欲しいと思った経験はありませんか？
この記事は発足して2年弱のデザイン組織でデザインレビューのガイドラインを作成した経緯の記録の第3弾「レビューフロー編」です💡
中小規模のデザインチームでレビューに課題を感じている方々の参考になればと思い、「心得編」「レビュー
「便利さ」ではなく、「豊かさ」を生み出すデザインをしたい
この記事は🎄MIMIGURI Advent Calendar 2023の19日目の記事🎄です。
前回は田幡さんのWHYからは始まらない！？ WHEREから始める探究論でした。
noteの執筆頻度が実質年に1本になっているとのことですが、そのエネルギーが存分に込められた壮大な内容で、このまま本にできるのではないかと思うくらい濃密な内容でした。ぜひ読んでみてくださいね！
他の記事はこちらのマガ
実務のためのマイクロインタラクション入門 @ Friends of Figma Shonan
2023.11.29にFriends of Figma Shonanで発表した内容を紹介します。当日使用したスライドは以下から確認いただけます。
はじめに今回のテーマは「実務のためのマイクロインタラクション」です。
オライリーから出版されている『マイクロインタラクション』では以下のように説明されています。
最小単位のインタラクション
「愛される製品」と「許容範囲の製品」の違いを生む
トリ
デザインと開発の分断を乗り越え、チームでアウトカム検証を回すプロセス
リーン開発の課題、Sense→Discovery→Deliveryのプロセス分断をどう乗り越えるかリーン的なアウトカム検証には、不確実性が高い段階から「Sense（課題発見）」「Discovery（ソリューション発見）」「Delivery（製品開発）」の3つの仮説検証トラックが存在すると考え、Gaudiyでもこれに近い運用を行なっています。
そして、リーンやアジャイル的な考え方では、これらはプロ
iOS構造設計の実践ガイド〜HIGは読んだけど、次に何をすればいい？〜
こんにちは！i3DESIGNデザイナーチームです。
今回は、iOSの構造設計についてお話しします。まず前提として、iOSにおける構造設計には、Apple独自の理念と原則をまとめたHuman Interface Guidline（通称HIG）の理解が重要になります。しかし、HIGを読んだだけでは、具体的なUI設計は難しいと感じる方も多いのではないでしょうか？
本記事では、HIGの理念を具体的なシ
デザイントークンの効果的な命名方法
サイボウズでkintoneのデザインシステム開発をしているトビ（@0b1tk）です。こんにちは。
今回はデザイントークン、特にセマンティックトークンの命名方法について掘り下げます。
まずはデザイントークンの定義について、W3Cから設立されたデザイントークンの仕様策定をするコミュニティ「Design Tokens Community Group」の定義を引用いたします。
このデザイントークンの名
「集合知」でチームとプロダクトが成長するデザインレビューを目指して｜SaaS Design Conference 2022
こんにちは！
Unipos株式会社プロダクトデザインTマネージャーのmyb(@myb_t_)です。
11月26日に開催されたSaaS Design Conference 2022に登壇させていただいた内容の書き起こしになります。
Unipos社のプロダクト開発部のアドベントカレンダー記事でもありますので、ぜひ他の記事もご覧ください！
📌 背景情報 -Uniposとは-💻 Uniposのサービ
『はじめよう！ 要件定義』（とそのシリーズ）を読んで、はじめよう！UIデザイン
繰り返し読んでいるマイ・フェイバリット技術書に『はじめよう！ 要件定義 ～ビギナーからベテランまで』とその姉妹本『はじめよう！ プロセス設計 ～要件定義のその前に』『はじめよう！ システム設計 ～要件定義のその後に』の、通称「はじめよう！シリーズ3部作」があります（羽生章洋さん著）。
『はじめよう！ 要件定義 ～ビギナーからベテランまで』はそのタイトル通り、ソフトウェア開発に携わるエンジニアや
主観と客観を切り替える鍛錬
突然ですが、ここに一つのプロダクトがあるとします。
そのプロダクトを見つめる視線には様々な種類があります。
そのプロダクトを利用しているユーザーの視点、利用していないが存在は知っているという人の視点、それをつくるデザイナーの視点、プロダクトを運営している会社経営者の視点…
もしあなたがデザイナーであれば、デザイナーの視点だけが唯一自分で体感できる「主観」で、それ以外はすべて「客観」となり
ユーザーテストガイドラインをバージョンアップ！～都庁で「サービスデザイン」を徹底するために～
すべての行政手続のデジタル化など、都政のDXの推進にあたり、私たちが目指すのは、単なるデジタル化ではなく、QOS（Quality of Service）の高い、すなわち、誰もが使いやすく、品質の高いデジタルサービスの提供です。
そうしたより良いサービスを創るには、利用者（ユーザー）中心でサービスを設計する「サービスデザイン」の取組を徹底することが大切です。
そのため都庁では、職員が遵守すべき共
最小公倍数のプロダクト戦略（FigJamフォーマット公開）
プロダクト戦略をたてる際に活用できるフレームワークはこの世に無数に存在します。
時代や業種やフェーズやプロダクトの性質に応じて最適なフォーマットが異なるため、どういったフォーマットを選びとって進めていくか迷う人も多いでしょう。
そこで、私がいままで数々の新規事業立ち上げとプロダクトグロースをおこなってきた経験から、プロダクト戦略をたてる際にほとんどの場合で使っているオレオレFigJamフォーマ
