1. デザイン組織の定義 => デザイン負債の返済 => 一貫性のメンテナンス 2. デザインの領域 => デザインフェーズと実装フェーズに分ける => UI作成だけでなく仮説検証からコミット 3. デザイン知見の共有 => dely.design でのブログ発信
デザインは軽視するには重要すぎる / Design is important
1. デザイン組織の定義 => デザイン負債の返済 => 一貫性のメンテナンス 2. デザインの領域 => デザインフェーズと実装フェーズに分ける => UI作成だけでなく仮説検証からコミット 3. デザイン知見の共有 => dely.design でのブログ発信
Web Components で 社内 UI ライブラリを作っている 話
WebComponents.kyoto Meetup #2 での発表資料です。 https://wc-kyoto.connpass.com/event/78690/
ユーザーに受け入れられ、問題を起こしづらい大規模リニューアルの進め方
iOSDC Japan 2016の発表資料です。 https://iosdc.jp/2016/c/node/84
スマートフォンアプリ開発における共創的な開発チーム
複雑かつリッチな体験を提供するスマートフォンアプリを開発するためのチームワーク、その中でのエンジニアの役割について
デザイン組織を作って実行したこと // Speaker Deck
All slide content and descriptions are owned by their creators.
UIの話は会議室でするな
9. ● 常に文書による指示を要求せよ。 ● 準備を十分行い完全に準備ができているまで実行に移すな。 ● 些細なことにも高い完成度を要求せよ。わずかな間違いも繰り返し修正させ小さな 間違いも見つけ出せ。 ● 重要な決定を行う際には会議を開け。 ● もっともらしくペーパーワークを増大させよ。 ● すべての規則を隅々まで厳格に適用せよ。 ● 何事をするにも「通常のルート」を通して行うように主張せよ。決断を早めるため のショートカットを認めるな。 ● 可能な限りの事象を委員会に持ち込み「さらなる調査と熟考」を求めよ。委員会の メンバーはできるだけ多く（少なくとも5人以上）すること。 ● 議事録や連絡用文書、決議書などにおいて細かい言葉遣いについて議論せよ。 ● 以前の会議で決まったことを再び持ち出し、その妥当性について改めて問い直せ。 10. ● 常に文書による指示を要求せよ。 ● 準備を十分行
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
宣言的UI
GitHub - glidejs/glide: A dependency-free JavaScript ES6 slider and carousel. It’s lightweight, flexible and fast. Designed to slide. No less, no more
Designer meets Domain-Driven-Design
UIデザインは誰のもの？
Kaizen Platform における UI ライブラリのワークフロー
XCode6 / iPhone6 / iOS8 デザイナーが知ってると 便利なTips
社内システムの構造と設計、実装のはなし(下書きバージョン)