久保 シンスケ

業務システムのデザインのことを日々考えています

久保 シンスケ

業務システムのデザインのことを日々考えています

  • 組織

  • 業務システムのUIの特徴

    業務システムのUIデザインをしている立場から思った、業務システムならではのUIの特徴や、その理由・背景について書いています。

業務向けUIデザインシステムの代表例と、これから

リーガルテックAI SaaSであるMNTSQ（モンテスキュー）でプロダクトデザイナーをしているクボです。 この記事は、社内のプロダクトチームで実施している気軽な知見共有の会であるProduct Dev Talkで話した内容をもとに作成しました。 デジタルプロダクト向けには、一貫性のあるデザインやデザイン言語を定義し、そのデザインを統一的かつスケーラブルに適用するためのUIデザインシステムが存在します。一連のルールやガイドライン、コンポーネントなどが含まれており、多数のプロダ

久保 シンスケ

    • スタートアップに入ってひとりめデザイナーがやったいろいろ

      この記事は、MNTSQアドベントカレンダー2022の5日目です。 前回はSales西原さんのプロダクト販売開始から2年経過したMNTSQの現在地の記事でした。 機械学習テクノロジーと日本トップローファームの力を掛け合わせ、大企業の契約業務の変革を進めるAI SaaS、MNTSQでプロダクトデザイナーを務める久保です。クボスケと呼ばれています 本記事はMNTSQアドベントカレンダー2022の一環です。アドベントカレンダーとは、クリスマスまでの期間くらいに、みんなで1日ひと

      久保 シンスケ

      • エンタープライズSaaSのデザイナーは電気羊の夢を見るか？

        2022年6月にMNTSQ（モンテスキュー）株式会社にデザイナーとして入社しました、久保信介と申します。この記事は、いわゆる「入社エントリー」というやつです。 入社エントリーとは、新しい仕事環境へのオンボーディングも進み、なんとかだんだん慣れてきた気がする、同時にまだまだ転職したてのフレッシュな感覚を持ち合わせている、そんな入社して1ヶ月くらいのタイミングでなんか書いとこうぜ！ というものです（そして会社としては採用やらブランディングやらに役立てたいね！ というものです）。

        久保 シンスケ

        • 本当は怖いBAD UIの話

          これは、社内の勉強会にて“BAD UI（バッド・ユーアイ）”について発表したプレゼンテーションの内容を起こしたものです。 世の中にあふれる、なんでか残念なことになってしまっている数々のUIについて触れています。そのUIにいたってしまった事情を知らない立場から無責任に嘲笑ったりするのではなく、裏側の事情を想像したり、なぜそれが“BAD”なのか紐解いてみることで、UIについて考えることを身近に感じてもらおうと思って作りました。 残暑厳しい夏のころに発表したものなので、ちょっと

          久保 シンスケ

        業務向けUIデザインシステムの代表例と、これから

        久保 シンスケ

        マガジン

        • 組織
          96本
        • 業務システムのUIの特徴
          9本

        記事

          じぶんのUIデザイン原則

          デザイン原則とは最近、多くの企業やプロダクト・サービスが「デザイン原則」を公開するようになってきました。 「自分たちが良いと考えているデザイン」を明文化したものですが、たとえば“Cheerful, Fresh, Speedy”（適当です）のような数個のワードに集約して並べたような、企業やブランドの「理念」や「行動指針」により近いような抽象的なものをよく見かけます。 それだけ“デザイン”が担うものが拡大し、“デザイン経営”の考えかたや価値観が浸透してきているあらわれなのかも

          久保 シンスケ

          じぶんのUIデザイン原則

          久保 シンスケ

          エラーのデザイン

          エラーをどのようにユーザーにフィードバックし、訂正のアクションを促すのか、UIは通常時だけでなくエラー発生時についてもひと揃いのものとしてデザインされる必要があります。 誰だって“間違っている”と言われるのは嫌です。 入力のエラーをおこさないためにエラーのフィードバックの前に、まずはそもそもエラーとなる入力がされないように、デザインでできる工夫はいろいろあります。 わたしたち人間はいいかげんで、そんなに“正しい”行動が得意なようにはできていません。一言一句間違いなく覚え

          久保 シンスケ

          エラーのデザイン

          久保 シンスケ

          業務システムのUIの特徴 9　レガシーが継承されやすい

          業務システムは“古いつくり”を構造的に継承しやすくなっています。 まず、とくに基幹システムなどは規模が大きく連携するシステムや影響する範囲が広いため、いちどにすべて取り換えたりするのは危険なこともあります。ユーザー企業にとっても、マンパワー的に難しいことも多いでしょう。そのため、全体のロードマップを作ったうえで、部分的に範囲を区切りながらリプレイスを行なっていくことになります。 そして、独自システムまたはパッケージのカスタマイズの場合であっても、費用が高額で開発期間もそれ

          久保 シンスケ

          業務システムのUIの特徴 9　レガシーが継承されやすい

          久保 シンスケ

          業務システムのUIの特徴 8　繰り返し大量のデータ処理

          業務システムにおいて、とくに主要な機能については、日常的に大量のデータを繰り返し扱うことも多いです。 1件ずつ同じ作業を繰り返すのではなく、同等の大量のデータを一括で処理したり、一覧性がある表組（データテーブル）の形式でくらべながら編集をしたりするUIが役立ちます。 新規にレコードを作成するときは、まっさらなブランクの状態からではなく、既存のものから複製してそれを必要に応じて改変する形で作成することも多いです。 ひとつひとつの作業にかかるちょっとした手間が、大量・反復し

          久保 シンスケ

          業務システムのUIの特徴 8　繰り返し大量のデータ処理

          久保 シンスケ

          業務システムのUIの特徴 7　タスクベースとオブジェクトベース

          タスクベース 業務のタスクをもとに業務システムのUIを設計すると、同じような要素で似たような画面の重複が起こりやすく、ナビゲーションの複雑度が上がります。 例えば、たくさんの画像を取り扱うシステムをタスクベースで作ると、　 画像の閲覧 画像の編集 画像の削除 というナビゲーションになり、それぞれの遷移先はいずれにしても画像の一覧画面（コレクションビュー）です。並んだ中から対象の画像を選択して、それぞれの作業（閲覧／編集／削除）ができる詳細画面（シングルビュー）に移

          久保 シンスケ

          業務システムのUIの特徴 7　タスクベースとオブジェクトベース

          久保 シンスケ

          業務システムにつよいUIデザインライブラリー

          要件定義段階からプロトタイプを活用するアプローチ 私がつとめるアストロラボでは、DX推進支援事業におけるITソリューション開発で、プロジェクトの初期段階である要件定義からデザイナーが参加し、プロトタイプを活用して実際の業務をイメージしながらシステムの仕様を詳細に検討するアプローチをとっています。 従来のSI開発アプローチにおいては、UIデザイナーは、開発フェーズがある程度進んだあとで、ようやくアサインされることが多いと思います。しかしながら、その時点ではすでに合意し実装も

          久保 シンスケ

          業務システムにつよいUIデザインライブラリー

          久保 シンスケ

          業務システムのUIの特徴 6　帳票主義と業務フロー

          業務システム（日本の場合にとくに顕著であると言われています）の特徴として、帳票主義とでも呼べるようなものがあります。 これは、ちょうどシステムを利用することのゴールがさまざまなオブジェクトを組み合わせた帳票を出力するというタスクの達成になっているという状況です。 かならずしも帳票自体が悪いといわけではないのですが、個々のエンドユーザーにとってはゴールかもしれなくとも、業務全体から見ると帳票は中継フォーマットに過ぎなかったりします。次の別の業務フローやシステムに渡すためだ

          久保 シンスケ

          業務システムのUIの特徴 6　帳票主義と業務フロー

          久保 シンスケ

          業務システムのUIの特徴 5　エラーに対する許容度

          コンシューマー向けのシステムにおいてもとくに金融系など、決済まわりやKYCのように厳密性が強く求められるものはありますが、一般的にいって業務システムはコンシューマー向けのシステムに比べて、全体的にエラーに対する許容度は低め（エラーの発生について厳しめ）です。 システム内でデータを参照したり連携したりしている範囲にとどまらず、システム外での業務オペレーション自体にも波及すれば、影響範囲や損害の程度がかなり大きくなりうるからでしょう。 実行前／エラー発生前の状態に戻せる（Un

          久保 シンスケ

          業務システムのUIの特徴 5　エラーに対する許容度

          久保 シンスケ

          業務システムのUIの特徴 4　利用環境の限定

          業務システムでは、ユーザーだけでなく利用環境についても限定できます。 Webベースの場合、デバイスやOS、ブラウザー、ディスプレイサイズ・解像度など、対象利用環境は社内で導入しているものだけになるので、対象外の環境用の対策や検証を省くことができます。 ただし対象環境はデザイン時点でのものだけでなく、システムが利用される期間に実施されるの更新・設備投資の計画も考慮に入れる必要があります。 利用頻度が低い例外的なものへの対応をしたい場合は、追加の開発コストとして予算や投

          久保 シンスケ

          業務システムのUIの特徴 4　利用環境の限定

          久保 シンスケ

          業務システムのUIの特徴 3　ユーザーの専門性とレベルの限定

          UIデザインでは、対象とするユーザーが共通で持っている理解や期待に上手く沿うことで、“わかりやすさ”、“つかいやすさ”を実現できます。 企業内部で特定の目的で使われる業務システムでは、対象とするユーザーを不特定多数一般の場合ほど広くは想定する必要がなく、前提とする共通理解や専門性、リテラシーをある程度限定できます。 ユーザーが“慣れている”ものが“わかりやすい”、“つかいやすい”につながるとすると、特定の業務知識や業務手順を全ユーザーが共有している前提でデザインする

          久保 シンスケ

          業務システムのUIの特徴 3　ユーザーの専門性とレベルの限定

          久保 シンスケ

          業務システムのUIの特徴 2　権限と役割

          業務システムにおいて、同一のデータを取り扱う（全体としては）同一の業務でも、ユーザーが役割で分かれていることがよくあります。 たとえば、 起票者 入力担当者（BPOなど外部委託の場合もある） 承認者 管理者 など、それぞれに分化された役割ごとの作業が組み合わさって業務オペレーションが出来上がっているものです。 そしてそれぞれの役割のユーザーで、条件やニーズや異なります。 扱うデータの量（承認者や管理者はたくさんの実務者から集まった大量のデータを日々処理する な

          久保 シンスケ

          業務システムのUIの特徴 2　権限と役割

          久保 シンスケ

          業務システムのUIの特徴 1　定型作業の標準化と負担のバランス

          業務システムでは似たような定型作業も多いです。 操作手順やシステムのふるまいに一貫性を持たせることで、学習・作業効率を上げやすくなります。 また、複雑性保存の法則というものがあります。 これは「プロセスの単純化には限界があり複雑性は減らせないが移動は可能」ということです。 業務システムのUIにおいては、ユーザーの負担をなるべくシステム側に移したり、段階的にするなどして分散すること、として応用できます。例えば 項目数はそのままでも、適切な初期値（ブランクではなく大多数のユ

          久保 シンスケ

          業務システムのUIの特徴 1　定型作業の標準化と負担のバランス

          久保 シンスケ