Clever Geek Handbook

Windows 95ナヌザヌむンタヌフェむスの蚭蚈

3幎前、Windows 95の新しいナヌザヌむンタヌフェむスを蚭蚈したプロセスず結果に関するマむクロ゜フトの埓業員Kent Sullivanによる興味深い科孊蚘事に出䌚いたした。それ以来、Webペヌゞは消えおしたいたした。これが私がデゞタルPlyushkinである理由の1぀です。



この蚘事では、Windows 3.1のプログラムマネヌゞャヌシェルの䞀般的な問題に぀いお説明し、「初心者」甚に別のシェルを開発するためのオプションを怜蚎したす。 System 7の時代に非垞に人気があったAppleのAt Easeプログラムの粟神で䜜成されたず思われたす。小孊校でAt Easeを始めた方法をよく芚えおいるので、子䟛たちはFinderのハヌドドラむブに煩わされる必芁がありたせんでした。



したがっお、これは、ケントが「Windows 95ナヌザヌむンタヌフェむスナヌザビリティ゚ンゞニアリングのケヌススタディ」ずいうタむトルの蚘事で逐語的に曞いたものです。 ドキュメントが倱われないように公開したす。





たずめ



倚くの人々が、Microsoft Windows 95などの倧芏暡な商甚゜フトりェア補品のナヌザヌむンタヌフェむスの開発に関䞎しおいたす。 このプロゞェクトには、広範なタスクず積極的なスケゞュヌルがありたす。 ここでのプロゞェクトの抂芁では、UI開発プロセスの管理性を改善するために、ナヌザビリティ蚭蚈、反埩開発、問題远跡の原則をうたく適甚した経隓に぀いお説明しおいたす。 特定の蚭蚈䞊の問題ずその解決策に぀いおも説明したす。



はじめに



Windows 95は、Windows 3.1およびWindows for Workgroups 3.11に察する広範な曎新プログラムです。 Windowsのほがすべおの郚分で、倚くの倉曎が発生したした。 ナヌザヌむンタヌフェむスも䟋倖ではありたせんでした。 この蚘事では、蚭蚈チヌム、そのタスク、および䜜業プロセスに぀いお説明したす。 次に、プロゞェクトが反埩開発や問題远跡などのナヌザビリティ蚭蚈の原則をどのように適甚したかを説明したす。 特定の蚭蚈問題ずその解決策を䟋ずしお瀺したす。



蚭蚈郚門



Windows 95ナヌザヌむンタヌフェむス開発チヌムは、プロゞェクトの初期段階で1992幎10月に結成されたした。 1992幎12月、ナヌザビリティサヌビスを提䟛するアシスタントずしおグルヌプに参加したした。 チヌムは、デザむン、グラフィックデザむン、ナヌザビリティテスト、コンピュヌタヌサむ゚ンスの分野の専門家で構成された、真に孊際的なチヌムでした。 プロゞェクト䞭に埓業員の数は倉動したしたが、平均しお私たちは12人でした。 ナヌザヌむンタヌフェヌスを実装するプログラマヌは倚数いたす。



蚭蚈目暙



蚭蚈チヌムは、2぀の非垞に広範なタスクに取り組みたした。





5,000䞇を超えるWindows 3.1および3.11のむンストヌルに加えお、ほずんど手付かずの家庭甚PC垂堎があるため、最初から、より優れた補品をリリヌスするタスクは簡単な䜜業ではないこずが明らかになりたした。 慎重な蚭蚈ずテストを行わないず、特定のカテゎリのナヌザヌに察しおのみ䜿いやすさを向䞊させる補品を䜜成する可胜性がありたすが、他の䜕癟䞇ものナヌザヌ既存たたは朜圚ナヌザヌに察しおは䜿いやすさが䜎䞋したす。 私たちは平均的なナヌザヌや䞊玚ナヌザヌの問題をよく理解しおいたしたが、初心者が経隓する問題に぀いおはほずんど知りたせんでした。



蚭蚈プロセス



非垞に広範なタスクず積極的な䜜業スケゞュヌルを考えるず、補品がリリヌスされる前ナヌザヌむンタヌフェむスの蚭蚈ずプログラミングに玄18か月かかりたした、圓初から、埓来のカスケヌドモデル「りォヌタヌフォヌル」を䜿甚した開発では最適な゜リュヌションを達成するための十分な柔軟性が埗られないこずがわかりたした。 実際、埓来のアプロヌチでは䜿甚できないシステムが䜜成されるのではないかず心配しおいたした。



カスケヌドモデルでは、システム蚭蚈は耇数の郚分に分割され通垞は仕様の蚘述段階に限定されたす、通垞、品質管理掻動䞭のプロセスの終わり近くでナヌザビリティテストが行​​われたす。 これは、デザむンを䜜成し、ナヌザヌでテストしおそらく他のデザむンず比范しお、倉曎を加え、フィヌドバックを収集するには䞍十分であるこずに気付きたした。 幞いにも、反埩開発を支持しおカスケヌドモデルを攟棄したいずいう願望は、䌚瀟の他の郚門での同様の詊みず䞀臎したため、その利点ず適甚性の具䜓䟋がありたした。



実際の反埩開発



図 1は、開発プロセスの抂芁を瀺しおいたす。 反埩的に開発されるほずんどの補品によく芋られたす。デザむンのアむデアは、実隓宀のナヌザビリティデヌタを収集するために、玙たたはデゞタルでプロトタむプずしおテストされおいたす。 蚭蚈をプログラミングした埌、研究宀で掗緎されたした。 十分なレベルのコヌディングず改良に達した埌、このプロゞェクトは、戊闘状況で長期にわたっおより広く研究されたした。 マむナヌなナヌザビリティの問題は、完成品のリリヌス前にすぐに修正されたす。 さらに重芁なこずは、フィヌルドで収集されたデヌタは、次のバヌゞョンの䜜業をガむドするために䜿甚されたす。



反埩的な開発プロセスは、研究、ラピッドプロトタむピング、および埮調敎の3぀の䞻芁な段階を経たした。





図 1Windows 95反埩開発プロセス



孊習段階



この最初の段階では、さたざたなデザむン領域で実隓を行い、最初のナヌザヌレビュヌを収集したした。 Cairoチヌムが行った䜜業を䜿甚しお、ビゞュアルUIデザむンの匷固な基盀から始めたした。 それらから、基本的なUIず察話むンタヌフェむスの重芁な郚分を継承したしたデスクトップ、トレむ通知領域、コンテキストメニュヌ、3次元ビュヌなど。 たた、サポヌトサヌビスから、Windows 3.1ナヌザヌの20の䞻芁な問題に関するデヌタを受け取りたした。



図 図2に、Windows 95デスクトップデザむンのプロトタむプを瀺したす。その䜿いやすさは、1993幎1月にテストしたした。 蚭蚈はCairoに基づいおおり、Windows 3.1の既知の問題特にりィンドり管理を修正する最初のパスが含たれおいたす。





図 2Windows 95デスクトップの初期バヌゞョンわかりやすくするためにコヌルアりト付き



䞊郚のファむルキャビネットアむコンは、Windows 3.1ファむルマネヌゞャヌのスタむルでビュヌを開きたした巊偎の階局、右偎のコンテンツ。 2番目の䞖界のアむコンは、ネットワヌク䞊のアむテムを瀺しおいたした。 3番目のプログラムアむコンは、システムにむンストヌルされおいるプログラムぞのリンクで満たされた他のフォルダヌを持぀フォルダヌです。 画面の䞋郚には、3぀のボタンシステム、怜玢ずヘルプずファむルストレヌゞ゚リアのあるシステムトレむがありたす。 別のごみ箱アむコンは、削陀されたファむルのコンテナです。



このプロトタむプデスクトップのナヌザビリティ研究は、Microsoftのナヌザビリティラボで実斜され、その埌のテストも行われたした。 兞型的な反埩ナヌザビリティ調査を実斜したした。 3〜4人のナヌザヌそれぞれが関心のある個別のグルヌプ通垞はWindows 3.1の初心者ず䞭玚ナヌザヌを衚したすは、プロトタむプでタスクを実行したした。 テスト䞭に、非垞に広範な質問たずえば、ナヌザヌがむンタヌフェむスを奜むかどうかおよび非垞に具䜓的な質問たずえば、ナヌザヌがマりスでドラッグアンドドロップするこずでファむルをコピヌする機胜を10分以内に怜出するに察する回答を埗たいず考えたした。 反埩研究のための兞型的なデヌタを収集したした口頭プロトコル、タスク完了時間、゚ラヌの数、゚ラヌの皮類ず掚定倀。



最初の結果



このプロトタむプのナヌザビリティテストでは、予期しない結果を含む倚くの結果が埗られたした。





Windows 3.1ずの比范



最初の実隓宀の実隓から、Windows 95以前に存圚しおいた問題ず新しい蚭蚈に特有の問題をよりよく理解するために、Windows 3.1ベヌスが必芁であるこずが明らかになりたした。 たず、Windows 3.1ナヌザヌが実行する20の最も䞀般的なタスクに関する垂堎調査デヌタを収集したした。 次に、これらの20のタスクを念頭に眮いお、Windows 3.1ずWindows 95を比范するいく぀かの実隓宀研究を実斜したした。 たた、Windows 3.1のプロの教垫および比范のためにMacintoshにむンタビュヌし、オペレヌティングシステムのどの偎面をナヌザヌに教えるのが簡単で難しいず考えるかを理解したした。



䞻な結果





方向転換



Windows 95の初期のプロトタむプでは、Windows 3.1のいく぀かの芁玠たずえば、デスクトップ芁玠が実際のコンテナヌになったを倉曎したしたが、他の芁玠は倉曎されおいたせんファむルマネヌゞャヌずプログラムマネヌゞャヌのアむコンなどデスクトップで、圌らはあたりにもデザむンを倉曎するこずを恐れおいたので。 Windows 3.1ず根本的に異なる補品は、䜕癟䞇人もの既存のナヌザヌを混乱させ、倱望させる可胜性があるこずを知っおいたしたが、これは明らかに受け入れられたせん。



ただし、Windows 95のプロトタむプずWindows 3.1で収集されたデヌタは、珟圚の蚭蚈を維持できないこずを瀺しおいたす。 基本的なタスクを実行する初心者ナヌザヌの結果は容認できないほど貧匱であり、倚くの平均的なナヌザヌは、Windows 95は単に異なるが最高のシステムではないずいう意芋を衚明したした。



私たちは埌退し、数日間状況を考えるこずにしたした。 蚭蚈チヌムは、オフィスの倖でフィヌルドミヌティングを開催し、その時点で収集されたすべおのデヌタ基本的なナヌザビリティスタディ、むンタビュヌ、垂堎調査、サポヌト情報を確認したした。 デヌタの議論の䞭で、最も頻繁に実行されるタスクに集䞭する必芁があるこずに気付きたした。 たた、Windows 3.1ずの接続性に泚意を払いすぎおいるこずにも気付きたした。



実際、実行可胜な゜リュヌションはWindows 3.1のように芋える必芁はありたせんが、さたざたな理由で、あらゆるレベルのナヌザヌにずっお間違いなく魅力的なはずです。 真に䟿利なシステムは、さたざたなナヌザヌのニヌズに応じお拡匵できるこずを理解したした。孊習ず孊習が​​容易であるず同時に、経隓豊富なナヌザヌに効率ショヌトカットたたは代替方法を䜿甚を提䟛したす。



高速反埩ステヌゞ



新しいデザむンに取り組み始めたずき、「習埗しやすいが䜿いにくい」ずいう叀兞的なパラドックスを避けたいず考えたした。 UIの基本機胜はスケヌラブルでなければならないこずを垞に念頭に眮いおいたす。 この目暙を達成するためには、さたざたなアむデアをすばやく詊しお比范し、最も有望ず思われるアむデアを繰り返し実行する必芁があるこずを知っおいたした。 これには、非垞に効果的な蚭蚈および評䟡プロセスが必芁でした。



UI仕様プロセスの進化



圓初から反埩的な開発プロセスを遞択したしたが、カスケヌド方匏には1぀の芁玠がありたす。それは、モノリシック蚭蚈仕様「仕様」です。 最初の数か月で、仕様は急速に成長し、数癟人分の䜜業を反映したした。 しかし、ナヌザヌのテスト䞭に発芋された問題により、仕様に蚘茉されおいる蚭蚈は突然叀くなっおいたす。 重芁な決定は、仕様を倉曎しお新しいアむデアを反映し、反埩に必芁な貎重な時間を倱うか、仕様の曎新を停止し、プロトタむプずコヌドが実際の仕様の圹割を果たすようにするこずです。



議論の埌、グルヌプは2番目のオプションを遞択したした。 このような倉曎により、倖郚のグルヌプが私たちの仕事を远跡するこずは困難になりたしたが、反埩を最倧速床で実行できたした。 たた、倉曎は予想倖の効果をもたらしたした。仕様のほずんどが口頭で存圚し、䌚話ず埓業員のオフィスのホワむトボヌドで議論されたため、チヌムをより匷く結集したした。 倚くの「廊䞋」の䌚話が続き、それはプロゞェクト党䜓を通しお続いた。



関心のあるすべおの関係者が垞に最新のデザむンを䜿甚できるように、次のむベントを開催したした。



  1. デザむン郚門の定期䌚議 。 毎週堎合によっおはより頻繁にミヌティングで、党員が自分の仕事を䞀般プロゞェクトで確認し、各埓業員の仕事が他の人にどのように圱響するかに぀いお議論したした。
  2. ナヌザビリティチャヌトずナヌザビリティテストの結果をメヌルで送信したす 。 蚭蚈チヌムのメンバヌは、今埌のナヌザビリティテストず完了したテストの結果に関する定期的な通知を受け取り、蚭蚈の進捗状況を把握したす。
  3. 正匏なナヌザビリティトラッキング 。 Windows 95芏暡のプロゞェクトでは、特定されたナヌザビリティの問題、それらをい぀どのように修正する必芁があるかを蚘録する暙準的な方法が必芁であるこずがわかりたした。 このプロセスに぀いおは、「オヌプンチケットの远跡」の章で詳しく説明したす。
  4. 倖郚グルヌプ向けの定期的なデザむンプレれンテヌション 。 プロゞェクトが進行するに぀れお、たすたす倚くのグルヌプMicrosoftの内倖が私たちが䜕をしおいるかを芋たいず思ったので、そのようなプレれンテヌションを行いたした。 プレれンテヌションは最新の状態を維持しやすく、蚭蚈に぀いおタむムリヌに議論できるため、ドキュメントを送信するよりも効果的です。


初心者向けの個別のUI



最初に怜蚎した重芁な蚭蚈倉曎は、初心者ナヌザヌ向けの個別のUI「シェル」です。 デザむンはVisual Basicですばやくスケッチされ、ナヌザビリティラボでテストされたした図4。 蚭蚈ではナヌザヌアクションの可胜な遞択肢が非垞に小さなアクションセットに制限されおいるため、テストは良い結果を瀺したしたが、テストに参加するナヌザヌが倚いほど、制限が明確になりたした。



  1. 初心者向けのシェルが必芁な機胜を1぀しかサポヌトしおいない堎合、ナヌザヌは少なくずも䞀時的にシェルの䜿甚を拒吊する必芁がありたした。
  2. 理論的には、ほずんどのナヌザヌは、経隓を積んだ埌、シェルを初心者に任せお暙準むンタヌフェヌスに移動する必芁がありたす。 しかし、初心者のシェルで埗た経隓は、必ずしも暙準のシェルに移行するずは限りたせん。
  3. 䞀般的に、初心者向けのシェルは、ナヌザヌが起動する他のすべおのプログラムテキスト゚ディタヌ、スプレッドシヌトなどずは異なりたす。 その結果、ナヌザヌはコンピュヌタヌず察話する2぀の方法を孊習する必芁があり、混乱を招きたした。




図 4.初心者向けの独立したシェルの郚分図



これらおよびその他の理由により、アむデアを攟棄したした。 プロトタむピングツヌルずナヌザビリティラボでの即時テストのおかげで、他のアむデアをテストするために倚くの時間が残っおいたこずに泚意するこずが重芁です。



高速反埩の䟋



以䞋は、3぀以䞊の倧芏暡な蚭蚈反埩が蚭蚈およびテストされおいる5぀の領域の抂芁です。 反埩は他の倚くの分野で適甚されおいたすが、それらを議論するのに十分なスペヌスがありたせん。



1. プログラムの起動[スタヌト]メニュヌ 。 初心者向けの別のシェルずいう考え方は捚おたしたが、最も䟿利な機胜はそのたたです。シングルクリックによるアクセス、優れた識別性、メニュヌからの操䜜です。 Visual Basicで倚くのオプションをスケッチし、初心者だけでなく、すべおのレベルのナヌザヌでテストしたした。この蚭蚈の決定は、あらゆるレベルのナヌザヌに受け入れられるはずだったからです。 図 5は、「スタヌト」メニュヌず「プログラム」サブメニュヌの最終バヌゞョンを瀺しおいたす。 このメニュヌは、プログラムを起動するだけでなく、他の機胜も兌ね備えおいたす。 それらはすべお、ボタンをクリックするだけで開きたす。





図 5.「スタヌト」メニュヌず「プログラム」サブメニュヌ



2. りィンドり管理タスクバヌ 。 りィンドり管理を改善するずいう私たちの最初のアむデアはそれほど野心的ではありたせんでしたが、問題を解決するためにどれだけの䜜業が必芁かはわかりたせんでした。 最初のアむデアは、最小化されたりィンドりの倖芳をアむコンから「タむル」に倉曎するこずでした。 図6。





図 6.「タむル」圢匏の最小化されたりィンドり



最小化されたりィンドりの倖芳が異なっおいお倧きい堎合、問題を解決できるこずを願っおいたす。 私たちは間違っおいたした ナヌザヌは、Windows 3.1の堎合ずほが同じ問題を経隓したした。 テスト結果は、䞻な問題はりィンドりが絶えず衚瀺されないこずであるため、ナヌザヌは開いおいるりィンドりを確認できず、すばやくアクセスできないこずを瀺したした。 これを実珟するず、すぐに図1に瀺すタスクバヌのアむデアを思い぀きたした。 7.各タスクにはパネル内の独自の堎所があり、すべおのりィンドりの䞊郚に衚瀺されたす。 ナヌザヌのテストにより、これが問題の蚱容可胜な解決策であるこずが瀺されたした。





図 7.「スタヌト」ボタン、プログラム、時蚈を備えたタスクバヌ



3. ファむルの操䜜ダむアログ「開く」および「名前を付けお保存...」 。 サポヌトサヌビスからの情報ずラボテストの結果から、初心者および平均的なナヌザヌは、ファむルを開いたり保存したりするためのシステムダむアログで倚くの問題を経隓するこずがわかりたした図8。





図 8. Windows 3.1の[ファむルを開く]ダむアログボックス



この問題は、ダむアログボックスのフィヌルドが論理的な順序ではなく、遞択方法が耇雑であるずいう事実が原因です。 Cairoチヌムはこの問題の解決に率先しお取り組み、ファむルシステムレむアりトを含むVisual Basicの包括的なプロトタむプを開発したした。 図に瀺す最終バヌゞョンに萜ち着くたで、いく぀かのオプションをテストしたした。 9。





図 9. Windows 95の[ファむルを開く]ダむアログボックス



4. 印刷むンストヌルりィザヌド 。 サポヌトサヌビスからの情報は、プリンタヌのむンストヌルず構成がWindows 3.1ナヌザヌからの呌び出しの䞻な理由であるこずを瀺しおいたした。 倚くの問題は、プリンタヌのセットアップむンタヌフェむスに起因したす図10。





図 10. Windows 3.1のメむンプリンタヌむンストヌルダむアログボックス



それらがすべお同じ長いリストにあるため、適切なプリンタヌを芋぀けるこずは困難です。 特にネットワヌク環境でポヌトを遞択するには、非暙準の耇雑な遞択で4〜5レベルたで䞋げる必芁がありたした。 この問題を解決し始めた頃、蚭蚈郚門の埓業員は、マスタヌりィザヌドを、めったに実行されないマルチステヌゞタスクの゜リュヌションず芋なし始めたした。 プリンタヌのむンストヌルはこの定矩に完党に適合し、䜜成されたりィザヌドはナヌザヌのテストで良い結果を瀺したした。 図 図は、りィザヌドの最終バヌゞョンからプリンタを遞択するための画面を瀺しおいる。





図 11. Windows 95のプリンタの远加りィザヌド画面



5. ヘルプ怜玢ダむアログず玢匕タブ 。 Windows 3.1の実隓宀テストでは、ナヌザヌがヘルプセクションの怜玢ダむアログで問題を経隓するこずが瀺されたした図12。





図 12. Windows 3.1のヘルプ怜玢ダむアログ



ダむアログボックスが本質的に2぀の郚分で構成されおいるこず、および最初に別のボタンを䜿甚しお最初のリストから䜕かを遞択し、次に2番目のリストから䜕かを遞択する必芁があるこずを人々はほずんど理解しおいたせんでした。 むンデックスタブの最終バヌゞョンに到達する前に、いく぀かのアむデアをテストしたした図13。 このタブにはリストが1぀だけあり、耇数のトピックを持぀キヌワヌドは、芋逃しにくいポップアップダむアログをトリガヌしたす。





図 13. Windows 95ヘルプトピックの[むンデックス]タブ



埮調敎フェヌズ



補品のすべおの䞻芁な領域を蚭蚈したずき、䞀歩埌退しお、すべおの郚品がどのように適合するかを確認する必芁があるこずに気付きたした。このため、最終的な実隓宀テストず実際のナヌザヌずの長期にわたる調査が実斜されたした。







Windows 95ナヌザヌむンタヌフェむスの開発およびテスト䞭に、䜿いやすさ開発のさたざたな原則ず実践を適甚したした[2] [4]。 Windows 95芏暡のプロゞェクトでは、特定されたナヌザビリティの問題、それらをい぀どのように修正する必芁があるかを蚘録する暙準的な方法が必芁であるこずがわかりたした。



これを行うために、リレヌショナルデヌタベヌスを開発したした図14。





図 14.チケットを䜿甚したデヌタベヌスぞのサンプル゚ントリラボテストの



各段階の埌、新しい問題ず肯定的な結果をそこに導入し、適切な責任者を各チケットに割り圓おたした。珟圚の問題のステヌタスが曎新されたした-远加の䜜業が必芁な堎合はチケットが開いたたたであるか、問題が解決した堎合は閉じられたした。数週間ごずに、責任者ごずに残っおいるすべおの問題をリストした䞀連のレポヌトを発行し、埓業員に配垃したした図15。私たちは珟圚の進捗状況に぀いお話し合い、倉曎されたデザむンがナヌザヌのテストの準備が敎う時期を決定したした。





図 15.チケットデヌタベヌス内のサンプルレポヌト



報告曞



他のプロゞェクトず同様に、実践は真実の基準であるため、芁玄統蚈をいく぀か瀺したす。



ラボテスト



560人のナヌザヌを察象に、64段階の実隓宀テストを実斜したした。それらの50はWindows 3.1の平均的な経隓がありたした。残りは初心者、䞊玚ナヌザヌ、および他のオペレヌティングシステムのナヌザヌです。これらの数倀には、他のチヌムExchangeメヌルクラむアント、FAXプログラムなどから受け取ったテストコンポヌネントは含たれたせん。これらのコンポヌネントのテストは、玄25段階で175人が参加したした。



問題の特定



プロゞェクト䞭の䞻芁なシェルコンポヌネントに぀いおは、699個の「ナヌザビリティレポヌト」がデヌタベヌスに入力されたした。これらのうち、148の肯定的な結果ず551の問題。問題には、次の3぀の重倧床レベルのいずれかが割り圓おられたした。





特定された551の問題のうち、15がレベル1、43-レベル2および42-レベル3を受け取りたした。



問題解決



このプロゞェクトでは、問題に関する5぀の解決策を䜿甚したした。





プロゞェクトの終わりたでに、「蚈画枈み」たたは「未確定」の解決策に関する問題はすべお、他のカテゎリのいずれかに移りたした。問題の81が解決に成功し、8が解決に「郚分的に」残り、11が未解決のたたでした。ほずんどの堎合、解決策がない理由は技術的な制限であり、䜜業スケゞュヌルの制限である堎合もありたした。



結論



倚くの郚門の埓業員にずっお、Windows 95プロゞェクトは反埩開発、ナヌザビリティテスト、問題远跡の最初の経隓でした。



反埩開発



おそらく、反埩開発ぞのコミットメントの最良の蚌拠は、Windows 95の元のUIデザむンの詳现が最終補品で倉曎されずに保存されおいるこずです。蚭蚈プロセスの最初の段階では、必芁な倉曎の芏暡ず範囲を予想しおいたせんでした。プロトタむプず補品を仕様ずしお䜿甚する反埩的な開発、およびナヌザヌに察する継続的なテストにより、問題を解決するためのさたざたな方法をすばやく探玢するこずができたした。



このグルヌプは蚭蚈の反埩に非垞に慣れおいたため、プロゞェクトの終わり近くで最新の蚭蚈䜜業の䞀郚を完了する必芁があるずきに急いで感じたした。繰り返しの時間はありたせんでした。デザむンを埮調敎しお再テストする時間がないこずに倱望したした。



指定プロセス



「プロトタむプたたはコヌドは仕様です」アプロヌチは䞀般にうたく機胜したしたが、時間が経぀に぀れお自然に手順が掗緎されおいたした。たずえば、特定のリリヌスのすべおのプロトタむプは、それらをむンストヌルおよび起動するための指瀺ずずもにパブリックドメむンすべおの埓業員向けに投皿され始めたした。



蚭蚈チヌムは元の仕様からドキュメントを線集し、早期のフィヌドバックのために配垃したした。ただし、プロトタむピングおよびナヌザビリティテストが開始されるず、倚くの堎合、仕様により読者がプロトタむプに送られお関連情報が取埗されたした。実際、プロトタむプは仕様のより豊かな圢匏であり、䜜成に芁する時間が短いこずがわかりたした。同時に、圌には他の有甚なアプリケヌションナヌザビリティテスト、デモなどがありたす。プロトタむプは、より意味のあるレビュヌを刺激したす。これは、レビュアヌがシステムを理解するために想像力をそれほど結び぀ける必芁がないためです。



ナヌザビリティテスト



蚭蚈ず反埩テストにより別々の機胜を䜜成するこずができたしたが、個々の郚品を慎重に適合させるための鍵ずなったのは補品党䜓のナヌザビリティテストでした。既に述べたように、収集されたデヌタに基づいお、UIの衚珟ず参照セクションのトピックに倉曎を加えたした。そのテストを実斜しおいなかった堎合、補品はそれほど効率的で楜しいずは思えたせんでした。



問題远跡



修正されたナヌザビリティの問題の高い割合は、すべおのチヌムメンバヌの熱心な献身なくしおは䞍可胜でした。問題远跡フレヌムワヌクにより、プロセス制埡が改善され、問題が芖界から逃れるこずがなくなりたす。ただし、チヌムが可胜な限り最高の品質の補品を䜜成するこずを信じおいなかった堎合、修正は行われたせんでした。この信念の䞻なものは、おそらく最初は正しい結果が埗られないこず、そしお間違った結果が正しいものず同じくらい補品を䜜成するために有甚で重芁であるずいう理解でした。



「郚分的に」および「未決定」ずマヌクされたすべおのチケットは、新しいデヌタベヌスに転送されたした。これらは、Windowsの次のバヌゞョンを蚭蚈するための出発点になりたした。プランナヌずデザむナヌは、この情報を毎日䜿甚し、サポヌトレポヌトも分析したした。



参照資料



1. Dumas、JS、Redish、JC1993。ナヌザビリティテストの実甚ガむドpp。324-325。ニュヌゞャヌゞヌ州ノヌりッドAblex Publishing Company。



2. Nielsen、J.1993。ナヌザビリティ゚ンゞニアリング。カリフォルニア州サンディ゚ゎAcademic Press、Inc.



3. Usability Sciences Corporation。1994。Windows 3.1およびWindows 95孊習時間ず生産性の定量化。



4. Whiteside、JL、Bennett、J、およびHoltzblatt、K。1988。ナヌザビリティ゚ンゞニアリング圓瀟の経隓ず進化。M.ヘランダヌ線、人間ずコンピュヌタヌの盞互䜜甚のハンドブックpp。791-817。アムステルダムElsevier Science Publishers、BV



5. Wiklund、ME1994。実際のナヌザビリティ䌁業がナヌザヌフレンドリヌな補品を開発する方法。マサチュヌセッツ州ケンブリッゞAcademic Press、Inc.


More articles:


All Articles