【アジャイル開発＋UXデザイン】Lean UXをやってみて学んだ話｜長岡（野澤）紘子 Hiroko Nagaoka (Nozawa）
こんにちは。atama plusというAI×教育のスタートアップでUXリサーチャー/UXデザイナーをしています野澤です。 atama plusではプロダクトをアジャイルに開発しています。開発フレームワークとしてスクラムを採用していて、UXデザイナーもエンジニアやQAと１チームとなって開発を行っています（更に最近ではビジネスのメンバーもチームにジョインしてます）。 本記事では、atama plusのUXデザイナーがアジャイルにプロダクト開発を行うために大事にしている「Lean UX」という考え方と、私がそれを１年半実際にやってみて学んだこと、チームにLean UXやアジャイルの考え方を広げる方法を紹介します。 以下の人に向けて書きます! ・アジャイル開発に興味があるUXデザイナー・エンジニア・QA ・デザイナーとエンジニアとQAの壁に悩んでる人 ・組織にアジャイル・Lean UXを広めたいが
LCHは、UIにベストなカラースペース｜hirotoarakawa
Linearのリニューアル記事がすごく良かった。 A design reset (part I) How we redesigned the Linear UI (part Ⅱ) その記事の中で「LCHカラースペース」について書かれていた。知らなかったので調べてみると、以下の記事を見つけた。 この記事の内容を抜粋しながら、自分用に簡易なメモとしてまとめる。 LCHとは？LCHは簡単に言うと、異なる色相でも同じコントラストに見えるように構成されたカラースペース。 1976年に国際照明委員会 (International Commission on Illumination, CIE) によって最初に定義された色空間であるため、CIELAB とも呼ばれている。 LCH は、Lightness（明度）、Chroma（彩度）、Hue（色相）の略。 HSL と LCH の違いLightness（明度
「経営に入り込むデザインリーダー」とは何者か？どうやってなるのか？｜tsujiharasaki | ILY,inc
Hello, 辻原です。すごい久しぶりにnoteを書きます。 外部公開できないものの、23年はビジネス書1冊くらいの原稿を書いたので、年始の「今年は文章を書くぞ！」はクリアしたものと思っており発信系をサボりつつあったのは正直なところ自分への甘えです。 今年は弊社でクリエイティブキャピタルの取り組みをスタートしたこともあり、年の後半の辻原個人のテーマは「経営に参画するデザイナーに必要なスキルは？」「どんな振る舞が求められ・どんな役割を果たすべき？」という観点であり、こうした自己問答を繰り返していました。23年最後にできるだけ簡単に整理しておこうかなという気持ちでnoteを書いています。 もっと経営に貢献したいぜ〜という野心と向上心と利他心をお持ちのデザイナーさんのお役に立てると嬉しいです。 「経営に入り込めるデザインリーダー」って？この表現はgoodpatch土屋さんのnoteから引用してい
【UXエンジニアを目指すには？】クックパッドのUXエンジニアに聞いた、働き方や勉強法 - エンジニアtype | 転職type
2019.09.19 スキル スマートフォンの普及以降、Webページやアプリケーションのデザインが大きく進化してきた。同時に、快適なユーザー体験を支える（UX/User Experience）UXデザインの重要性も高まっている。そんな中、近年新しい職種として注目を集めているのが、デザイナーとエンジニアの領域を横断し、一貫してプロダクトに落とし込む「UXエンジニア」だ。 では、既存のエンジニアがUXエンジニアへのキャリアチェンジを目指そうと思った際、一体どんなことから始めたらいいのか。クックパッド株式会社でUXエンジニアとして働いている重田桂誓さんに話を伺った。 クックパッド株式会社 UXエンジニア 重田桂誓さん 高専卒業後、筑波大学大学院を修了。学生時代にGoogleMapsやTwitterのUIに衝撃を受け、デザインに強い関心を持つ。新卒でミクシィに入社後、デザイン領域により深く関わるた
Design for the web without Figma
By all accounts, Figma has been an amazing tool for designers. We've used it extensively at 37signals, and I'm sure most every other software shop has too. Adobe didn't pay $20 billion for nothing. But we don't do the bulk of our design work with or in Figma when developing Basecamp or HEY for the web. That's all done directly in HTML and CSS, as it should be. Because no matter how good Figma is,
UI Stackに基づいた状態変化に強いUIを作ろう！
HOME制作UI/UXUI Stackに基づいた状態変化に強いUIを作ろう！ UI Stackに基づいた状態変化に強いUIを作ろう！ こんな思いをしたことはありませんか？ 「ページの読み込みに時間がかかっているけど、画面が真っ白で読み込み中なのかエラーなのかわからない…」 「ブログの記事数が少なくて、ページとしては寂しい…」 「404ページがサイトのデザインと異なっていて、びっくりした…」 ユーザーに不安な気持ちを与えるページを作っていませんか？ ページの構成・デザインを考える時は「UI Stack」を基準に考えるとユーザビリティの高いページを作成できます。 UI Stackとは UI Stackとはアメリカのデザイナー Scott Hurffさんが提唱した、「UIの考慮すべき5つの状態」という考え方です。 出典：How to fix a bad user interface 5つの状態と
AtomicDesign 境界線のひき方
AtomicDesign はコンポーネント粒度の指標として共有し易く、多くのプロジェクトで採用されています。しかしながら、その設計概念が先立ってしまい、いくらかの課題を抱えている場合があります。 1.影響範囲が特定しにくい 2.依存関係が特定しにくい 3.汎用性が低くなりがち 4.汎用性の高低が判別できない 多くの場合「粒度」だけを基準にしてしまい、横断的コンテキストに「早期区分」 してしまっていることが直接的原因です。 「関心範囲の広さ」区分 アプリケーションを構成するモジュールは「関心範囲の広さ」で区分を行うことが鉄則です。次の２つのhelper.tsを見てください。全く同じ関数が定義されていたとしても、どこで利用される想定のものなのか、すぐに判別できますね。utilsは、プロジェクト内で横断的に再利用される可能性が高い（関心範囲が広い）ものが集約されます。 AtomicDesign
設計の考え方とやり方
#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計のためのモデリング
Tao of React - Software Design, Architecture & Best Practices
Tao of React - Software Design, Architecture & Best PracticesJanuary 18, 2021 • 25 minute read I’ve been working with React since 2016 and still there isn’t a single best practice when it comes to application structure and design. While there are best practices on the micro level, most teams build their own “thing” when it comes to architecture. Of course, there isn’t a universal best practice tha
営業日などの規則性と例外を扱うための設計
解決したい問題 例として、飲食店の予約サービスを考える。 予約を受け付けるためには各店舗の営業スケジュールを管理しておいて、営業日の営業時間内のみ予約を受け付けるようにする必要がある。 たとえば、ある店舗は各曜日の営業時間について、以下のように定めているとする。 平日：11:30-22:00 土曜日：11:00-22:00 日曜日：11:00-21:00 定休日：木曜日 これを素朴に設計すると、たとえば以下のような「営業日については営業時間を保持し、定休日についてはレコードがない」というテーブルになるかもしれない。 店舗 曜日 開店時刻 閉店時刻
フロントエンドエンジニアが変える現場のモデリング意識/modeling-awareness-changed-by-front-end-engineers
フロントエンドエンジニアが変える現場のモデリング意識/modeling-awareness-changed-by-front-end-engineers
CSSとコンポーネント設計に対する考察 - uhyo/blog
近年のフロントエンド開発にはコンポーネントという概念が付いて回ります。React・Vue・AngularといったViewライブラリでは、コンポーネントを定義してそれを組み合わせてアプリを作ります。また、いわゆるWeb Componentsとして知られる仕様群により、ライブラリに依存せずに“コンポーネント”を作ることもできるようになってきています。 コンポーネントは、何らかの機能（あるいは責務）を持った部品です。また、コンポーネントによっては再利用される（アプリ内の複数の箇所から利用される）ことを意図しているものや、そもそもライブラリとして配布されているようなものもあります。アプリの機能の一部分を抜き出したものという見方をすれば、コンポーネントというのは関数にとても類似した概念であることが分かります。 コンポーネント設計によって、言い換えればアプリがどのような機能を持ったコンポーネントたちに
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
データベース設計におけるNULL - kawasima
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Refactoring UI
Backlog UI リニューアルの舞台裏 / Backlog Renewal UI
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Don't overabstract your components
Prefer Declarative State Updaters | Kyle Shevlin
How Storybook helps designers & developers stay in sync
