http://gongdosoft.com/392
effectiveui사의 CEO인 Anthony Franco가 발표한 10 Ways To Ensure RIA Failure 요약본이에요. 물론 야매TM 영어로 들은거라 엄청나게 오해한 내용도 있을테니 비디오를 직접 보시길…^^;; videos.visitmix.com/MIX09/c06f
시작 할 때 나오는 인상적인 도표.
UX를 말할 때 항상 나오는 "사용자". 하지만 좋은 사용자 경험을 제공하는 애플리케이션을 개발 하는 것은 결코 쉽지 않은 일이죠.
앤써니는 RIA를 개발 할 때 실패하고 싶다면 다음과 같이 하라고 역설하고 있어요. 노파심에서 얘기하지만 다시 말해, 아래에서 굵고 크게 붉은 글씨로 표시한 표제들을 하지 말라는 거에요^^ 물론 그 외의 굵은 글씨는 중요한 것을 의미하고요;
1. 최종 사용자를 고려하지 말 것.
DO NOT UNDERSTAND THE END USER
70%에 가까운 IT 프로젝트가 실패하는 이유는 실제 사용자가 받아들이지 않았기 때문이라는군요. 그러면서 예를 든 유명한 사례는 미국의 최초의 MP3P인 Diamond Rio인데요, Apple의 아이팟에 비해 모든 스펙이 앞서 있었을 뿐만 아니라 2년 동안이나 시장을 장악하고 있었지만 결국 지독하게 나쁜 사용성때문에 아이팟에세 떠밀리고 말았다고 해요.
결론으로 소프트웨어 개발의 새로운 황금률을 제시하는군요.
최종 사용자에게 강하게 집중하라!
2. 개발자들이 좋은 디자인 결정을 내릴거라고 믿을 것.
TRUST DEVELOPERS TO MAKE GOOD DESIGN DECISIONS
개발자들에게 UI를 맡겼을 때 나오는 결과. 왜 이런 결과가 나오냐에 대해 다음과 같이 정리하네요.
개발자들은 정말 좋지 않은 결정을 조장한다
디자이너를 믿어라
3. 기적같은 아이디어의 디자인을 기대하라.
HOPE FOR A SILVER BULLET DESIGN
때로는 엄청난 아이디어가 중요하기도 하고 작은 변화가 큰 결과를 만들기도 하지만 기본적으로는 '효과'가 아닌 '내용'에게 집중하라는거죠. 정리하자면,
사용자를 믿어라
4. 모두를 위한 애플리케이션을 만들어라.
BUILD FOR EVERYONE
"모두를 위해 만든다면 아무에게도 필요없게 된다."
왜 아이폰 사례를 소개하는지 잘 못들었지만(=_=), 제목이 "iPhone의 저주"네요. 여기에서 왜 아이폰을 디자인의 사례로 생각하면 안되는지를 설명하는데요,
어쨌든 다음과 같이 결론을 내리는데요,
다음의 사항에 노력을 집중하라
5. 런칭하고 잊어버려라.
LAUNCH & FORGET
뭐어… 런칭하고 나서도 꾸준히 사용자의 행동을 측정하고 분석하고 그런 피드백을 바탕으로 향상시킬 수 있게 하라는거죠.
6. 성공을 정의하지 말라.
DO NOT DEFINE SUCCESS
성공을 정의하려면, 기능이 아니라 이득benefit에 대해 토론하라
성공은 충돌을 수반한다, 적당한 균형을 찾아라
7. 모든 충돌을 피하라.
AVOID ALL CONFLICT
"충돌없는 진행는 없다"
"모든 사람이 동의한다면 프로젝트에 문제가 있다는 신호이다"
8. 아이디어까지 팔 필요는 없다고 믿어라.
BELIEVE YOU SHOULDN’T HAVE TO SELL YOUR IDEAS
아이디어를 팔기 위해서:
9. 완벽한 계획을 세워라.
PLAN FOR PERFECTION
심지어 길을 찾는 것도 많은 변수가 있고 변경이 있으니 개발은 어떻겠느냐는 거죠. 뭐 많이 얘기되었던 사항이죠.
10. 제품보다 프로세스에 가치를 두라.
VALUE PROCESS OVER THE PRODUCT
엄청나게 많은 프로세스 다이어그램이 있지만 어떤 것도 실제 프로젝트와 일치하지 않는다는군요. 제 아무리 좋은 프로세스와 방법론으로 '제 시간에' 개발 했을지라도 제품이 엉망이면 아무 의미가 없다고 정리하네요.
우리가 '아이디어'를 스케줄에 포함 할 수 있다면 좋겠지만 좋은 아이디어는 절대로 스케줄을 잡는다고 나오는게 아니죠. 소프트웨어 프로젝트는 건설 프로젝트와는 달리 완벽하게 설계하거나 예측할 수 없죠.
사람들은 전혀 기대하지 못한 상황에서 문제를 해결하는 경우가 많다고 해요.
뭐 그 뒤로는 회사 자랑이 조금 이어지고요^^
암튼, 몇몇은 이제 꽤나 잘 알려진 사항이지만 한번 쯤 들어볼만해요. 시간도 40분정도 밖에 안되니까요.
effectiveui사의 CEO인 Anthony Franco가 발표한 10 Ways To Ensure RIA Failure 요약본이에요. 물론 야매TM 영어로 들은거라 엄청나게 오해한 내용도 있을테니 비디오를 직접 보시길…^^;; videos.visitmix.com/MIX09/c06f
시작 할 때 나오는 인상적인 도표.
UX를 말할 때 항상 나오는 "사용자". 하지만 좋은 사용자 경험을 제공하는 애플리케이션을 개발 하는 것은 결코 쉽지 않은 일이죠.
앤써니는 RIA를 개발 할 때 실패하고 싶다면 다음과 같이 하라고 역설하고 있어요. 노파심에서 얘기하지만 다시 말해, 아래에서 굵고 크게 붉은 글씨로 표시한 표제들을 하지 말라는 거에요^^ 물론 그 외의 굵은 글씨는 중요한 것을 의미하고요;
1. 최종 사용자를 고려하지 말 것.
DO NOT UNDERSTAND THE END USER
70%에 가까운 IT 프로젝트가 실패하는 이유는 실제 사용자가 받아들이지 않았기 때문이라는군요. 그러면서 예를 든 유명한 사례는 미국의 최초의 MP3P인 Diamond Rio인데요, Apple의 아이팟에 비해 모든 스펙이 앞서 있었을 뿐만 아니라 2년 동안이나 시장을 장악하고 있었지만 결국 지독하게 나쁜 사용성때문에 아이팟에세 떠밀리고 말았다고 해요.
결론으로 소프트웨어 개발의 새로운 황금률을 제시하는군요.
최종 사용자에게 강하게 집중하라!
- 다른 모든 규칙은 부차적일 뿐이다
- 다른 모든 실패는 절대적으로 이 조언을 무시했을 때 돌아오는 결과이다
2. 개발자들이 좋은 디자인 결정을 내릴거라고 믿을 것.
TRUST DEVELOPERS TO MAKE GOOD DESIGN DECISIONS
개발자들에게 UI를 맡겼을 때 나오는 결과. 왜 이런 결과가 나오냐에 대해 다음과 같이 정리하네요.
개발자들은 정말 좋지 않은 결정을 조장한다
- 개발자들의 결과물은 프로젝트 계획이나 기능이나 일정에 기반한다
- 개발자들은 데드라인에 맞출 수 없게 되면 최종 사용자가 진짜로 바라는 것에 집중하기 보다는 기능 구현에 전력을 다한다
디자이너를 믿어라
- 사용자는 애플리케이션이 Silverlight, AJAX, Flash, .Net… 어떤 것이든지 상관하지 않는다
- 정치나 사조직이 끼어들도록 하지 말라
- 기술적인 과제를 놓고 허심탄회하게 디자이너와 얘기하고 알려라, 그러면 디자이너는 싸우는게 아니라 함께 일하게 될 것이다
- 좋은 디자이너는 최종 사용자와 그들의 요구를 뭔가 쓸만한 것으로 옮기는 데 도움을 줄 것이다
- 의심이 들면 사용자에게 물어보라
3. 기적같은 아이디어의 디자인을 기대하라.
HOPE FOR A SILVER BULLET DESIGN
때로는 엄청난 아이디어가 중요하기도 하고 작은 변화가 큰 결과를 만들기도 하지만 기본적으로는 '효과'가 아닌 '내용'에게 집중하라는거죠. 정리하자면,
사용자를 믿어라
- 공감이란 단어를 새겨놓고 사용자와 대화하여 행동하라
- 사용자의 피드백을 바탕으로 자발적으로 아이디어를 내놓아라
- 포트폴리오에 신경쓰지 말라
- 만약 사용자가 UI에 신경쓴다면 분명히 실패할 것이다
4. 모두를 위한 애플리케이션을 만들어라.
BUILD FOR EVERYONE
"모두를 위해 만든다면 아무에게도 필요없게 된다."
왜 아이폰 사례를 소개하는지 잘 못들었지만(=_=), 제목이 "iPhone의 저주"네요. 여기에서 왜 아이폰을 디자인의 사례로 생각하면 안되는지를 설명하는데요,
- 애플은 엄청난 비용을 디자인에 쏟아 붓는다
- 모든 컨트롤들이 과도하게 통합되어 있다
- 사용하기 어렵다 ? 직관적이지 않다
- 익숙하게 하기 위해 마케팅에 비용을 쏟아 붓는다
어쨌든 다음과 같이 결론을 내리는데요,
다음의 사항에 노력을 집중하라
- 사용자가 공감할 수 있게
- 하나의 프로젝트에 최대 3개의 페르소나Persona만 정의하고 그들에게 강력하게 집중하라
5. 런칭하고 잊어버려라.
LAUNCH & FORGET
뭐어… 런칭하고 나서도 꾸준히 사용자의 행동을 측정하고 분석하고 그런 피드백을 바탕으로 향상시킬 수 있게 하라는거죠.
6. 성공을 정의하지 말라.
DO NOT DEFINE SUCCESS
성공을 정의하려면, 기능이 아니라 이득benefit에 대해 토론하라
- 질적인 이득
- 고객이 빠른 업무 처리를 인지한다
- 고객이 이 소프트웨어를 친구에게 추천한다
- 브랜드 일관적이고 신뢰할 수 있는 경험이 되어야 한다
- 양적인 이득
- 배송을 추적하는데 드는 시간이 20% 감소한다
- 선결제가 50% 증가한다
- 고객 서비스 전화가 50% 감소한다
성공은 충돌을 수반한다, 적당한 균형을 찾아라
7. 모든 충돌을 피하라.
AVOID ALL CONFLICT
"충돌없는 진행는 없다"
"모든 사람이 동의한다면 프로젝트에 문제가 있다는 신호이다"
8. 아이디어까지 팔 필요는 없다고 믿어라.
BELIEVE YOU SHOULDN’T HAVE TO SELL YOUR IDEAS
아이디어를 팔기 위해서:
- 프로젝트에 연관된 개인들을 이해하고 그들이 반대 의견과 걱정을 가져오기 전에 먼저 말하라
- 고객의 의견을 듣고 당신의 의견이 그들과 일치한다는 것을 확신시켜라, 그리고 다른 고객들의 말을 빌어 말하라("전에 우리의 고객들이 얘기해준 것과 같네요…")
- 겸손하지만 정렬적으로 아이디어를 말하라
- 공격적으로 팔라
9. 완벽한 계획을 세워라.
PLAN FOR PERFECTION
심지어 길을 찾는 것도 많은 변수가 있고 변경이 있으니 개발은 어떻겠느냐는 거죠. 뭐 많이 얘기되었던 사항이죠.
10. 제품보다 프로세스에 가치를 두라.
VALUE PROCESS OVER THE PRODUCT
엄청나게 많은 프로세스 다이어그램이 있지만 어떤 것도 실제 프로젝트와 일치하지 않는다는군요. 제 아무리 좋은 프로세스와 방법론으로 '제 시간에' 개발 했을지라도 제품이 엉망이면 아무 의미가 없다고 정리하네요.
우리가 '아이디어'를 스케줄에 포함 할 수 있다면 좋겠지만 좋은 아이디어는 절대로 스케줄을 잡는다고 나오는게 아니죠. 소프트웨어 프로젝트는 건설 프로젝트와는 달리 완벽하게 설계하거나 예측할 수 없죠.
사람들은 전혀 기대하지 못한 상황에서 문제를 해결하는 경우가 많다고 해요.
뭐 그 뒤로는 회사 자랑이 조금 이어지고요^^
암튼, 몇몇은 이제 꽤나 잘 알려진 사항이지만 한번 쯤 들어볼만해요. 시간도 40분정도 밖에 안되니까요.
