사용자 인터페이스 디자인Designing a User Interface

이 섹션에서는 Windows 응용 프로그램에 대 한 UI 디자인과 관련 된 몇 가지 작업에 대해 자세히 설명 합니다.This section describes in detail some of the tasks associated with designing a UI for a Windows application.

소개Introduction

UI 디자인은 기능, 미관 및 성능의 세 가지 필수 요소로 나눌 수 있습니다.UI design can be divided into three essential elements : functionality, aesthetics, and performance.

이러한 경우가 아니면 응용 프로그램 개발 중에 주요 초점은 기능입니다.More often than not, the primary focus during application development is functionality. 응용 프로그램을 사용할 수 있나요?Is the application usable? 사용자가 작업을 완료할 수 있게 하나요?Does it enable users to complete tasks? 그러나 기능은 스토리의 일부일 뿐입니다.However, functionality is only a part of the story.

미관 사용자에 게 전달 되는 스타일을 설명 하 고 표시 되는 방법을 설명 합니다.Aesthetics describe how things are shown and presented, the style in which things are communicated to the user. 미관는 기능 요구 사항 및 성능 메트릭에 비해 매우 주관적이 고 수량화 하기가 훨씬 더 어렵습니다.Aesthetics are very subjective and much more difficult to quantify than functional requirements and performance metrics. 일반적으로 미관는 일반적으로 색을 보완 하는 방법 또는 UI 요소에서 의미를 전달 하는 방법에 대해 자세히 설명 합니다 .이는 일반적으로 사용자가 무언가를 결정 하 고 사용 하는 방법에 영향을 줍니다.Aesthetics typically come down to simple choices—how colors complement each other or how UI elements convey their meaning—that often affect the way a person feels about something and influence how successful they are using it.

성능은 속도 뿐만 아니라 안정성도 측정 합니다.Performance is measured by not only speed, but also reliability. 응용 프로그램의 모양과 느낌이 매우 좋은 경우, 사용 하기 쉬우며 반복적으로 충돌 하는 경우에는 매우 성공할 가능성이 높습니다.If an application looks and feels great, is easy to use, but crashes repeatedly, it likely won't be very successful. 응용 프로그램은 안정성을 완벽 하 게 신뢰 하는 사용자를 제공 해야 합니다.The application has to provide a user with full confidence in its reliability.

다음은 Windows 응용 프로그램에 대 한 성공적인 UI에 기여할 수 있는 몇 가지 디자인 단계 작업입니다.The following are some design phase tasks that can contribute to a successful UI for a Windows application.

기능 요구 사항Functional Requirements

최대한 광범위 한 대상에 대해 사용자 환경을 최적화 하려면 디자인 단계의 초기에 다음 제안을 고려 하십시오.Consider the following suggestions early in the design phase to optimize the user experience across the broadest audience possible:

  • UI 디자인 지침을 따릅니다.Follow UI design guidelines.

    Windows 사용자 환경 상호 작용 지침 을 숙지 하 고 응용 프로그램 UI의 디자인, 구현 및 테스트가 진행 되는 동안 자주이를 참조 합니다.Become familiar with the Windows User Experience Interaction Guidelines and refer to them often as the design, implementation, and testing of the application UI progresses.

  • UI에 액세스할 수 있는지 확인 합니다.Ensure that the UI is accessible.

    제품 수명 주기의 시작 부분에서 UI 디자인에 접근성을 통합 해야 합니다.Be sure to integrate accessibility into the UI design from the beginning of the product lifecycle. 액세스 가능성 개발의 일부에는 아키텍처 수준에서 주의가 필요 하므로 수정 따라 접근성은 매우 비용이 많이 들 수 있습니다.Retrofitting accessibility can be extremely costly because part of accessibility development requires attention at the architectural level. 자세한 내용은 내게 필요한 옵션 전자책 엔지니어링 소프트웨어를 다운로드 하세요.For more information, download the Engineering Software for Accessibility eBook.

  • 국제 marketplace를 지원 합니다.Support the international marketplace.

    Windows에는 Windows 응용 프로그램에서 많은 문화권 및 작성 된 언어를 지원할 수 있는 기술이 포함 되어 있습니다.Windows includes technologies that enable support for many cultures and written languages in a Windows application. 응용 프로그램이 국제 marketplace를 대상으로 하는 경우 프로젝트 시작부터 UI 디자인에 국제화 지원을 포함 하는 것이 중요 합니다.If the application is targeting the international marketplace, it is important to include internationalization support in the UI design from the beginning of the project. 자세한 내용은 Windows 응용 프로그램용 국제화를 참조 하세요.For more information, see Internationalization for Windows Applications.

사용자 분석User Analysis

성공적인 인터페이스를 디자인 하는 중요 한 단계는 코드를 작성 하기 전에 사용자가 응용 프로그램에서 필요로 하는 작업과 필요한 항목에 대 한 기본적인 이해를 실현 하는 것입니다.A critical step in designing a successful interface is attaining a basic understanding of what users need and want from an application before writing any code. 응용 프로그램의 잠재적인 사용자는 이미 특정 한 방식으로 작업을 수행 하 고 있으며 기존 도구 및 프로세스를 최대한 완벽 하 게 이해 해야 합니다.Remember, potential users of an application are already doing their job in some way and existing tools and processes should be understood as fully as possible. 이러한 문제를 완전히 고려 하지 않고 설계 하지 마십시오.Do not design without fully considering these issues.

가장 간단 하 고 간단한 방법은 제품의 의도 된 사용자와 통신 하는 것입니다.The simplest and most informal approach is talking to the intended users of the product. 원본에서 직접 정보 가져오기-관리자 또는 임원을 실제 소비자에 대 한 프록시로 사용 하지 않습니다.Get information directly from the source–avoid using managers or executives as proxies for actual consumers. 소규모의 개발자와 프로그램 관리자가 자신의 작업 영역 등에에서 사용자에 게 비공식적 방문을 지불 하는 것이 좋습니다. 이러한 사용자는 자신의 작업 방식에 대해 논의 하 고 현재 도구로 직면 하는 문제에 대 한 세부 정보를 수집 하는 기회가 있습니다.Consider having small groups of developers and program managers pay informal visits to users in their workplaces where there is an opportunity to discuss how they work and gather details of the issues they face with their current tools.

사용자 의견의 품질 및 유효성에 직접적인 영향을 주므로 앞으로 나 바이어스 된 질문을 요청 하지 마세요.Remember, do not to ask leading or biased questions as this will directly affect the quality and validity of the user feedback. 이 단계에서 질문을 작성할 때 다음 사항에 유의 하세요.Keep the following in mind when composing questions during this phase:

  • 사용자는 누구 인가요?Who are our users? 제공 되는 기술 및 지식은 무엇 인가요?What skills and knowledge do they have?
  • 경험을 이해 하는 데 사용할 수 있는 데이터 원본은 무엇 인가요?What different sources of data can we use to understand their experience?
  • 제품을 사용 하 여 완료 해야 하는 목표 및 작업은 무엇 인가요?What goals and tasks will they use our product to complete?
  • 어떤 가정을 하 고 어떻게 확인할 수 있나요?What assumptions are we making and how can we verify them?
  • 어떤 데이터 원본이 있나요?What sources of data do we have? (유용성 연구 및 추론 평가를 시작 하는 것이 좋습니다.)(Usability studies and heuristic evaluations are good places to start.)

문제 문Problem Statements

모든 사용자 피드백이 수집 되 면이를 분석 하 고 관련 문제 및 요구 사항으로 변환 합니다.Once all user feedback has been collected, analyze and distill it into related issues and requirements. 이 시점에서 솔루션에 대 한 생각을 방지 해 보세요.Try to avoid thinking about solutions at this point. 증상 뿐만 아니라 문제가 완전히 식별 되었는지 확인 합니다.Make sure the problems are fully identified, not just the symptoms.

각 문제 또는 요구 사항에 대해 사용자 관점에서 한 문장 문제 문 목록을 작성 하는 것이 도움이 되는 경우가 많습니다.It is often helpful to compose a list of one sentence problem statements (from the users perspective) for each issue or requirement. 예를 들어 "편집 상자 너비를 15 자로 조정" 하는 것은 문제가 되지 않습니다.For example, "Resize edit box width to 15 characters" is not a problem. 그러나 "긴 검색 용어를 입력 하기는 너무 어렵습니다"은 올바른 문제 설명입니다.But "It is too difficult to type in long search terms" is a valid problem statement. 차이는 극적입니다.The difference is dramatic. 솔루션과 문제를 동시에 정의 하지 마십시오. 일반적으로 실제 문제가 손실 됩니다.Try not to define the solution and the problem at the same time: often the real problem is lost. 이 예에서는 편집 상자의 크기를 변경 하는 등 검색 용어의 문제를 해결 하는 다른 여러 가지 방법이 있을 수 있습니다.In this example, there may be many other ways to solve the problem of search terms, including changing the size of the edit box. 대체 솔루션은 항상 염두에 두어야 합니다.Always keep alternative solutions in mind.

다음은 문제 문의 추가 예입니다.The following are additional examples of problem statements:

  • 웹 사이트의 한 섹션에서 다른 섹션으로 이동 하는 것은 어렵습니다.It is difficult to navigate from one section of the Web site to another.
  • 사용자가 소프트웨어를 로드 하는 데 너무 오래 기다려야 합니다.Users have to wait too long for the software to load.
  • 보안 오류 메시지를 이해 하기 어렵습니다.Our security error messages are difficult to understand.
  • 등록 페이지에 너무 많은 질문이 있어 사용자가 중단 하는 경우가 많습니다.The registration page has too many questions, and users often abandon it.
  • 사이트 인덱스에서 특정 제품을 찾기가 너무 어려울 수 있습니다.Finding a specific product on the site index is too hard to complete.

문제 설명이 매우 광범위 한 경우 많은 혁신 및 독창적인 방법으로 해결할 수 있습니다.If the problem statements are broad enough, there are likely to be many innovative and creative ways to solve them.

우선 순위Priorities

항목 목록을 가져오고 우선 순위별로 순위를 지정 하는 작업은 릴리스를 정의 합니다.The act of taking a list of items, and ranking them by priority, defines a release. 우선 순위가 없는 경우 팀은 어떤 작업을 수행 해야 하는지 그리고 어떤 작업을 수행 해야 하는지에 대해 싸울 수 있습니다.Without clear priorities, teams may fight and argue over what things should be done and what things should be cut. 우선 순위 설정과 관련 된 작업은 연구 완료를 사용 하는 것이 더 쉬울 뿐만 아니라 항상 챌린지입니다.The work involved in setting priorities should be easier with the research complete, but it's always a challenge.

우선 순위를 설정 하려면 3 개 이상의 조건 (일정, 팀 및 비즈니스)을 평가 하는 기능이 필요 합니다.Setting priorities requires the ability to evaluate on at least three criteria: schedule, team, and business. 프로젝트에 대해 미리 정의 된 일정 집합이 있을 수 있으며,이를 통해 수행할 수 있는 작업의 크기와 크기를 제한할 수 있습니다.There may be a predefined schedule set for the project, which limits the size and scale of the work that can be done. 코드 베이스의 절반을 다시 작성 해야 하는 문제는 작은 릴리스 주기 동안 시도해 서는 안 됩니다.A problem that is likely to require rewriting half the code-base should not be attempted during a small release cycle.

팀의 구성을 및 특성은 수행할 수 있는 작업의 종류를 정의 합니다.The makeup and nature of a team defines what kinds of work can be done. 팀의 다른 약정은 무엇 인가요?What other commitments does the team have? 팀에 디자이너 또는 유용성 엔지니어가 있나요?Is there a designer or usability engineer on the team? 팀에서 웹 또는 UI 디자인을 사용 하는 기술은 무엇 인가요?What skills with Web or UI design does the team have? 마지막 및 가장 중요 한 것은 비즈니스 고려 사항입니다.Last, and most important, are business considerations. 이 프로젝트의 수익 목표는 어떻게 되나요?What are the revenue goals for this project? 경쟁사는 누구 인가요?Who are the competitors? 특정 문제를 해결 하는 경우의 이점은 무엇 인가요?What are the advantages of solving certain problems? 어떤 파트너를 위조 할 수 있나요?What partnerships can be forged? 목록의 우선 순위를 지정 하기 전에 다른 고려 사항도 확인 해야 합니다.Any other considerations should also be identified before prioritizing the list.

우선 순위를 지정한 후에는 문제 문의 목록이 제품의 방향을 설정 하 고 개발이 올바른 영역을 대상으로 하는지 확인 합니다.Once prioritized, the list of problem statements sets the direction for the product and ensures that development is targeted in the right areas.

개념적 디자인Conceptual Design

일반적으로 UI는 개념적 디자인 단계에서 처리 되지 않습니다.Typically, the UI is not addressed in the conceptual design phase. 그러나이 단계에서는 성공적인 사용자 환경을 위해 필수적인 전체 사용자 프로필 및 사용 시나리오가 포함 된 철저 한 비즈니스 모델이 필요 합니다.However, this phase does require a thorough business model with complete user profiles and usage scenarios which are imperative for a successful user experience.

논리적 디자인Logical Design

논리적 디자인 단계는 개념적 디자인을 지 원하는 초기 프로토타입이 개발 되는 경우입니다.The logical design phase is when the initial prototypes that support the conceptual design are developed.

개발 중에 사용할 특정 하드웨어 및 소프트웨어 기술도이 단계에서 식별 되며, 최종 제품의 UI 기능을 확인할 수 있습니다.The specific hardware and software technologies to be used during development are also identified in this phase, which can determine the capabilities of the UI in the final product. 자세한 내용은 사용자 인터페이스 기술(영문)을 참조 하세요.For more information, see User Interface Technologies.

개발 도구 외에도 응용 프로그램의 대상으로 지정할 수 있는 다양 한 하드웨어 요구 사항 및 폼 팩터를 식별 해야 합니다.In addition to the development tools, the various hardware requirements and form factors that are to be targeted by the application should be identified.

물리적 디자인Physical Design

물리적 디자인 단계는 논리적 디자인에서 식별 된 특정 하드웨어 및 폼 요소에 대해 UI 디자인을 구현 하는 방법을 결정 합니다.The physical design phase determines how a UI design is to be implemented for the specific hardware and form factors that were identified in the logical design.

이 단계를 진행 하는 동안 하드웨어 또는 폼 팩터 제한으로 인해 디자인에 상당한 구체화를 필요로 하는 UI에 대 한 예기치 않은 제약 조건이 발생할 수 있습니다.It is during this phase that hardware or form factor limitations might introduce unexpected constraints on the UI that require significant refinements to the design.