NOKIA의 새 제품들이 발표되는 시간이 얼마 남지 않았다.
기대기대...

아이리버에서 WiFi를 탑재한 모델을 출시하였다.
멀티미디어 기능이야 기본일꺼고, 가장 눈길을 끄는 기능은 인터넷 폰.
(해외 사이트에 Cell Phone으로 나와서 기대를 많이 했었는데 아쉽게도(?) 인터넷 폰이었다)

과연 사람들이 휴대폰 기능을 좋아할까?

인터넷 폰이 가지고 있는 단점은 여러가지이다.
- 전화걸때 장소의 제약을 받는다 (시티폰과 차이가 별로 없다)
- 전화 걸기, 문자 보내기만 가능하다.
- 휴대폰에 저장된 수백개의 전화번호를 이용할 수 없다
- 휴대폰으로 문자메시지를 받은 후 "답장하기"를 눌러서 바로 답장하기가 어렵다
- 휴대폰에 기록된 부재중통화 목록에서 바로 통화를 눌러 회신할 수 없다
- 나 뿐 아니라 상대방도 불편하다 (내가 전화를 걸었을 때 상대방 화면에 나타나는 CID가 내 휴대폰 번호가 아니라면)

이에 대한 보상으로 내세우는 것이 결국 저렴한 가격인데
휴대폰으로 전화를 걸 경우에 10초에 13원, 문자는 건당 15원이면
과연 사용자들이 불편함을 감수할 만큼의 benefit이 있는지는 의문이다.

WiFi를 탑재하여 추가로 지원하는 기능이 인터넷 전화만 있다는 것도 아쉽다.
사용자의 needs는 전화보다는 인터넷 풀 브라우징이 아닐까?
Wave의 가격이 얼마가 될지는 모르겠지만, WiFi 기능에 대한 추가 가격 부담 의향이 크지는 않을 듯 하다.

마지막 한가지. 아래에 있는 조이키가 통화할때 걸리적 거리지는 않을까?

UE 디자인을 하면서 어떤 자질을 갖추어야 하는지에 대한 좋은 insight를 알려주는  좋은 글.
나는 몇점짜리 UE 디자이너일까?

-------------------------------------------------

The Five Competencies of User Experience Design

By Steve Psomas

Published: November 5, 2007

Throughout my career as a user experience designer, I have continually asked myself three questions:

• What should my deliverables be?
• Will my deliverables provide clarity to me and their audience?
• Where do my deliverables and other efforts fit within the spectrum of UX design?

I have found that, if I do not answer these questions prior to creating a deliverable, my churn rate increases and deadlines slip.

When attempting to answer the third question, I use a framework I discovered early in my career: The Five Competencies of User Experience Design. This framework comprises the competencies a UX professional or team requires. The following sections describe these five competencies, outline some questions each competency must answer, and show the groundwork and deliverables for which each competency is responsible.

Information Architecture

When wearing the information architect hat, your job is designing a user interface (UI) structure that satisfies the corporate business strategy, product strategy, and user experience strategy and accommodates all use cases and product requirements. Information architecture addresses questions such as:

• What are users’ primary goals, and how can they achieve them using the application?
• How do users get from place to place?
• What rules exist that users have to work around?
• How are product features and components branded?
• What is the optimal scope of the application’s feature set?
• How do the UI roadmap and product roadmap position the application in its vertical market?
• How should I enable users to create and store multiple objects?
• What is the application’s search mechanism?

Through laying the groundwork and producing the deliverables shown in the sidebar, information architecture provides the foundation for the other competencies.

Interaction Design

With increasing pressure to create rich user experiences, the interaction designer bears the greatest load and is responsible for conceptual design, which requires exposure to the latest UI patterns and components. In laying the groundwork for and producing the deliverables listed in the sidebar, the interaction designer dives deepest into the minutia of page elements, presentation, and page flow.

Questions the interaction designer must address include:

• What layout pattern would work best?
• Which features and information are of higher importance, and how do I draw users’ attention to them?
• How should I incorporate the user feedback I am getting from user research, user surveys, and formative and summative usability testing?
• What behaviors occur on dragging and dropping, on mouse over, and so on?
• How can I communicate the strengths of a feature or application?
• How can I satisfy users’ primary needs and support the tasks that let them achieve their goals?
• How can I draw on users’ intuition to get them to the next step?
• How can I ensure users are aware they’re performing a subtask that’s part of a greater task they’ve started?
• How can I use the UI components that are available to me—such as grids, tabs, and panels?
• How can I maintain consistency throughout the application?

The emergence of rich application experiences has increased the workload for interaction designers. What, in a traditional Web design process, we once specified as page-by-page state changes, we now achieve through a UI-component-by-UI component, multi-state specification often expressed as a matrix. At present, no single methodology that efficiently enables the documenting of rich application designs has emerged as the standard in the UX design community.

On the plus side, the focus of specifications has shifted. Remember when interaction designers had to specify a UI component, then give the specification to the engineers to go build it? Now designers can just pick a pre-built component that the engineers can configure.

Usability Engineering

At my company, I am the sole user experience designer, and I have observed that, when shifting into usability engineering, it is beneficial to completely remove myself from the other four competencies, for three reasons:

• Doing so immediately places me in the mindset of the user.
• It favorably affects my ability to maintain neutrality when conducting usability tests.
• It gives me perspective on design churn.

Shifting into a user mindset helps me both when laying the groundwork for usability testing and when creating the pre-test and post-test deliverables shown in the sidebar. It is essential when conducting usability test sessions, evaluating the findings of a usability test, and making design recommendations.

I’ve also observed that the moment my usability engineering hat comes off, I dive right into another design iteration, fueled by the abundance of newly gathered knowledge about usage patterns.

Visual Design

Visual design communicates your brand. That’s why everyone has an opinion about it. But it also communicates interactivity, information structures, workflows, and relationships between the elements and components on a screen, making it an essential aspect of UX design for applications—whether for the desktop, the Web, or mobile devices.

What people often overlook is that, for every type of user interface element the interaction designer specifies, the visual designer must design a widget or devise a corresponding style. And the visual designer must consistently apply these styles to every instance of each element throughout the application.

However, in this era of rich application frameworks, if the interaction designer has selected page elements from a reasonably stylish UI component library, the visual designer can concentrate more on branding and navigation.

Prototype Engineering

Prior to the advent of rich user experiences, it was unusual for an engineer—a coder—to be part of a UX team. In fact, product development and product management might have resisted an engineer’s working on the UX team, considering engineering and design mutually exclusive. But with new rich UI component libraries emerging weekly, and the separation of the UI, or presentation, layer from the application logic and database layers in the code, both UX and engineering see having a prototyper on the UX team as advantageous to the overall product team.

Ideally, an interaction designer and prototype engineer work closely together to deliver prototypes of concept models for testing by the usability engineer. The findings of usability test sessions determine the designer’s next course of action—either iterate the design of the feature based on test results or move on to the next feature.

Prototyping offers a huge opportunity for increasing process efficiency. When done well, it can alleviate uncertainty about design intentions, clarify functionality, and reduce the need for documentation. It also provides a working, though perhaps limited, representation of the application, so everyone on the product team can evaluate what’s working well in the user interface and where gaps or issues still exist.

Why Are These Five Competencies Important?

For a UX team, these five competencies can provide clarity about the domain of each team member. And if you, like me, are the only UX designer in your organization, they may be even more important. The following sections describe some ways you can put this UX design framework to use.

Framing Your Strengths and Weaknesses

You can use this framework to evaluate your strengths and weaknesses as a UX professional and figure out where you can provide the most value on a UX team.

For example, on a scale of 1-7, I’m pretty good at information architecture and usability engineering, so I’d rate both of these skills a 6. I’m about a 5 at interaction design, but we’re all still learning a tremendous amount about interaction design these days. I’m better than average at visual design, but don’t have formal training in it, so I’m about a 4. And I consider myself an expert at HTML/CSS and was once pretty good at JavaScript, but now I need higher-fidelity prototyping, so I’d put myself at a 4 as a prototype engineer. So, my greatest strengths are information architecture, usability testing, and interaction design.

How about you?

Characterizing and Prioritizing Your Workload

What exactly do others on your product team need from you? A mockup? A wireframe? An image? A spreadsheet? Each of these deliverables requires you to put one of these five UX hats on. When I know ahead of time what creating a deliverable requires, in terms of my analytical and creative effort, I can either devote myself fully to the task or, if necessary, change the task priority.

Scoping the Deliverables for Projects

Scoping is about letting others on your team know how long it might take for you to produce a deliverable. If you’ve defined a task well, you already have a good sense of how much effort and time it will take. For instance, if I am asked to wireframe a new feature, I know I’ll have to do some discovery first, which will require extra time. If my task is skinning a user interface module, as you saw from my strengths and weaknesses, I can do the visual design, but it might take me a bit longer to get it right than it would a visual design expert.

Establishing Dependencies

In completing an interaction design task, my decisions are usually rooted in some information architecture work I’ve already done. Or did I? If I didn’t, I’ll need to go back and do it. Likewise, when you’re going to take the time to prototype something, you want to be pretty sure about the interaction design first.

Hiring Resources

Knowing your team’s strengths and weaknesses as well as your design needs, where would it make sense to bring on a new hire? It wouldn’t hurt to have candidates rate themselves on the five competencies so you can assess how a candidate fits your needs.

Regaining Perspective

If you, like me, are deep into making design decisions day after day, you might at times become disoriented and need to realign your thinking about the appropriateness and purpose of the task at hand. It’s important that we come up for air once in a while, not only in the midst of creating our deliverables, but also when managing our time and our team’s expectations.

Our industry is at a crossroads, scrambling to adjust to the demand for richness in Web applications. Design principles, processes, tools, and resources are changing, too. So, now we need to clarify the value of UX design and the competencies it offers to the greater product development process.

1. UI, GUI 관련 전체 문서 구성 방법
- 기본적으로 문서별 Audience를 명확하게 정의하고 그에 맞추어 문서 구성 (최대한 내용 중복 없애도록)
- UI 기능정의 문서 (플립북)
- GUI 가이드 문서
- 외부에서 Application을 개발하는 업체가 따라야 하는 UI/GUI Guide (현재의 UISM) 문서는 플립북과 별도로 작성 및 배포
- 운영 가이드 문서 별도 분리
- 상품 설명, 요금 정책 설명, 상품 출시 일정 등은 해당 부서에서 별도의 문서로 관리되어야 함

2. 플립북 (UI 기능정의서)
- 기능 이해가 필요한 내부 관계자 및 SW, GUI 개발 담당자가 봐야하는 문서임. 개발 위주가 아닌 기능 설명 위주로 문서 작성되어야 함 (어떻게 동작이 되는것인지?)
- 공통 interaction guide는 자세하게 별도 문서로 구성
- icod와 dnp 문서 분리 여부 검토 필요
- 기능별로 문서 분리 여부 검토 필요함 (예, 채널 문서 / VOD 문서 / 설정 문서 등)
- 용어 및 서비스 설명은 별도 section으로 관리
- 기능에 대한 Flow 기술 방안 고민 필요
- 문서 Format 검토 필요 (Word? Power Point?)
- UI 디자인시 의사결정 과정 및 이력 관리 방안 고민 필요

3. 플립북 운영 방안
- 최초 UI 설계에 대하여 기술 제약으로 구현이 안되는 항목은 최초 UI 설계 내용을 유지하고 기술적 문제를 Comment 하는 방향으로 운영 (최초의 idea 및 좋은 design에 대한 이력이 없어지면 안됨)
- 업체 의뢰할 때 technical writer가 문서 작성하도록 요청
- UI 설계 수정시 내부 공유 및 문서 Update, 외부 Release 방안

아이들이 음식을 오래오래 씹게 하여 비만을 막기 위하여 개발된 제품이라고 한다.
1000번 씹으면 선물로 한번씩 링도 울려주고...

이런 연구 결과에서 출발한 아이디어 상품일 것 같기는 한데...
http://news.bbc.co.uk/2/hi/health/7681458.stm

암튼 일본애들 별걸 다 만든다 -.-

TV를 통하여 도미노 피자를 주문할 수 있다면 좋을까?

피자 주문하려고 전단지를 찾아 헤메거나
전화로 주문을 하면서도 어떻게 생겼는지는 몰라서 이것저것 물어보는 일은 줄어들 것 같다.
(물론 얻어먹을 때는 생긴것 상관 없이 "가장 비싼거 주세요" 할 수 있겠지만)

TV로 문자 입력도 가능하니까 "갈릭소스를 가져오지 않으면 문을 열어주지 않을테다"와 같은 추가 요청 사항도 입력이 가능할 것이다.

관건은 인터넷 주문보다 더 쉽고 편해야 한다는 것일 듯...

디지털 액자를 사용하는 사람들이 겪게되는 고민들 중 한가지가
이전에 보관하고 있던 종이 사진들을 어떻게 액자에 넣을 수 있을까 하는 것일텐데
그에 대한 사용자 Needs를 잘 만족시켜주는 제품이다.

그런데 생각을 해 보면
디지털화가 되면서 파일을 프린트 해 주는 서비스들은 흔히 볼 수 있어도
이전보다 주변에서 스캐너를 찾기는 점점 어려워지는 것 같다. (나만그런가?)
디지털 기기가 흔해지면서도 이런 edge가 생기게 되는 것 같다.

User Centered Design에서 사용자를 관찰하고 사용자의 생각을 파악하는 것은 매우 중요하며 사용자를 관찰, 조사하고 이를 분석하기 위한 많은 방법론들이 나와있다. 그러나 적절한 방법론으로 조사를 잘 수행하고, 이를 잘 분석한 경우에도 결국 좋은 디자인으로 만들어 내기는 매우 어려운 일이다. 이 과정은 디자이너의 직관에 달려있는 문제인가?

Elito라는 방법론에서는 이 문제를 결국 Analysis와 Synthesis 사이의 Gap에 의한 문제로 정의를 한다.
http://trex.id.iit.edu/ideas/elito/0Overview.html

 

위의 그림과 같이 Research - Analysis - Synthesis - Realization으로 구성된 디자인 프로세스에서 Analysis와 Synthesis는 Understand와 Create로 구분되며 이 사이를 연결시켜주는 방법론을 Elito라는 방법론으로 제안을 하고 있다.

 

이는 관찰의 결과를 Key Metaphor - Observation - Judgement - Value - Concept - Sketch 의 과정으로 연결 시킴으로서 Analysis와 Synthesis 간의 Gap을 줄일 수 있다고 주장하는 것이다.

지금까지 사용자 조사를 하면서도 단순한 직관에 의하여 조사, 분석, 디자인을 진행해 왔기 때문에 사용자 관찰의 결과를 디자인으로 연결하기 위한 구조화되거나 체계화된 방법론이 필요하다는 것에 대해서는 크게 공감을 하고, 사용자의 조사 결과를 통합하기 위하여 여러개의 단위로 쪼개고 다시 합하는 분석적이고 체계적인 과정이 필요하다는 생각이 든다. 

관찰 결과를 디자인으로 표현하는 것에 대한 해결책을 알려준 방법론은 아니지만 나의 궁금증이 무엇일까는 궁금증에 대한 답을 약간을 줄 수 있는 주제인 것 같다. 결국 숙제만 늘어난 것인가? ㅎㅎㅎ