GitHubのようにFigmaを使う【デザインファイルの運用方法】｜三上蒼太 / Sota Mikami
こんにちは、株式会社アトラエでデザイナーをしています三上蒼太です。 この記事は、Atrae Advent Calendar 2019 の3日目です。 本記事では、Figmaでのデザインファイルの運用方法について書きます。 これが完成形という訳でもなく、まだ模索中の段階です。そしてチームのステージやメンバーの特性によって柔軟に変えていくものだと思っています。 運用方法に迷われている方の一つの参考事例となれば幸いです。 そもそもなぜ"運用"が大事？ サービスは、公開して終わりではありません。 運用し、機能を追加したりABテストするなどしながら設定した目標を達成すべくアップデートしていくことが前提です。 また、サービスの運用は短期的なものではありません。 数年、もしかしたら数十年のスパンの中で、いろんなステークホルダーが参画しては抜けてを繰り返しながら進んでいくはずのものです。 サービスデザイン
【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
