本当に実践的なデザインドキュメントの書き方 第1回：なぜ渡されたワイヤーフレームは分かりにくいのか？ | アドビUX道場 #UXDojo
本当に実践的なデザインドキュメントの書き方 第1回：なぜ渡されたワイヤーフレームは分かりにくいのか？ | アドビUX道場 #UXDojo 連載 本当に実践的なデザインドキュメントの書き方 いきなり渡されたワイヤーフレームをデザインするよう言われて戸惑った経験は、デザイナーなら誰でもあるのではないでしょうか？これはディレクターとデザイナーの分業という状況に起因する問題ですが、分業が一般的なのにはもちろん理由があります。そこで、この連載では、現在の分業体制を前提に、情報設計に関わる『デザインドキュメント』をきちんと制作することで、この問題を解決する手段を探ります。 第1回は、受託のWeb制作における一般的な分業体制を詳細に分析し、よりデザイナーが貢献できる役割分担について考えていきます。 なかなかはじめられないUXデザイン これはGoogleトレンドで、「Webディレクター」「Webデザイナー
エラーメッセージ | コンテンツ | SmartHR Design System
アプリケーション内に表示するエラーメッセージの作成に関するガイドラインです。 エラーメッセージのライティングは、基本的にライティングスタイル、用字用語に準拠します。 そのほか、エラーメッセージ特有の気をつけるべきポイントを記載しています。 適用範囲アプリケーションを操作してエラーが発生したときに表示するメッセージすべてです。 ここでは、以下の場合について説明します。 バックグラウンド処理画面FlashMessageエラーメッセージの基本的な考え方エラーメッセージを表示する目的は、ユーザーがメッセージを見て問題を解決でき、次の操作に進める状態にすることです。 この状態を実現できないエラーメッセージだった場合、ユーザーの戸惑いや不安につながります。 ユーザーが問題を解決できる対処方法を明示した内容にすることを考えます。 エラーメッセージの基本的な要素どのエラーメッセージであっても、含める情報の
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
API仕様を書く（まとめ）: 柴田 芳樹 (Yoshiki Shibata)
「API仕様を書く」として私自身の過去の経験を書いたものを読みやすく並べてみました。 API仕様を書く（1） API仕様を書く（2） API仕様を書く（3） API仕様を書く（4） API仕様を書く（5）ー gRPC protoファイル ー API仕様を書く（6）ー gRPC protoファイル（2） ー API仕様を書く（7） ちょうど同じような内容が『A Philosophy of Software Design』に書かれていました。 関連する章は、第12章「Why Write Comments? The Four Execuses」と第15章「Write The Comments First」です。第12章では、コメントを書かない理由として多くのソフトウェアエンジニアが挙げる理由について反証しています。第15章ではコメントを最初に書くことの有用性を説いています。ここでのコメントは、私
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
システムのドキュメント整理と新メンバー加入時の説明順序 - Qiita
この文書について 構築済のシステムについて、保守の引継ぎや追加開発時の増員があったとき、 「新しく参画したメンバーがすぐにシステムを把握するために、どうしたらよいか？」 を考えた際のメモ 背景 問題 新しいメンバーの習熟に時間がかかる 原因 ドキュメントがない・整備されていない 初期構築に関わった人が運用をそのまま実施しており、ドキュメントがなくても困らなかった 新しく人が入ってきて、ようやく気づく 索引がなく、知りたい情報がどこにあるか探すのが大変 今、何が正しいかがすぐにわからない 初期構築時の要件定義書はあるが、追加開発で要件が変わってしまった 追加開発時のドキュメントも全部読まないと何が正しいかがわからない 說明が体系だっていない OJT的な教え方しかできていない 運用や小規模改修から入って、徐々に慣れていってもらうはずが、 枝葉の部分だけ詳しくなってシステムの全容はわからずじまい
若手プログラマー必読！５分で理解できるER図の書き方５ステップ
データベース設計の基本中の基本であるER図。ER図を書きたいけど、「記法が分からない」「どういうステップで書けば良いか分からない」という若手エンジニアも多いのではないでしょうか。 ER図は１０種類近くあり、種類によって記法が異なります。このことが難しいイメージを与えていますが、実はそれほど難しいものではありません。覚えれば良いER図は２種類だけです。 しかも、この記事で解説している基礎知識を押えれば、たった５つのステップで作成することができます。 この記事では、ER図の基礎知識からER図の書き方まで、エンジニアが抑えておくべきER図の全知識をどこよりも分かりやすく解説します。 この記事を読み終えたとき、若手エンジニアもER図を書けるようになっているでしょう。 この記事を参考に最適なデータベース設計を進めて下さい。 １．ER図とは ER図とは、「データベース設計（データモデリング）で使う設計
コードを書く際の指針として見返すサイトまとめ - Qiita
お勧めの記事がありましたらコメントなどで教えて頂けると幸いです。 Guidelines プログラマが知るべき97のこと 技術的負債 不慣れなコードベースで短期間に生産性を高めるための7つの方法 何も知らない人を育てるために(新人教育情報キュレーション) 保守開発に開発者として入って困ることのまとめ(実体験) 技術系の名言まとめ++ 真似をする前にバッドプラクティスかどうかを調べてみよう 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） 技術的負債とどうやって戦うか Coding Style モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう 関数名や変数名に使えそうな動詞・名詞・形容詞のメモ Naming -名前付け- DRY原則をもう一度 -コンカレント・エンジニアリング- レガシーコードのメンテナンス担当になったら新人はどうすればいい クソコードに対する怒りとコー
LevelDBの設計ドキュメント和訳 - Qiita
Cassandraのストレージには、SizedTierCompactionと、Google LevelDBをもとにしたLeveledCompactionという二つのコンパクション戦略が存在し、ワークロードによって開発者が自由に選択できるようになっています。しかしLeveledCompactionの具体的な挙動がいまひとつ、よく分からず、選択の決め手に欠ける状態でした。 そこで、オリジナルであるLevelDBの実装を調べてみることにしました。インターネット上にLevelDBの解説は多いですが、具体的にどのようなファイルI/Oが発行されているのかはっきりしなかったので、LevelDB開発者向けドキュメントを和訳しました。結果、よく出来てるなーという事がわかったので安心してLeveledCompactionを使おうと思います。 参考 - LevelDB入門 (基本編) - from scratc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
