タグ

設計とエンジニアに関するkei_0000のブックマーク (2)

  • 画面をデザインするということ - Qiita

    この記事は社内の勉強会で話した内容を再編したものです。 私自身はPC/ブラウザ/スマホのアプリ開発をしている1エンジニアにすぎないのですが、対客や要件定義から開発、運用、そしてUIのデザインを担当しており、自分なりに伝えられるものがないかと試みたものです。 デザインとは デザインとは単に見た目だけの話ではなく、「ビジネス」と「ユーザーが得る体験価値」から始まり、それを実データと結びつけながら人の認知を通してどう見せるのかという作業です。 始まりの部分は最近だとUXデザイナー、終わりの部分はUIデザイナーとかグラフィックデザイナーとか呼ばれるような人の仕事です。そしてそれらを形にするのがエンジニアです。 画面を設計するまでの作業 ギャレットのUX5段階モデルに従って、どういったことを考えないといけないのか確認します。 (実際にUX5段階モデルを意識して仕事してるわけではありませんが、何かしら

    画面をデザインするということ - Qiita
    kei_0000
    kei_0000 2020/09/17
    「表層:見た目のデザイン/骨格:画面パターン・ワイヤー、画面遷移とか諸々のルール/構造:APIやデータの設計/要件:要件定義/戦略:ビジネスの目的・目標」全部きちんとやるのは大変。1人でよく考えた後、助けを借りたい
  • 設計書には何を書くべきなのか - terurouメモ

    設計とは、 要求(やりたいこと)をヒアリングする 要求を要件(何を満たさないといけないのか)に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する(一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する) 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案(いわゆる比較表で書いていくのが楽) 検証結果 選定・合意結果(合意した代替策や妥協ラインについても記載する) 詳細設計(どういう実装にするとか、パラメーターにするとか、細

    設計書には何を書くべきなのか - terurouメモ
    kei_0000
    kei_0000 2020/07/30
    自分なりのまとめ 1.要求(やりたいこと) 2.要件(やると決まったこと) 3.方式(実装方法の概要・方針) 4.詳細設計(実装方法の詳細)
  • 1