蟹@UIデザイン|現実主義UX開発

理想と現実の間で頭を悩ませるデザイナーです。

蟹@UIデザイン|現実主義UX開発

理想と現実の間で頭を悩ませるデザイナーです。

    マガジン

    • 「UXデザインにおける5段階モデル」を現実的なタスクにする

      言うは易く、行うは難し。UX関連の情報は崇高な理想を掲げている物が多い印象で、限られたリソースの中で、自分たちが直近何をすべきなのか悩んでしまいます。 そこで、このシリーズでは「現実主義UX開発」と題し、実際にどんな事をすれば良いのか考え、実行した結果を記録します。

    • 実録|UIデザイナーから見る組織デザイン

    • デザイナーの思考回路 - 解説を試みる

    最近の記事

    #7 段階の運用|進行・合意形成・チームデザイン

    シリーズの続き。#1 記事↓ 前回は骨格段階までやった。表層段階はデザイナーに任されることがほとんどなので、あえてここに文章化する必要もないだろう。 今回は、今まで見てきた「5段階モデル」をどう運用するのか、 チームに導入するべきか、その場合どう浸透させるのかを考えていく。 p.143〜 「段階の運用」の内容 戦略・要件・構造がカットされがちだが・・・ 目に見えない段階 コードや画像のような、実際のコンポーネントとして目に見えないので、「戦略」「要件」「構造」はカ

      • #6 骨格段階|構造段階ちゃんとできてる?

        シリーズの続き。#1 記事↓ 今回は骨格段階へ。 このワイヤーで進めてください!え?企画側がワイヤーを引いて、デザイナーに色付けをしてくれという依頼がたまに来る。そのワイヤーが適当であれば良いが、そうでないケースも少なくない。今回は、なぜ適当でないか言語化できるように文章にしていく。 レイアウトが上手くいかないのはなぜ?レイアウトを考える時に、パズルをするように要素を並べ替えていると、「どうしても上手く噛み合わない!」「スペースが足りない!」など、お手上げ状態になるケー

        • #5 構造段階|チケットに、要件に対して変な構造設計を書いて来よる

          シリーズの続き。#1 記事↓ 今回はいよいよ構造段階へ。 変なチケットたち弊社ではbacklogチケットで施策とそのリリースを管理している。デザインチームにも、チケットを通して依頼が来る。 よくある変なチケットとして、以下のようなものがある。 要件だけが書いてあり、何のための施策なのか分からない。 構造設計まで書いてあるが、要件と食い違っている。 表層段階の事が書いてあるが、何のためにやるのかが分からないし、表層まで考えてあるなら、デザイナーに依頼する必要ないよね

          • デザイナーとマーケターで1on1してみた

            自分はデザインチーム3名のリーダーと、その3名とフロントエンドエンジニアを含む9名のチームのマネージャーの代理的なポジションをしている。(マネージャーが週1稼動のため) そんな感じで、デザイン&フロントエンドのチームの開発体験を扱っているのだが、よく「この仕事角度高いのかな?やる意味あるのかな?」という話が出てくる。その不満を「まあまあ」となだめて済めば良いが、起案をしているマーケターのチームに若手が多く、不満だけでなく「心配」も出てくるので、つい余計な「おせっかい」をした

          マガジン

          マガジンをすべて見る すべて見る
          • 「UXデザインにおける5段階モデル」を現実的なタスクにする
            蟹@UIデザイン|現実主義UX開発
          • 実録|UIデザイナーから見る組織デザイン
            蟹@UIデザイン|現実主義UX開発
          • デザイナーの思考回路 - 解説を試みる
            蟹@UIデザイン|現実主義UX開発

          記事

          記事をすべて見る すべて見る

            最近、闇雲に施策やってない?

            UXについて考えていたら、組織の課題にぶつかった。 悩みは、施策の起案者(マーケター)が、KPIを追うのではなく、プロジェクトの完遂を目掛けて仕事をしているということ。 デザインチームは、マーケターと別の目線から施策を起案したいのに、根拠のない施策にリソースが割かれている可能性があるというのは納得感がない。 プロジェクトの完遂ではなく、成果やUX改善の成功測定基準を元にした内容にシフトしてもらいたいな〜と思った。 デザインチームのメンバーとマネージャーに相談週次でKPT

            #4 要件段階|なぜ仕様書が書かれない?合意形成が進まない?犯人は人事評価基準か?

            シリーズの続き。 #1 記事↓ 今回は「要件の切り分けをちゃんとする」の続き 結局、人事評価の問題にまで話が広がった。 仕様書が書かれなくなってしまう課題 自社で仕様書が用意されておらず、エンジニアが発狂することがある(発狂は言い過ぎかも)Figmaで引いたデザインにコメントで仕様を書き込んでいたが、要件が膨らみすぎて、コメントが100件を越えたあたりから悲鳴が上がった。 原因は本にもある通り、「実際の製品を反映していない」ことが原因にある。実装の過程で物事が変化す

            #3 要件段階|要求と要件の違い・リリースを分割できない原因は?

            シリーズの続き。 #1 記事↓ 今回は「要件の切り分けをちゃんとする」具体的な手法について学習し、具体的なタスクに落とし込みます。 なぜ、わざわざ要件を定義するのか?ゴールの明文化 プロジェクトメンバーの中で暗黙の了解になっていてはいけない。何のために作業をしているかをはっきりさせるべきだ。目的のために、あと何をやっていないのかを明確にするために。 具体的な要求を策定する 具体的な要求を制定し、それに合わないリクエストを今後のリリースの可能性としてストックする。

            #2 戦略段階|UXの成功測定基準を設定してなくない?あとユーザーテストって結局ナニ?

            前回の続き 今回は「戦略段階の整理を徹底する」具体的な手法について学習し、具体的なタスクに落とし込みます。 開発側の要求ゴールの明文化 ゴールが暗黙の了解になっていたら、チームで明文化して共通認識を持った方が良い -ビジネスゴール -製品目標 -ブランドアイデンティティ(概念的な関連性・感情の反応の集合体) -成功測定基準   -滞在時間(長く回遊して欲しいのか、速く処理を完了させたいのか) >自社でUXの理想論はよく語られているが、具体的な測定基準の設定が甘い気が

            #1「UXデザインにおける5段階モデル」を、現実的なタスクにする

            私は、インハウスでUIデザイナーとして働いている者です。自社でもUXを改善していこう!と言う話になっているので、急いで本を読んで勉強している所です。 ただ・・・書籍や記事を読んで「せやな!」となるのですが、言うは易く、行うは難し。UX関連の情報は崇高な理想を掲げている物が多い印象で、限られたリソースの中で、自分たちが直近何をすべきなのか悩んでしまいます。 そこで、このシリーズでは「現実主義UX開発」と題し、実際にどんな事をすれば良いのか考え、実行した結果を記録します。

            デザイナーの思考回路|どうして風呂敷を広げたがるの?

            デザイナーではない人に対して、デザイナーのミッションと思考回路の説明を試みるシリーズです。 デザイナーを話に入れると、すぐに風呂敷を広げたり「そもそも〜」と言って、話をひっくり返したがるケースがありますよね。なんで、そんな面倒臭い事をするのでしょうか? 質問を質問で返すデザイナーに、「〜できる?」「〜はどんな物が良いと思う?」と聞くと、質問で返されることはないですか? >>質問を質問で返すなあーっ!!<< なぜ、デザイナーはそんな事をするのでしょうか? 自動車メーカーの