大手ITスタイルガイドがベースGoogleやMicrosoftなど大手IT企業の英語スタイルガイドの基準がベース。一般的な英語表記から外れません。
コンテンツスタイルガイドとは、ブランドが公開するコンテンツの作成基準を、ライティングチームや同僚が理解できるようにするためのものです。特に、あなたの会社に複数のライターが在籍している場合、文法や表記ルール、文章のスタイルを定めておくことは、次の3つの点で役に立ちます。 1.ブランドの「らしさ」に一貫性が生まれる 表現や言い回しに調和が取れていると、コンテンツはより研ぎ澄まされ、読者に信頼感を与えることができます。それはウェブページ、ソーシャルメディア、ニュースレター、ブログ記事に限りません。アプリのユーザーインターフェースに表示するマイクロコピーを書く場合においても、スタイルガイドがあれば、プロダクトの個性や「らしさ」に一貫性を与えることができます。 2.ライティングの上での誤りを防げる 使ってはいけないスラング、避けるべき専門用語、または日付の正しい表記方法まで、スタイルガイドではっきり
生まれ変わったらデザインシステムになりたいと思っているくらい、デザインシステムが好きなエンジニアの乗田です。 僕の入社の経緯や業務内容についてはこちらからご覧いただけます! デザインシステムとは デザインシステムとは、ソフトウェアやグラフィックなどにおけるデザインの原則や指針と、それらを実現するための仕組みの集合体です。デザインシステムのメリットは、低コストで高速に一貫性のあるデザインを実現しやすくなるという点にあります。 一般的にデザイン原則にはタイポグラフィ・カラーシステムやボイス&トーンなどが含まれ、仕組みにはコードベースのUIコンポーネントやデザイントークンなどが含まれます。 しかしデザインシステムにおける必須要素の定義はありません。それ故にデザインシステムは、各組織にとって必要なデザイン原則やデザインアセットが集合した物と言い換えることもできるでしょう。 古い物ですと1975年に
This application is a living style guide or pattern library, generated from KSS documented styles...with an accessibility twist. No matter your level of development or accessibility expertise, there are ways to help contribute to the a11y style guide. Why did this project start? We wear a lot of hats as front-end developers. Depending on the client or company you work for, you may be the designer,
// Good: choose between two options as appropriate (see below). import * as ng from '@angular/core'; import {Foo} from './foo'; // Only when needed: default imports. import Button from 'Button'; // Sometimes needed to import libraries for their side effects: import 'jasmine'; import '@polymer/paper-button'; Import paths TypeScript code must use paths to import other TypeScript code. Paths may be r
この記事では、デザインシステムを作成するときの基本ガイドをまとめています。 この記事は3つのパートで構成されています。 デザインシステムを理解する(デザインシステムとは何か、いつ作るべきか?) デザインシステムの作成(作成プロセスとやっておきたい項目) デザインシステムの具体的なサンプル例(デザイナーとデベロッパー、それぞれの観点より) デザインシステム追加の検討事項(その他のコンセプトや参考文献など) *この記事では、Webサイトやアプリ、オンラインサービスなどを表す包括的な用語として、「プロダクト(Product)」という言葉を使用しています。 この記事のコンセプトをイラスト化するために作成した、デザインシステムを公開しています。ご自由にお使いください。 Basic Design System – Figmaファイル デザインシステムを理解しよう デザインシステムとは? デザインシステ
ここ数年で、「デザインシステム」はウェブ開発やデザインのコミュニティでとても人気の話題になりました。そして「コンポーネント」として定義される一連のデザイン成果物を開発・メンテナンスするために、StyleguidistやStorybookといったツールが多くのプロジェクトで一般的に使われています。このプロセスはデザインシステムという概念の一部として、コンポーネント駆動開発(Component Driven Development)と定義することができるでしょう。 さて、コンポーネント駆動開発にまつわる資料のほとんどは、ReactやVue、Angularといった、フロントエンドのビューのためのメジャーなライブラリを利用することについてのものです。しかしもっとトラディショナルな技術スタックの場合はどうすればいいでしょう? 例えば私たちスタンダードデザインユニットでは、静的なHTMLとCSSのアセ
ずっと自分好みのスタイルガイドジェネレーターを探していたんですが、ようやく見つけました!「Fractal 」というツールで、かなり良さそうなのでご紹介します。 初級編、中級編の2回に分けて、初級編ではインストールと初級設定からウェブUIの起動までを、中級編ではコンポーネントのより細かい設定などについてご紹介します。公式ドキュメントは初めてだとわかりづらいところもあったので、その辺を補う形でまとめてみたいと思います。 ※先日、スタイルガイドとパターンライブラリの違いについてまとめましたが、スタイルガイドやパターンライブラリを自動生成するツールは「スタイルガイドジェネレーター」というのが一般的なようです。「パターンライブラリジェネレーター」とは呼ばないみたいですね。 では早速、「Fractalのはじめの一歩」的な感じで行ってみましょう! Fractalとは まずは、ざっくりとFractalをご
みなさんは、JavaScriptのコードを書くときに文字列は何で囲みますか?シングルクォート?ダブルクォート? インデントに使用する文字はスペース?それともタブ? JavaScript Standard Styleは、そのように千差万別なコーディングスタイルを統一するためのスタイルガイドの一つです。1 JavaScript Standard Styleのルール JavaScript Standard Styleには、次のようなルールがあります。 インデントはスペース2個 文字列はシングルクォートで囲む 未使用の変数は禁止 文末のセミコロンは禁止 キーワードの後にスペースを入れる 関数名の後にスペースを入れる 値の比較に==ではなく===を使用 ただしobj == nullはnull || undefinedをチェックするために許容される 常にNode.jsのerr引数をハンドル ファイルの
We’re happy to announce Style Guide Guide, Gatsby Edition! You can check out the demo here. The workshop and the storefront There are lots of moving parts, tools, and environments involved in making a design systems take shape. We’ve found it helpful to break down two important environments of a design system into the “workshop” and the “storefront”. The “workshop” is the environment designed for
10年以上の歳月を経て、Atlassianのデザインは徐々に改良・洗練されていきました。そういった流れの中で、Atlassianは、2012年に最初の公式なデザインシステムを作成しました。当時の最優先の目的は、Atlassianのすべての製品で一貫性を確立することでした。最初の「デザインシステム」は、実際には従来的なスタイルガイドに近いものでした。 次の5年間で、Atlassianはデザインシステムの開発と調整を行い、有益な教訓を学びました。それは、デザインシステムは一貫性の維持だけにとどまらない効果があるということでした。2017年の最新バージョンでは、製品のインターフェイスからフリクションを減らすことに重点が置かれました。そして、デザインシステムを補完するUIライブラリー「Atlaskit」が追加され、デザインシステムの機能が定義されました。 Atlaskitでは、標準となるUIコンポ
デザイナーの仕事は、成果物に対するデザインだけではありません。デザイン制作をしたら、「なぜそのデザインなのか」をステークホルダーに説明し、コンセンサスを取る必要があります。 デザイナーがカバーする領域も広がる中、私たちデザイナーはどのようにデザインを共有するべきでしょうか? 今回は、UX MILKチームがどのように情報共有を行っているかを紹介します。 デザインドキュメントをどのように共有すべきか デザインドキュメントには、ワイヤーフレームやプロトタイプ、ビジュアルデザインなどさまざまなものがあります。 プロジェクトが進むにつれ、デザインドキュメントは増え、また変更が加えられていきます。すると、これらをどのように保存・整理し、共有するかという問題が出てきます。 UX MILKチームでは、こういった問題を解決するために、DocBaseを使ったデザインの共有を行っています。 なぜDocBaseで
株式会社rootのUIデザイナー 古里祐哉です(@remmyfurusato)。 rootでは、サービスの立ち上げやリニューアルに伴う、UI/UXデザインをご支援しています。 さて、今年を振り返えると「デザインガイドラインに注力した」年でした。デザインガイドラインを必要とされるクライアント様には共通点があります。 ・レイアウトパターンやパーツの使い方が定義されていないで、設計者やエンジニアが迷う。 ・結果、サービス全体の一貫性がなく使いづらい。 このような課題を抱えるクライアント様からのご依頼を多くいただきました。サービス開発の現場で、徐々にデザインガイドラインの重要性が広まってきているのではないでしょうか。 デザインガイドライン作成を通して考えたことをまとめたいと思います。 デザインガイドラインとは? デザインガイドラインの定義は「サービスやプラットフォームのデザイン方針を示したドキュメ
BenはUXPinのコンテンツ戦略担当者です。 Webウェブデザイナーとバックエンド開発者の両方として働いています。 人は馴染みがあるものを信頼します。そのことを知っている多くのデザイナーは、作品をできるだけシンプルにするよう努めています。また、シンプルなデザインは実用的でもあります。たとえば、一度ナビゲーションバーをデザインすれば、すべてのページで使うことができます。 しかし、デザインコンセプトはどんどん変化します。新しいアイデアを持つデザイナーが古いプロジェクトを引き継いだり、新しいコーディング手法が昨年の最先端に取って代わったりすることもあるでしょう。その結果、一貫性のないビジュアルとコードの寄せ集めになってしまいやがて問題となります。 デザインの一貫性とは デザインの一貫性がある製品は、変更を加えても見た目や動作が全体としてまとまりがあるように見えます。これは、特に大規模なサイトで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く