本当に実践的なデザインドキュメントの書き方 第1回：なぜ渡されたワイヤーフレームは分かりにくいのか？ | アドビUX道場 #UXDojo
本当に実践的なデザインドキュメントの書き方 第1回：なぜ渡されたワイヤーフレームは分かりにくいのか？ | アドビUX道場 #UXDojo 連載 本当に実践的なデザインドキュメントの書き方 いきなり渡されたワイヤーフレームをデザインするよう言われて戸惑った経験は、デザイナーなら誰でもあるのではないでしょうか？これはディレクターとデザイナーの分業という状況に起因する問題ですが、分業が一般的なのにはもちろん理由があります。そこで、この連載では、現在の分業体制を前提に、情報設計に関わる『デザインドキュメント』をきちんと制作することで、この問題を解決する手段を探ります。 第1回は、受託のWeb制作における一般的な分業体制を詳細に分析し、よりデザイナーが貢献できる役割分担について考えていきます。 なかなかはじめられないUXデザイン これはGoogleトレンドで、「Webディレクター」「Webデザイナー
「Ameba」アイコン刷新 一貫性と再現性追求のための設計術 | CyberAgent Developers Blog
GUIにおけるアイコンとは、プロダクトを触れるユーザーに対して、機能や動作を抽象化してシンプルかつ直感的に伝達させる、文字情報に頼らない記号です。 基本的に、記号が内包する意味には受け手によって解釈の余地があるような状態であってはなりません。しかし、ユーザーに対して、シンプルに正しい意味を伝えることが出来るという前提さえ踏まえれば、それを成すスタイリングは作り手やプロダクトによって様々な表現が可能な余地が残されています。 つまり、アイコンは、記号としての機能性に加えて、装飾としての役割も抱く、プロダクトGUIにおけるスタイリング定義の標本となり得るということです。 前段 「Ameba」について 「Amebaらしい」アイコンとは何か 塗りと線のルール 「Amebaらしい」形状 「Ameba Sans」の形状分析と曲率定義 線の太さのルール 命名規則を決める Library化 リプレイス まと
Sassのモジュールシステムを@importから@useに移行する方法を考えてみた
先日、KOJIKA17さんの「Sassを@importから@useに置き換えるための手引き 」という記事を見て、2022年10月ころにはSassで@importが使えなくなる可能性があることを知りました。まだ2年ありますが、新しく取り組むプロジェクトでは@useを使ったモジュールシステムにしたいので、自分が使っている構成の置き換えについて考えてみました。 まずはアイディアをシェアをして叩き台にしてもらうのが目的ですが、他に良い書き方があったらぜひアドバイスいただきたいというのもあります。 試しながら、考えながら書いているので内容は変更される可能性が高いかもしれません。 Sassの新モジュールシステムについて Sassの新しいモジュールシステムについては、上述の記事や SHIFTBRAINさんのブログ がわかりやすかったです。ありがとうございます。 公式の発表と@useと@forwardのド
『UX原論』の刊行
2018年の秋に企画を立て、その年の初冬から執筆を始めた『UX原論』が2020年1月にようやく脱稿し、2020年4月28日に販売されることになったので、この場をお借りして、少しPRさせていただきたい。 黒須教授 2020年4月27日 筆者の出版の個人史 筆者は、これまで、ユーザビリティやUXに関連するまとまった書籍として、 黒須正明、伊東昌子、時津倫子 （1999） 『ユーザ工学入門―使い勝手を考える・ISO13407への具体的アプローチ―』、共立出版 ユーザビリティハンドブック編集委員会 （2007） 「ユーザビリティハンドブック」、共立出版 黒須正明 （2013） 『人間中心設計の基礎』、HCD ライブラリー第 1 巻、近代科学社 Kurosu, M. (2016) “Theory of User Engineering”, CRC Press を出してきたので、まずそれについて説明し
CSS設計・Sassディレクトリ管理の標準化（CROCSS） - Qiita
はじめに HTML+CSSコーディングにおいて、Sass管理ディレクトリを標準化する方法を紹介します。 CSS設計は、サイト種別やプロジェクト規模、分業の有無や人数によっても最適解が異なります。 この仕組みは、様々な設計を同じロジックで受け入れることによって、CSSコードの管理効率を画一的に最大化する狙いのものです。 コーポレート・ポータル・ブログ・EC・LP・管理画面…など、様々な種別のサイトのCSSを、同じ仕組みで設計して管理できるようになります。 前提事項など SassなどのCSSプリプロセッサの使用を前提とします。 本記事の一部は、後で見られるよう別記事として切り出しています。（📝のマークのもの） この記事は標準化ノウハウ公開の一環として書いています。 仕組みの概要や前提事項などについては「UltimateCoding 概要・前提事項」のエントリをご確認ください。 セクション一覧
1段上のCSS設計・コーディングの概念図（HCDCモデル図） - Qiita
はじめに HTML＋CSSコーディングにおいて、「どのように要素を特定してスタイリングするのか」というCSS設計上の課題に対し、「ひとつ上の視点で思考できる概念図」を紹介します。 この図を用いることで、3種類の異なるスタイリングアプローチ（OOCSS方式 / 包括要素基点方式 / BEM方式）の本質を一度に俯瞰できるため、全てを同じ枠の中で捉えられます。そして、最終的には種別や規模の異なるサイトやプロジェクトに対し、同じメソッドを使ってそれぞれ最適な設計がおこなえるようになります。 ※この記事は標準化ノウハウ公開の一環として書いています。 仕組みの概要や前提事項などについては「UltimateCoding 概要・前提事項」のエントリをご確認ください。 経緯 / 制作者中心のデータ分類 そもそもですが、HTMLとCSSは目的も仕様も異なる言語です。 HTML+CSSコーディングを一般的な視点
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
