UX 디자인 프로젝트 가이드 - PDF 무료 다운로드 (2023)

UX 프로젝트 가이드

설계

현장 또는 제작 중인 사용자 경험 디자이너용

러스 웅거와 캐롤린 챈들러

피치핏 프레스

UX 디자인에 대한 프로젝트 가이드: Russ Unger 및 Carolyn Chandler를 제작하거나 현장에 있는 사용자 경험 디자이너용

New Riders 1249 Eighth Street Berkeley, CA 94710 (510) 524-2178 (510) 524-2221 (팩스) 웹사이트: www.newriders.com 오류를 보고하려면 다음 주소로 메모를 보내주십시오.[이메일 보호]New Riders는 Pearson Education의 부서인 Peachpit의 상표입니다. Russ Unger 및 Carolyn Chandler의 저작권 © 2009 인수 편집자: Michael J. Nolan 프로젝트 편집자: Becca Freed 프로덕션 편집자: Tracey Croom 개발 편집자: Linda Laflamme 복사 편집자: Leslie Tilley 교정자: Suzie Nasol 편집자: Danielle Foster 인덱서: Valerie Perry 표지 디자인: Mimi Heft 커버 제작: Andreas deDanaan 인테리어 디자인: Mimi Heft

책임 고지 이 책의 정보는 보증 없이 "있는 그대로" 배포됩니다. 책을 준비할 때 모든 예방 조치를 취했지만 저자나 Peachpit은 이 책에 포함된 지침으로 인해 직간접적으로 발생했거나 발생했다고 주장하는 손실이나 손해와 관련하여 개인이나 단체에 대해 어떠한 책임도 지지 않습니다. 또는 여기에 설명된 컴퓨터 소프트웨어 및 하드웨어 제품에 의해.

상표 제조업체 및 판매자가 제품을 구별하기 위해 사용하는 많은 지정은 상표로 주장됩니다. 이러한 지정이 이 책에 나타나고 Peachpit이 상표권 주장을 알고 있는 경우 해당 지정은 상표 소유자가 요청한 대로 나타납니다. 이 책 전체에서 확인된 다른 모든 제품 이름과 서비스는 상표권을 침해하려는 의도 없이 그러한 회사의 이익을 위해 편집 방식으로만 사용되었습니다. 그러한 사용 또는 상호 사용은 이 책과의 보증 또는 기타 제휴를 전달하기 위한 것이 아닙니다. ISBN-13 978-0-321-60737-9 ISBN-10 0-321-60737-6 987654321 미국에서 인쇄 및 제본됨

UX 디자인에 대한 프로젝트 가이드에 대한 찬사 Russ Unger와 Carolyn Chandler가 마술사라면 Alliance는 최고의 비밀을 밝히기 위해 그들을 쫓을 것입니다. 다행스럽게도 그렇지 않습니다. Russ와 Carolyn은 이전에 가장 경험이 많은 UX 프로젝트 리더에게만 알려진 현명한 지혜를 수집하여 모두가 볼 수 있도록 코드화했습니다. 이제 훌륭한 사용자 경험 프로젝트를 실행하는 데 필요한 비밀을 배울 수 있습니다. Jared M. Spool, 사용자 인터페이스 엔지니어링의 CEO 겸 창립 교장

사용자 경험 디자인에 대해 알아야 할 모든 것을 알려주는 책이 있습니까? 아니오. 거기까지 가는 데 도움이 되는 책이 있습니까? 지금 있습니다. Carolyn과 Russ는 디자인 프로젝트를 계획하고 관리하기 위한 견고한 기반을 마련했습니다. 이것은 경쟁 방법론, 끝없는 회의, 사용자 경험 디자인의 모든 움직이는 부분에 빠져 있는 모든 사람을 위한 필수 핸드북입니다. 커뮤니케이션 디자인의 저자 댄 브라운

이 책은 실제 사람들을 위해 훌륭한 제품을 디자인하는 방법에 대한 환상적인 입문서입니다. 하지만 단순한 디자인 그 이상을 다룹니다. 프로젝트 관리, 사람들과의 작업, 아이디어 전달 등 디자인과 관련된 모든 것도 포함합니다. 훌륭한 만능 선수. "Card Sorting: Designing Usable Categories"의 저자 Donna Spencer

이것은 매우 인간적인 활동에 대한 실용적이고 접근 가능하며 매우 인간적인 가이드입니다. Steve Portigal, Portigal 컨설팅

저자 Wil Wheaton에 대해 들어본 적이 있다면 내가 Russ Unger를 그토록 높이 평가하는 이유를 이해할 것입니다. Russ의 경험과 지침은 Monolith Press의 구성 및 설계에 기본이 되었으며, 그는 제가 지금까지 함께 일한 가장 귀중한 협력자 중 한 명입니다. Wil Wheaton, Dancing Barefoot, Just a Geek, The Happyest Days of Our Lives의 저자

ⅲ

감사의 말 Russ Unger 이 책은 가족, 친구, 동료, 그리고 처음 몇 번의 키 입력을 치기 전에는 전혀 알지 못했던 많은 사람들의 도움이 없었다면 결코 완성에 근접하지 못했을 것입니다. 과대성취 버그를 가진 괴짜와 기꺼이 고의로 결혼한 나의 아름다운 아내 Nicolle은 이 책을 쓰는 대부분의 시간 동안 육아 의무를 두 배로 늘렸습니다. 우리 딸인 시드니와 에이버리는 자주 혼수상태에 빠진 아버지를 찌르고 재촉하여 춤추고 노래하고 스포어를 연주하게 했습니다. 갓난아기를 집에 두고 책을 쓴다는 것이 그리 큰 도전이 아닐 거라 생각했다. 나는 빨리 다르게 배웠다. 그리고 Nicolle은 저를 구하고 이 프로젝트를 완료하는 데 필요한 집중을 할 수 있도록 몇 번이고 배트를 쳤습니다. 그녀는 내가 가장 의지하는 영웅입니다. 그녀는 혼돈 속에서 우리 집을 질서 있게 유지합니다. 그녀는 여기에서 우리 세계의 중심이며 우리 모두를 너무 쉽게 풀어줍니다. Nicolle은 Sydney와 Avery와 함께 저를 꽤 좋은 아버지처럼 보이게 해 주었고 저는 그것에 대해 감사합니다. 나는 세 명의 소녀와 함께 집에 살고 있고, 내가 줄 수 있는 모든 것보다 적은 것으로 그들 중 누구를 사랑하는 것은 상상할 수 없습니다. Carolyn은 나를 추적했습니다. 이 프로젝트가 시작되거나 끝나지 않을 것 같았던 때가 있었습니다. 그녀는 항상 일을 계속 진행하고, 아이디어를 탐구하고, 우리를 올바른 방향으로 이끌었습니다. 콜라보레이션이 너무 좋았고, 이번 작업을 통해 많은 것을 배웠습니다! 그녀는 확실히 내 UX 양에 대한 훌륭한 UX 음입니다. Michael Nolan은 인수 편집자였으며 완벽한 가이드였습니다. Michael은 정직하고 친절하며 일이 순조롭게 진행되도록 정말 도와주었습니다. Rebecca Freed는 저글러로서 책의 모든 측면을 관리하고 우리가 작업을 계속할 수 있도록 하며 종종 늦은 밤에 우리에게 이메일을 보냅니다. 슬프게도, 그녀는 종종 나로부터 거의 즉각적인 반응을 받았습니다! Linda Laflamme는 우리의 개발 편집자였으며 그녀의 Red Pen of Doom에 익숙해지면 내가 그녀를 불완전한 생각과 연속적인 문장에 빠뜨리려고 아무리 노력해도 그녀가 나를 올바른 방향으로 인도하고 있다는 것이 분명해졌습니다. Leslie Tilley는 단어를 최종적으로 다듬었습니다. Tracey Croom은 프로덕션, 레이아웃 및 그래픽 요소를 함께 가져왔습니다. 그리고 진짜 책이 나타났다. Steve "Doc" Baty는 Peachpit 사무실에서 빛을 보기 전에 모든 장을 읽었습니다. 나는 종종 새벽 2시경에 Steve에게 챕터를 보냈고 그는 iv

감사의 말

오전 5시까지 그의 피드백을 보낼 것입니다. 이는 작은 일이 아닙니다. Steve는 호주에 있지만 그럼에도 불구하고 인상적입니다. Steve의 끊임없는 도움과 신속한 처리가 없었다면 이 책이 선반에 올랐을 것이라고 믿기 어렵습니다. Brad Simpson(www.i-rradiate.com)은 내가 그에게 던진 모든 그래픽을 가져다가 아름다운 인쇄 준비 이미지로 바꾸었습니다. 종종 두 명의 십대 아들과 바쁜 작업 일정으로 자신의 삶을 저글링하면서 말입니다. 브래드가 언제라도 떠나는 것이 쉬웠을 텐데, 그는 프로젝트에 관심이 있었고 나를 지원하고 싶었던 진정한 친구입니다. 이 노력을 갚을 만큼 스테이크 저녁 식사가 충분할지 확신할 수 없지만, 거기에 도달하기 위해 열심히 노력할 것입니다. 이것을 지원하기 위해 많은 휴일과 늦은 밤을 포기해 주셔서 감사합니다, Brad. Mark Brooks는 시간 및/또는 능력을 넘어서는 시각적 구성 요소가 필요한 메시지를 전달하려고 할 때 몇 번 패닉 모드에 있는 나를 발견했습니다. Mark는 한 번 이상 뛰어 들어 하루를 구했고 저는 이것에 대해 빚을졌습니다. 재능이 있고 잘못에 자신을 내어주는 Mark는 내가 되고자 하는 유형의 사람입니다. Jonathan Ashton은 우리를 위해 검색 엔진 최적화에 대한 전체 장을 작성했습니다. 조나단과 5분 동안 이야기를 나눈 후 저는 그가 그 일에 적임자라는 것을 알았습니다. 그의 챕터 하나만으로도 이 책을 사야 하는 큰 이유가 되었고, 그가 참여하게 되어 정말 기뻤습니다. Jono Kane은 마지막 순간에 순간적으로 뛰어 들었습니다. Jono는 Yahoo의 웹 개발자, 인터랙션 디자이너 및 프로토타입 작성자이며 12장을 작성하는 데 매우 큰 도움을 주었습니다. Lou Rosenfeld는 이 공이 굴러가는 데 많은 도움을 주었습니다. 유명한 "Polar Bear Book"(O'Reilly's Information Architecture for the World Wide Web)을 공동 집필한 것 외에도 Lou는 똑똑하고 친절하며 접근하기 쉬우며 항상 우리 분야의 다른 사람들을 기꺼이 돕습니다. Lou만큼 자신에게 관대한 사람을 많이 찾기 어려울 것입니다. Christina Wodtke는 저를 소개하고 연결하는 데 도움을 주었습니다. Christina가 없었다면 오늘날 우리가 어디에 있을지 모르겠지만 아마도 "인쇄"되지 않았을 것입니다. 그녀는 "당신이 읽어야 할 작가"일 뿐만 아니라 항상 조언과 통찰력을 제공할 수 있는 사람입니다. UX 디자인 분야의 많은 사람들은 끊임없는 혁신을 통해 우리의 지평을 넓히려는 Christina의 지칠 줄 모르는 노력 덕분에 그들이 알고 있는 많은 것을 빚지고 있습니다. 감사의 말

Will Evans와 Todd Zaki Warfel은 자체 결과물의 템플릿으로 사용할 수 있는 고품질 결과물을 아낌없이 제공했습니다. 그들은 진정한 형제였고, 질문이나 걱정 없이, 종종 순간적인 통지에 그들의 시간과 재능을 바쳤습니다. 그들은 당신이 알고 함께 일하고 싶어하는 우리 UX 커뮤니티의 훌륭한 구성원이며 그들과 친구가 된 것을 축복합니다. 나는 이 두 사람에게 빚진 감사의 빚을 갚을 수 없습니다. David Armano, Chris Miller, Kurt Karlenzig, Livia Labate, Matthew Milan, Michael Leis, Mario Bourque, Troy Lucht, Ross Kimbarovsky(및 crowdSPRING의 갱단), Wil Wheaton은 저에게 좋은 친구이자 진정한 지지자이자 신봉자였습니다. 내가 아는 사람들의 목록으로 그 이름들을 함께 입력할 수 있다는 것만으로도 행운이고 그들이 하는 모든 일의 열렬한 팬입니다. 그들의 지원은 내가 하는 모든 일에서 나에게 헤아릴 수 없는 유익이 되었습니다. 이 훌륭한 사람들은 저를 돕기 위해 노력했고, 정보, 일화 및 리소스에 대한 액세스를 아낌없이 제공했으며 진심으로 감사드립니다. Tonia M. Bartz(www.toniambartz.com), 7장; Steve "Doc" Baty, (www.meld.com.au), 3장, 11장, 14장 및 "A Brief Guide to Meetings"; Mark Brooks(www.markpbrooks.com), 3장 및 11장; Leah Buley(www.adaptivepath.com), 11장; Dave Carlson(www.deech.com), 11장; Will Evans(www.semanticfoundry.com), 7, 10, 11장; Christopher Fahey(www.behaviordesign.com), 14장; Nick Finck(www.nickfinck.com), 10장; Jesse James Garrett(www.adaptivepath.com), 10장; 오스틴 고벨라(www.grafofini.com), 11장; Jon Hadden(www.jonhadden.com), 12장; Whitney Hess(www.whitneyhess.com), 11장; Andrew Hinton(www.inkblurt.com), 10장; Gabby Hon(www.staywiththegroup.com), 3장 및 11장; Kaleem Khan(www.uxjournal.com), "A Brief Guide to Meetings"; Ross Kimbarovsky(www.crowdspring.com), 14장; Livia Labate(www.livlab.com), 7장; Michael Leis(www.michaelleis.com), 11장; Troy Lucht(www.ascendrealtysolutions.com), 14장; 제임스 멜저(www.jamesmelzer.com), 10장; Matthew Milan(www.normativethinking.com), 7장; Chris Miller(www.hundredfathom.com/blog), "A Brief Guide to Meetings,"; Maciej Piwowarczyk(www.linkedin.com/pub/3/a74/a66), 11장; Stephanie Sansoucie(www.linkedin.com/in/smsansoucie), 11장; Kit Seeborg(www.seeborg.com), 3장, 11장 및 "A Brief Guide to Meetings"; Josh Seiden(www.joshuaseiden.com), 7장; 조나단 스누크(www.snook.ca), 12장; Joe Sokohl(www.sokohl.com), 12장 및 "A Brief Guide to Meetings"; Samantha Soma(www.sisoma.com), “A Brief Guide to

뷔

감사의 말

회의”; Donna Spencer(www.maadmob.net), 7장; Jared M. Spool(www.uie.com), 7장; Keith Tatum(www.slingthought.com), 12장; Todd Zaki Warfel(www.messagefirstt.com), 7장, 12장, 14장. Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau, Hugh Forrest of SXSW, Peter Ina, Alec Kalner, Jonathan Knoll, Christine Mortensen, Steve Portigal, Dirk M. Shaw, Paula Thornton, 그리고 Manifest Digital 사람들과 Draftfcb의 모든 사람들. 누군가를 그리워하는 것은 어쩔 수 없는 일이고 개인적으로 받아들이지 않았으면 합니다. 소싱된 "군중"에는 많은 사람들이 있으며 모든 사람을 추적하려고 노력했습니다. 놓친 경우 알려주시면 바로잡을 방법을 찾아보겠습니다! 마지막으로 Information Architecture Institute, Interaction Design Association 등과 같은 조직이 없었다면 언급된 많은 사람들과 연결하는 것이 불가능했을 것입니다. UX 디자인 분야에 대해 조금이라도 궁금하시다면 이 조직들을 찾아보고, 가입하고, 참여하세요!

Carolyn Chandler 우리 중 많은 사람들이 삶의 어느 시점에서 책을 쓰는 꿈을 꿉니다. Russ가 없었다면 뛰어들고 할 동기를 얻었을지 모르겠습니다. 그의 에너지와 열정은 Peachpit 팀에서 UX 산업의 리더에 이르기까지 적시에 적절한 사람을 찾는 데 도움이 되었으며, 이들 모두는 이 페이지에서 보는 내용에 큰 영향을 미쳤습니다. 그는 진정으로 우리 분야의 위대한 연결자 중 한 명이며 밤낮으로 사람들을 하나로 모으는 데 성공합니다. 게다가 내가 트위터에 가입한 이후로 그가 하루에 올린 트윗보다 더 많은 트윗을 올린 것 같아요! Russ는 우리를 엄청나게 도와준 많은 사람들에게 감사를 표했습니다. 나는 우리가 그에게 던질 수있는 원시 형식으로 모든 장을 읽었고 여전히 오전 2시 (그의 시간)에 열정적으로 들렸던 Steve Baty의 이름 이외의 모든 이름을 반복하지 않을 것입니다. John Geletka는 또한 여러 분야를 넘나드는 불꽃과 관점으로 사려 깊은 피드백과 흥미로운 토론을 제공했습니다. 물론 Peachpit 팀도 마찬가지입니다. 나는 Linda Laflamme에게서 나의 첫 장을 되찾은 것을 결코 잊지 못할 것입니다. 예쁘지 않았습니다 (그녀는 훌륭한 재치로 제안을 전달했지만). 그녀는 참을성 있게

감사의 말

vii

편집을 통해 저를 데려갔고 원래 전체 길이의 책보다 일회성 백서를 작성하는 데 더 적합했던 흐름을 개선하는 데 도움을 주었습니다. 이제는 동료들과의 일상적인 대화에 전환을 추가하는 제 자신을 발견했습니다! 말하자면... 크리스틴 모텐슨(Christine Mortensen, a.k.a. Morty)은 시각적 요소와 관련하여 제 범죄 파트너였습니다. 제 장에서 볼 수 있는 아이콘과 다이어그램은 그녀의 노력의 결과입니다. 그녀와 저는 장 마감일을 맞추려고 노력하는 동시에 많은 동일한 고객 프로젝트에서 작업했기 때문에 얼마나 힘든지 압니다. Morty는 시각적 디자인과 인터랙션 디자인 모두에 자신의 발을 내디딜 수 있는 비주얼 디자이너 중 한 명으로, 프로젝트의 모든 사람과 유쾌하게 협업하고 개념을 생생한 삶으로 가져옵니다. 그녀는 함께 일하는 것을 즐겁게 만드는 무결성과 품질에 대한 집중을 가지고 있으며, 그녀를 파트너로 삼게 되어 영광이었습니다. 또한 지난 몇 개월 동안 큰 도움을 준 Manifest Digital의 모든 직원들에게도 많은 감사를 드립니다. Jim Jacoby는 그의 트레이드마크인 선과도 같은 차분함과 함께 비즈니스에 정통한 시각과 UX 관점의 특별한 조화를 가져왔습니다. Jason Ulaszek은 UX 분야에서 내가 아는 가장 열정적인 사람 중 한 명이며 도구와 기술에 대한 끝없는 지식을 가지고 있습니다. 나는 그가 모든 것을 위한 공간을 어디에 두는지 전혀 모릅니다! 또한 Brett Gilbert와 Jen O'Brien은 UX 디자이너와 협업하는 많은 역할에 귀중한 정보를 제공했습니다. 또한 영감을 주고 "책"의 진행에 대한 나의 끊임없는 참조를 참을성 있게 기다려준 Manifest UX 팀원들에게도 감사를 표하고 싶습니다: Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith 페인, 산티아고 루이즈. 당신은 함께 일할 수 있는 끊임없는 기쁨입니다. 매일 나는 당신의 유머와 통찰력에 감사합니다. Interaction Design Association의 동료 회원 여러분, 귀하의 경험을 공유하고 제가 사랑하는 UX 커뮤니티의 적극적인 회원이 되어 주셔서 감사합니다. 특히 시카고 챕터 개발의 핵심이었으며 똑똑한 사람들의 활기찬 네트워크를 성장시키기 위한 새로운 방법을 지속적으로 찾고 있는 Janna Hicks DeVylder와 Nick Iozzo에게 감사의 말을 전하고 싶습니다. 마지막으로 저의 실종 행위를 참을성 있게 견디고 제가 아직 살아 있는지 확인하기 위해 계속 확인해 준 가족, 친구, 안토니에게 감사드립니다. 당신은 현금으로 바꿀 수 있는 우천 수표를 많이 가지고 있으며, 나는 그것을 당신과 함께 사용하기를 기대합니다!

viii

감사의 말

목차 소개

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

1장:

UXD의 타오. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 사용자 경험 디자인이란 무엇입니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 광범위한 정의 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 유형을 잊지 마세요. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 우리의 초점 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

UX 디자이너 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 UX 디자이너가 사는 곳 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 시작합시다! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2장:

프로젝트 생태계. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 사이트 유형 식별 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 브랜드 존재 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 마케팅 캠페인 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 콘텐츠 소스 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 작업 기반 애플리케이션 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 전자 상거래 사이트 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 E-러닝 애플리케이션 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 소셜 네트워킹 애플리케이션 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

당신의 모자를 선택하십시오. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 정보 설계자. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 인터랙션 디자이너 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 사용자 연구원 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 귀하가 수행하거나 필요할 수 있는 기타 역할 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 사용자 옹호 네트워크 구축 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

회사 문화를 이해하십시오. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 역사 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 계층 구조 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 물류. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

함께 당기기. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3장: 제안

컨설턴트 및 프리랜서용. . . . . . . . . . . . . . . . . . 39 제안서 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 제안서 작성. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

내용물

제목 페이지. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 개정 내역 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 프로젝트 개요 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 프로젝트 접근법 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 작업 범위 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 가정 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 산출물. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 소유권 및 권리 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 추가 비용 및 수수료 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 프로젝트 가격. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 지불 일정 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 확인 및 승인 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

작업 명세서 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4장: 프로젝트

목표 및 접근 . . . . . . . . . . . . . . . . . . . . . . . . . . 56 프로젝트 목표 구체화 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

UX 디자이너가 어떻게 도울 수 있습니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

프로젝트 접근 방식을 이해합니다. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 폭포 접근법. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 애자일 접근법 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 수정된 접근법. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 접근 방식이 나에게 어떤 영향을 미칩니까?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5장: 비즈니스

요구 사항 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 현재 상태 이해 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 휴리스틱 분석 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

이해 관계자로부터 아이디어를 수집합니다. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 개요 책임 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 올바른 이해관계자 모으기 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 회의 계획 세우기 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 영업: 요구 사항 수집 회의. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 회의를 효과적으로 운영하십시오. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 병합 요구 사항 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

엑스

내용물

6장: 사용자

연구 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 사용자 조사의 기본 단계 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 사용자 그룹 정의 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 속성 목록 생성 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 우선 순위를 정하고 정의하십시오. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

연구 기법 선택 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 얼마나 많은 연구 활동을 포함할 수 있습니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 사용자 인터뷰 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 상황별 조회 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 설문조사. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 포커스 그룹 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 카드 정렬 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 사용성 테스트 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

연구 후. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7장: 페르소나

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 페르소나란? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 페르소나를 만드는 이유는 무엇입니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 페르소나에 대한 정보 찾기 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 페르소나 만들기 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

최소 콘텐츠 요구 사항 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 선택적 콘텐츠 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

고급 페르소나. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 페르소나에 대한 최종 생각 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 8장: 사용자

경험 디자인 및 검색 엔진 최적화 . . . . 126 SEO 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 SEO가 중요한 이유는 무엇입니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 중요한 기본 리소스 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

사이트 기술, 설계 및 인프라 . . . . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript 및 기타 스크립팅된 컨텐츠 . . . . . . . . . . . . . . . . . . . . . . 130 콘텐츠 관리 시스템 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 도메인, 디렉토리 및 URL 구조가 모두 중요합니다. . . . . . . . . . . . . . . . . . . . . . . . 134

내용: The Once (and Current) and Future King . . . . . . . . . . . . . . . 135 명명 규칙 및 전문 용어와의 전쟁 . . . . . . . . . . . . . . . . . . . . . 136 메타데이터, 헤더 및 키워드. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

내용물

머리카락을 나눕니다. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 사이트 맵 사용 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 콘텐츠를 최신 상태로 유지 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 기타 콘텐츠 문제. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

링크 인기 설명 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 일반적인 링크 인기 분포 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 바닥글 링크. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 콘텐츠 내 교차 연결 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

시스템 게임. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 흰 모자 대 검은 모자. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 메타 키워드를 사용한 스팸. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 복제 및 도어웨이 페이지 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 링크 스팸 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

몇 가지 최종 생각 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 9장: 전환:

정의에서 설계까지 . . . . . . . . . . . . . . . . . . . . 144 기능 구상 및 시각화 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

스토리보딩의 기본 과정 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

우선 순위 지정 프로세스를 촉진합니다. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 적절한 긴장 유지 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 개발 옹호자 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 우선 순위 지정 중 충돌 관리 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

활동 및 문서화 계획 . . . . . . . . . . . . . . . . . . . . . . . . 162 10장: 사이트

맵 및 작업 흐름. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 사이트 맵이란? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 작업 흐름이란 무엇입니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 거래 도구 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 사이트 맵 및 작업 흐름의 기본 요소. . . . . . . . . . . . . . . . . . . . . 168 페이지 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 페이지 스택 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 결정 포인트. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 커넥터 및 화살표 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 조건. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

흔한 실수 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 조잡한 연결. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

xii

내용물

잘못 정렬되고 고르지 않은 간격의 개체 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 잘못 배치된 텍스트 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 페이지 번호 매기기 부족. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 간단한 사이트 맵 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

고급 사이트 맵 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 사이트 맵 틀 깨기. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 작업 흐름 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 작업 흐름을 다음 단계로 가져가기. . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 프로세스 흐름 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 스윔 레인 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 11장: 와이어프레임

및 주석. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 와이어프레임이란? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 주석이란 무엇입니까?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 누가 와이어프레임을 사용합니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

와이어프레임 만들기 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 거래 도구. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

간단하게 시작: 기본 와이어프레임 설계 . . . . . . . . . . . . . . . . . . . . . . . . . .191 시작하기 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 와이어프레임 및 주석. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

연습: 홈 페이지 와이어프레임 디자인 . . . . . . . . . . . . . . . . . . . 195 요구 사항 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 결과: 홈 페이지 와이어프레임 디자인 . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 시각 디자인: 와이어프레임이 성장하고 세계에서 고유한 방식을 찾을 때. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 디자인 실습 후속 조치: 어떤 디자인이 옳은가? . . . . . . . . . . . . . . . . . . . . . . 201

와이어프레임 표시에 대한 최종 참고 사항 . . . . . . . . . . . . . . . . . . . . . . . . . 202 12장: 프로토타이핑.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 프로토타이핑이란 무엇입니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 얼마나 많은 프로토타입이 필요합니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 종이 프로토타이핑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 디지털 프로토타이핑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 와이어프레임 대 실제 프로토타입 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 HTML 대 WYSIWYG 편집기 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 프로토타이핑을 위한 추가 도구. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

내용물

xiii

개발자와 함께 일하기. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

프로토타입 예제 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 프로토타이핑 후에는 어떻게 됩니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 13장: 설계

사용자 테스트 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 개념 탐색. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 시각 디자인 목업 탐색에 대한 팁 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

사용성 테스트. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 접근 방식 선택 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 연구 계획 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 채용 및 물류 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 토론 가이드 작성. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 촉진 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 결과 분석 및 제시. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 권장 사항 생성. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 14장: 전환:

디자인에서 개발 및 그 이상까지. . . . . . 247화 끝이다.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 시각적 디자인, 개발 및 품질 보증 . . . . . . . . . . . . . 248 사용자와 디자인 테스트(다시). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … 발사! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 개인적 이점 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 지원 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 네트워크 의견 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

출시 후 활동. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 실행 후 분석 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 사용자를 대상으로 한 출시 후 디자인 테스트(다시, 다시) . . . . . . . . . . . . . . . . . . . . . 255

모두 끝났죠? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 다시 시작하는 것처럼… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 색인

xiv

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

내용물

소개 우리가 이 책을 쓴 이유 UX 디자인에 대한 프로젝트 가이드에 오신 것을 환영합니다. 어딘가에 새 회사에서 실제 프로젝트를 진행하는 것이 어떨지 몰라 잠을 설치고 있는 사용자 경험 디자인 학생이 있습니다. 마을 건너편에는 사이트의 사용자 경험을 정의하는 새로운 책임을 맡고 싶어하는 프로젝트 경험이 풍부한 비주얼 디자이너가 있습니다. 이 두 사람은 인생의 서로 다른 시점에 있지만 비슷한 요구 사항을 가지고 있습니다. 살아 숨쉬는 프로젝트의 맥락에서 사용자 경험 사례를 통합하는 방법을 이해하는 것입니다. 이 책의 목표는 작업 팀과 함께 UX 도구와 기술을 사용하는 데 도움이 되는 기본 도구와 컨텍스트를 제공하는 것입니다. 이 장의 많은 부분에서 보게 되겠지만, 우리는 모든 사람에게 모든 것이 되려고 노력하는 것이 아니라 앞으로 수행할 많은 의무를 수행하는 데 필요한 핵심 정보와 지식을 제공하려고 합니다. UX 디자이너로 지정됩니다. 자체 예제 외에도 기본 자료를 빠르게 시작하고 정보를 매시업하고 자신의 목적에 더 적합하고 더 새롭고 더 나은 것을 만들 수 있는 방법을 식별하는 데 도움이 되는 예제를 제공합니다. 우리는 이것이 UX 디자인 프로젝트에 대한 꽤 좋은 접근 방식이라는 것을 제대로 표현했기를 바랍니다. 반복할 때마다 (우리가 무엇을 하든) 끊임없이 배우고 개선하려고 노력하지 않는다면 우리는 아무것도 아닙니다. 그것이 어느 정도 우리가 이 분야에 있는 이유입니다. Russ의 한마디 Information Architecture Institute(www.iainstitute.org)의 멘토로서 함께 일한 사람들 사이에서 한 가지 패턴을 발견했습니다. . 일부는 뛰어난 교육을 받았지만 항상 프로젝트 기반 환경에서 UX 디자인 기술을 충분히 실용적으로 적용하지는 못했습니다. 2008년 Information Architecture Summit(www.iasummit.org)에서 내가 가졌던 많은 대화에서 동일한 주제가 울려 퍼졌습니다.

소개

이러한 일반적인 문제를 많이 다루는 이 책에 대한 아이디어가 구체화되기 시작했습니다. 캐롤린이 처음 이메일을 보냈는지 내가 처음으로 이메일을 보냈는지 기억나지 않지만 그녀에게서 결국 이 책이 된 아이디어의 모서리를 다듬는 데 도움을 준 기꺼이 유능한 공동 저자를 찾았다는 것은 알고 있습니다. Carolyn의 한마디 수년 동안 저는 UX 팀을 구성하고 관리하는 운 좋은 위치에 있었습니다. 나는 일반적으로 UX 디자이너가 우뇌의 직관과 좌뇌의 논리를 혼합하여 함께 작업하는 것을 아주 재미있게 만드는 특성의 훌륭한 균형을 가지고 있다는 것을 알기 때문에 "행운"이라고 말합니다. 이 팀을 구성하기 위해 인터뷰를 진행하면서 한 가지 사실이 정말 눈에 띄었습니다. 인적 요소 또는 커뮤니케이션 디자인과 같은 관련 교육 배경은 누군가가 UX 디자인 분야에 전념하고 있다는 훌륭한 지표이지만 숫자는 아닙니다. 누군가가 팀이나 프로젝트에 잘 맞는지 여부를 나타내는 하나의 지표입니다. 컨설턴트의 마음가짐을 가질 수 있는 사람의 능력도 마찬가지로 중요합니다. 이것은 긍정적인 태도, 프로젝트 전반에 걸쳐 다른 사람들을 이해하고 포함하려는 추진력, 그리고 무엇보다도 사용자와 고객에게 실질적인 영향을 미치는 데 초점을 맞추는 것을 의미합니다. 이러한 마음가짐은 시간을 들여 프로젝트에서 다른 역할의 관점을 이해하고 사례를 만들고 필요한 경우 타협하는 것을 의미합니다. 이러한 마음가짐을 진정으로 잘 정착시키려면 경험과 노력이 필요하지만 열린 마음, 강력한 기반, 좋은 일련의 질문(질문할 용기를 가지고)을 가지면 먼 길을 갈 수 있습니다. 이 책이 모든 "답"을 제공하지는 않지만 답을 찾는 데 도움이 되는 질문은 제공할 것입니다.

이 책을 읽어야 할 사람 UX 디자인에 대한 프로젝트 가이드는 프로젝트의 맥락 내에서 UX 디자인에 대한 광범위한 소개 개요를 제공합니다. UX 디자인에 관심이 있는 사람이라면 누구나 여기에서 유용한 정보를 찾을 수 있을 것입니다. 우리는 특히 다음 그룹에 중점을 두었습니다. UX 디자인 과정(예: 인간-컴퓨터 상호 작용 또는 상호 작용 디자인)을 수강하는 학생으로서 학습 내용을 커뮤니케이션과 협업이 필요한 실제 상황에 적용하는 방법에 대한 정보로 과정을 보완하고자 합니다. 필수적인.

xvi

소개

UX 디자인의 기본 도구 및 기술에 대한 지식을 심화하고 관련된 역할에 대한 팀 커뮤니케이션을 개선하려는 실무자. 3장은 또한 특히 자신만의 제안서를 작성해야 하는 프리랜서를 대상으로 합니다. 팀이 프로젝트 모범 사례를 UX 디자인 활동과 통합하는 데 도움이 될 책을 찾고 있는 UX 디자인 그룹의 리더입니다. UX 디자인이 프로젝트에 어떻게 통합되는지, 가치가 무엇인지, UX 디자이너에게 무엇을 기대해야 하는지에 대해 자세히 알아보고자 하는 모든 프로젝트 팀의 리더. 필요한 경우…

그런 다음 읽어야 합니다…

사용자 경험 디자인을 정의하고 무엇이 사람들을 현장으로 끌어들이는지 이해합니다.

1장: UXD의 도

프로젝트를 시작하기 전에(또는 적어도 작업을 시작하기 전에) 대답해야 할 중요한 질문을 하십시오.

2장: 프로젝트 생태계 3장: 컨설턴트 및 프리랜서를 위한 제안

효율적인 회의, 명확한 목표, 이해하기 쉬운 승인 지점으로 시작하세요.

온라인 장: 회의에 대한 간략한 안내 4장: 프로젝트 목표 및 접근 방식

비즈니스 이해 관계자 및 사용자로부터 도출된 명확하고 우선 순위를 지정하기 쉬운 프로젝트 요구 사항을 정의합니다.

5장: 비즈니스 요구 사항 6장: 사용자 조사 9장: 전환: 정의에서 설계로

사용자에 대해 알아보고 프로젝트 전반에 걸쳐 사용자의 요구 사항을 표현합니다.

6장: 사용자 조사 7장: 페르소나 13장: 사용자를 대상으로 한 설계 테스트

프로젝트 팀에 시각적 아이디어를 신속하게 제공할 수 있는 도구와 기술을 선택하고 활용하십시오.

10장: 사이트 맵 및 작업 흐름 11장: 와이어프레임 및 주석 12장: 프로토타이핑

사용자와 검색 엔진이 사이트를 쉽게 찾고 검색할 수 있도록 합니다.

8장: 사용자 경험 설계 및 검색 엔진 최적화

개발이 시작되면 프로젝트 팀과 커뮤니케이션하고 디자인을 발전시키십시오.

14장: 전환: 설계에서 개발 및 그 이상으로

www.projectuxd.com을 방문하여 보너스 챕터인 "A Brief Guide to Meetings"를 읽고 템플릿과 같은 기타 보너스 자료를 다운로드하십시오.

소개

xvii

방법론에 대한 참고 사항 세상에는 다양한 접근 방식과 방법론이 있습니다. 우리는 다른 접근 방식보다 한 접근 방식을 지지하지 않습니다. 이 책의 목표는 프로젝트 요구 사항 정의, 경험 설계, 솔루션 개발 및 배포와 같이 대부분의 프로젝트에 공통적인 단계에 초점을 맞추는 것입니다. 이 단계 사이의 중첩 정도는 사용하는 프로젝트 접근 방식에 따라 크게 달라집니다(자세한 내용은 4장 참조). 대부분의 경우 프레임워크는 정의 단계가 먼저 오는 느슨한 선형 접근 방식이지만 각 단계에서 가장 도움이 되는 촉진 및 설계 기술을 활용합니다.

What This Book Is Not 모든 기술의 백과사전. UX 분야에는 엄청난 수의 창의적인 사람들이 있으며 그들은 항상 디자인 문제에 대한 새로운 접근 방식을 시도하고 있습니다. 여기에 이러한 접근 방식을 모두 포함하면 훨씬 더 큰 책이 될 것이며 곧 구식이 될 것입니다. 여기에 포함된 것은 가장 일반적으로 사용되는 기술, UX 디자인의 기본입니다. 우리는 각 기술에 대한 기본 프로세스와 경로를 선택한 후 이를 구현하는 데 도움이 되는 책이나 사이트에 대한 추가 참조를 포함하여 귀하의 관심을 끌고 다른 프로젝트 구성원에게 활동을 전달할 수 있도록 충분한 정보를 제공하려고 노력했습니다. 프로젝트 관리자가 되기 위한 지침서. 훌륭한 프로젝트 관리(프로젝트 목표, 일정 및 예산 설정 및 추적 포함)는 모든 프로젝트 성공의 핵심입니다. 프로젝트 관리자가 되는 방법이나 특정 프로젝트 방법론을 선택하는 방법에 대한 구체적인 내용은 다루지 않습니다. 우리는 UX 디자이너가 촉진 및 커뮤니케이션과 같이 프로젝트를 효과적으로 실행할 수 있도록 하는 기술과 프로젝트 목표를 명확하게 하고 초점을 유지하는 능력에 대해 논의합니다. 이러한 기술은 프로젝트 관리의 파트너가 되는 데 도움이 됩니다. 따라야 할 유일한 또는 완벽한 프로세스 또는 방법론입니다. 우리는 모든 답을 갖고 있지 않습니다. 오늘날 아무도 답을 갖고 있지 않습니다. UX 디자인 분야는 상대적으로 젊고 우리 모두는 우리가 있는 곳을 개선하기 위해 노력하고 있습니다. 시행 착오, 개선 사항 및 개선 사항, 피드백을 찾을 수 있습니다.

xviii

소개

다른 사람들이 귀하의 필요에 맞게 프로세스를 조정하는 데 도움이 될 것입니다. 자신에게 맞는 것을 찾으면 공유하십시오! 알려주세요!

이 책을 사용하는 방법 UX 디자이너를 위한 훌륭한 리소스가 많이 있습니다. 여기서는 주제를 광범위하게 다루지만, 얼마나 많은 시간을 할애하고 싶은지에 따라 더 깊은 수준에서 주제를 탐색할 수 있는 참고 자료를 알려줍니다. 각 참조에 일반적으로 필요한 시간을 이해하는 데 도움이 되도록 다음 세 가지 주요 범주로 나누었습니다.

서핑 보드와 함께 호출되는 서핑 참조는 읽는 데 5~30분이 소요되는 더 짧은 기능(일반적으로 온라인)입니다.

스노클링 스노클링으로 호출된 사람들은 더 긴 온라인 기사, 백서 또는 읽는 데 한 시간에서 주말까지 걸리는 짧은 책입니다.

딥 다이빙 잠수부 헬멧을 쓴 사람들은 읽는 데 아마 일주일 이상 걸릴 더 긴 책들입니다. 주제에 대한 심층적인 내용을 제공합니다.

소개

xix

이 페이지는 의도적으로 비워두었습니다.

UXD의 도 호기심이 열정을 만나고 공감을 만나다 중요한 것은 질문을 멈추지 않는 것입니다. 호기심은 그 나름의 존재 이유가 있습니다. 영원의 신비, 생명의 신비, 실재의 경이로운 구조를 묵상할 때 경외감을 느끼지 않을 수 없습니다. 매일 이 신비를 조금이라도 이해하려고 노력하는 것으로 충분합니다. 알버트 아인슈타인

호기심은 자연의 원래 교육 학교입니다. 스마일리 블랜튼

열정과 목적은 함께 간다. 당신이 당신의 목적을 발견할 때, 당신은 일반적으로 그것이 당신이 엄청나게 열정적이라는 것을 알게 될 것입니다. 스티브 파블리나

인간의 위대한 선물은 우리가 공감의 힘을 가지고 있다는 것입니다. 메릴 스트립

큐

간단히 말해서 이 장은 당신과 사용자 경험 디자인(또는 줄여서 UX 디자인) 분야에 끌리는 다른 사람들에 관한 것입니다.

이 문장을 읽고 있다면 당신은 호기심 많은 사람입니다. 문 손잡이에서 비행기, 목 뒤에 있는 것에 이르기까지 모든 것이 어떻게 작동하는지 알고 싶어합니다. 무엇보다도 사람들을 움직이게 만드는 것이 무엇인지 알고 싶습니다. 사물을 흑백으로 보지 않습니다. 탐색할 회색 음영이 많이 있습니다! 물론, 때때로 당신은 항상 악마의 옹호자 역할을 자원하여 동료들을 약간 미치게 만들 수 있지만 동전의 반대편을 보려고 노력하는 것을 멈출 수 있는 것은 아닙니다. 행운아! 사용자 경험 디자인 분야는 다양한 회색 음영으로 편안하게 작업할 수 있는 호기심 많은 사람들을 끌어들입니다. 우리는 패턴을 찾고 조직과 구조를 위해 번성합니다. 우리는 점들을 연결합니다. 우리는 끈질기게 퍼즐의 다음 조각을 추구하고 퍼즐이 해결되면 이를 개선할 방법을 찾습니다! 우리는 아날로그가 될 수도 있고 디지털이 될 수도 있습니다. 우리는 집에 연필과 종이, 화이트보드, 드라이 지우개 마커, 포스트잇 노트, 샤피 펜을 가지고 있습니다. 우리는 Visio와 'Graffle'이라는 용어로 이야기하며 컴퓨터의 여러 화면에 연결된 상자와 화살표의 세계에 살고 있습니다. 우리는 호기심만 있는 것이 아닙니다. 우리는 열정적입니다! 우리는 아이디어를 브레인스토밍하고 토론을 촉진하는 데 열정을 가지고 있습니다. 우리는 제품을 사용하는 사람들과 그것을 만드는 사람들을 위해 변화를 가져오는 제품을 만들고자 하는 열정을 가지고 있습니다. 이상하게도 우리는 우리가 만든 것이 너무 좋아서 사람들이 그것이 얼마나 좋은지 깨닫지 못할 때 가장 자랑스럽습니다! 그리고 물론 우리는 공감합니다. 우리는 나쁜 경험을 만났을 때 우리 존재 구조의 핵심 깊숙이 그것을 느낄 수 있습니다. 설상가상으로 우리는 즉시 문제를 해결하기 위한 솔루션을 찾으려고 합니다. 우리는 단순한 요청처럼 보이는 것에 대해 예상치 못한 응답을 받는 것이 어떤 것인지 알고 있습니다. 그리고 우리는 그것을 좋아하지 않습니다! 우리는 우리와 같은 사용자가 열악한 경험과 함께 자주 발생하는 혼란과 부족함을 견뎌야 하는 것을 원하지 않습니다. 2

1장: UXD의 도

거의 변함없고 어린아이 같은 호기심과 "우리가 하는 일을 하는 것"에 대한 비할 데 없는 열정과 다른 사람들이 어떻게 느끼는지에 대한 감각을 결합할 때, 편안하게 자신의 생각을 말하고, 질문하고, 솔루션을 공유하는 활기찬 전문가 커뮤니티를 갖게 됩니다. 그리고 잘못된 것 – 모두 옳은 것에 도달한다는 이름으로. UX 디자인 커뮤니티에 오신 것을 환영합니다.

사용자 경험 디자인이란 무엇입니까? 사용자 경험 디자인에 대한 많은 정의가 있습니다. 결국 사물을 정의하는 데 번성하는 분야입니다. 인정하건대, 때때로 우리는 전체의 다양한 부분에 관해서 "망할 것을 정의"하는 일을 그렇게 잘하지 못하지만, 적어도 전체가 무엇인지는 압니다. 이 책에서는 특히 두 가지 정의, 즉 UX 디자인이라는 용어의 가장 넓은 의미와 이 책의 맥락에서 사용할 정의에 초점을 맞출 것입니다.

광범위한 정의 사용자 경험 디자인은 사용자의 인식과 행동에 영향을 미치려는 의도로 특정 회사에 대한 사용자 경험에 영향을 미치는 요소를 생성하고 동기화하는 것입니다.

이러한 요소에는 사용자가 만질 수 있는 것(예: 유형의 제품 및 포장), 들을 수 있는 것(광고 및 오디오 서명), 심지어 냄새(샌드위치 가게에서 갓 구운 빵의 향기)까지 포함됩니다. 여기에는 사용자가 디지털 인터페이스(웹 사이트 및 휴대폰 애플리케이션)와 같이 물리적인 것 이상의 방식으로 상호 작용할 수 있는 것과 사람(고객 서비스 담당자, 판매원, 친구 및 가족)이 포함됩니다. 지난 몇 년간 가장 흥미로운 발전 중 하나는 이러한 다양한 감각에 영향을 미치는 요소를 보다 풍부하고 통합된 경험으로 병합하는 기능이었습니다. Smell-o-vision은 아직 먼 미래이지만, 그렇지 않으면 제품이 계속해서 전통적인 선을 흐리게 합니다.

사용자 경험 디자인이란 무엇입니까?

삼

우리는 사용자 경험의 디지털 측면에 초점을 맞추고 있지만 이러한 유형의 상호 작용은 진공 상태에서 발생하지 않습니다. 디지털 제품을 디자인할 때 유형 경험의 효과를 반드시 고려하십시오. 사용자가 디자인과 상호 작용하는 방식에 영향을 미치는 실제 제품(스크린, 키보드 및 기타 입력 장치)과 마찬가지로 사용자가 작업하는 환경이 중요합니다. 6장에서는 컨텍스트의 영향을 이해하는 데 도움이 되는 기술을 제공합니다. 또한 제품이나 회사가 그것과 상호 작용하는 사람들과 갖는 다른 접점을 잊지 마십시오. 결국 회사의 브랜드는 많은 것에 영향을 받고 브랜드 경험은 컴퓨터나 휴대폰 화면에서 끝나지 않습니다. 가능한 최고의 웹 사이트 디자인은 열악한 고객 서비스에 대한 평판을 보완하거나 제품이 배송될 때 잘 디자인된 포장의 만족을 제공할 수 없습니다.

그림 1.1 현대 교실 환경은 아날로그와 디지털을 혼합합니다.

1장: UXD의 도

교실에서의 학습과 같은 유형의 경험은 디지털 애플리케이션의 영향을 점점 더 많이 받고 있습니다. 마찬가지로 가정용 가라오케 기계를 선택하는 것과 같이 개인의 경험이 사회적 상호 작용을 통해 점점 더 향상되고 있습니다.

그림 1.2 온라인 리뷰는 소비자에게 큰 영향을 미칩니다.

우리의 초점 보시다시피 UX 디자인의 범위는 크고 성장하고 있습니다. 이 책의 목적을 위해 우리는 특히 웹 사이트 및 소프트웨어 응용 프로그램과 같은 대화형 미디어와 같은 디지털 경험 디자인에 중점을 둔 프로젝트에 초점을 맞출 것입니다. 성공하려면 이러한 제품의 사용자 경험 디자인에서 프로젝트의 비즈니스 목표, 제품 사용자의 요구 사항 및 제품 기능의 실행 가능성에 영향을 미치는 모든 제한 사항(예: 기술적 제한 사항 또는 프로젝트 예산에 대한 제약 사항)을 고려해야 합니다. 또는 기간).

사용자 경험 디자인이란 무엇입니까?

마라톤에서 나눠주는 새로운 영양 바의 무료 샘플

문 손잡이

신발 한 켤레의 포장

그림 1.3 이 책은 사용자 경험 디자인의 디지털 측면에 중점을 둡니다.

유형의 휴대폰 문자 메시지 기능

고객 서비스 전화 통화

개인

사회의

우리의 초점 온라인 제품 리뷰 읽기 온라인 아카이브 검색 타겟 광고 보기

디지털 고객 서비스 라이브 채팅

About UX Designers 호기심, 열정, 공감은 UX디자이너의 공통된 특성이지만 균형을 이루고자 하는 욕구도 있습니다. 우리는 그의 감정 칩이 그의 양전자 릴레이에 과부하를 준 에피소드에서 Spock과 Kirk 또는 Data와 Data와 같이 논리와 감정 사이의 균형을 찾습니다. 당신은 아이디어를 얻습니다. 진정으로 기억에 남고 만족스러운 경험을 만들기 위해 UX 디자이너는 경험을 위한 논리적이고 실행 가능한 구조를 만드는 방법을 이해해야 하며 제품 사용자와 감정적인 연결을 만드는 데 중요한 요소를 이해해야 합니다. 정확한 잔액은 제품에 따라 변동될 수 있습니다. 어린이 장난감에 대한 광고 캠페인은 병원에서 환자 정보를 추적하기 위한 애플리케이션과 균형이 다릅니다. 두 가지 모두에 대한 필요성을 이해하지 않고 설계된 제품은 진정으로 기억에 남을 경험의 기회를 놓치고 제품 뒤에 있는 회사에 결과로 나타나는 이점을 놓칠 수 있습니다. 노트 감성 디자인에 대한 추가 정보는 Donald Norman의 감성 디자인: Why We Love (or Hate) Everyday Things(Basic Books, 2005)를 확인하십시오.

1장: UXD의 도

이러한 균형을 이루려면 공감 능력이 높아야 합니다. 즉, 잠재적인 제품 사용자의 세계에 몰입하여 그들의 요구 사항과 동기를 이해하는 능력입니다. 사용자 경험 디자이너는 이러한 이해에 도달하기 위해 조사를 수행하고(6장 참조) 나머지 프로젝트 팀이 노력에 집중할 수 있도록 페르소나와 같은 도구를 만듭니다(7장 참조). 감정은 전체 그림의 일부일 뿐임을 기억하십시오. 논리적 측면을 사용하여 에지에서 벗어나 당면한 작업에 집중하십시오. 대부분의 경우 프로젝트를 완료하는 데 필요한 시간과 자료를 기준으로 예산에 맞춰 작업하게 됩니다. 때때로 낚시를 하거나 미끼를 잘라야 한다는 것을 이해해야 합니다.

UX 디자이너가 사는 곳 당신은 혼자가 아닙니다. 주변을 둘러보면 사용자 경험 디자이너로서의 개발을 촉진할 수 있는 많은 조직과 커뮤니티를 찾을 수 있습니다. 메일링 리스트, 온라인 리소스, 수많은 정말 똑똑한 사람들을 제공하는 것 외에도 이러한 조직 중 다수는 시야를 넓히는 동시에 경력 초점을 좁히는 데 도움이 되는 이벤트나 컨퍼런스를 후원합니다. 많은 회사에서 User Interface Engineering의 Web App Summit 및 User Interface Conference, Adaptive Path의 UX Intensive, Nielsen Norman Group의 Usability Week 등 평생 교육을 제공하기 위한 이벤트를 주최합니다. 또한 여러 도시에서 "언컨퍼런스"의 수가 증가하고 있습니다. 이들은 특정 회사나 협회로부터 독립된 동기 부여된 개인들의 집합에 의해 만들어집니다.

UX 디자이너가 사는 곳

여러 전문 기관도 매년 회의를 후원합니다. 표 1.1은 더 잘 알려진 일부 조직, 웹 사이트 및 주최하는 이벤트의 짧은 목록을 제공합니다. 표 1.1

UX 조직의 샘플링

조직

웹 사이트

주요 회의(일반적으로 개최)

인터랙션 디자인 협회(IxDA)

www.ixda.org

상호 작용(2월 초)

정보 아키텍처 연구소(IAI)

www.iainstitute.org

IDEA 컨퍼런스 (9월/10월)

미국정보과학기술학회(ASIS&T)

www.asis.org

IA 서밋(3월)

ComputerHuman Interaction에 대한 ACM 특별 관심 그룹(SIGCHI)

www.sigchi.org

CHI(4월 초)

사용성 전문가 협회

www.usabilityprofessionals.org

UPA (6월)

시작하자! 당신은 여기까지 해왔습니다. 처음에 이 책을 집어든 이유에 대해 알아볼 시간입니다. 페이지를 넘기고 프로젝트 영역 내에서 사용자 경험 디자인이 어떻게 존재하는지 자세히 살펴보십시오. 그러나 거기서 멈추지 마십시오. 이 책은 시작하는 데 도움이 되는 안내서입니다. 여기에는 귀하가 맡게 될 많은 활동을 수행하는 데 도움이 될 수 있는 많은 예가 있습니다. 또한 귀하의 팀과 고객에게 유용한 산출물을 생성하기 위한 최선의 접근 방식을 확장하고 찾는 데 도움이 되는 추가 예제를 제공하려고 노력했습니다. 호기심, 열정, 공감을 유지하세요! 이상적인 사용자 경험을 구축하도록 다른 사람들에게 영감을 줄 수 있는 새로운 방법을 찾기 위해 도전하십시오. 물론 개선을 시작하기 전입니다.

1장: UXD의 도

프로젝트 요구 사항, 역할 및 문화에 대한 프로젝트 생태계 계획 새로운 프로젝트를 시작하려고 합니까? 아니면 중간에 있습니까? 어느 쪽이든 잠시 시간을 내어 프로젝트의 역학과 컨텍스트, 즉 귀하와 나머지 프로젝트 팀에 영향을 미칠 문제를 고려하십시오. 어떤 유형의 사이트 또는 애플리케이션이 관련되어 있습니까? 어떤 역할과 기술이 필요합니까? 회사 문화는 무엇입니까? 이러한 질문에 답하면 프로젝트를 정의하고 궁극적으로 성공을 위해 필요한 도구와 기술을 결정하는 데 도움이 됩니다. 캐롤린 챈들러

이자형

각 프로젝트에는 고유한 문제가 있습니다. 웹 사이트나 응용 프로그램을 설계하는 경우 사용자가 온라인에서 친구 및 가족과 사진을 공유할 수 있는 방법을 구축하거나 인트라넷의 정보를 재구성하여 콘텐츠가 더 많이 표시될 수 있도록 하는 것과 같은 특정 기능과 관련된 문제가 많습니다. 쉽게 찾고 공유할 수 있습니다. 그러나 이러한 특정 설계 목표와 관련하여 모든 프로젝트에는 이해하고 계획에 통합해야 하는 더 큰 컨텍스트가 있습니다. 이 컨텍스트는 프로젝트의 "생태계"이며 작업 환경(회사 문화), 참여하게 될 일반적인 작업 유형(예: 디자인 중인 사이트 유형) 및 상호 작용할 사람들(역할 및 책임 포함). 시간을 들여 프로젝트 생태계를 이해한다면 프로젝트 전반에 걸쳐 도움이 될 지식을 갖게 될 것입니다. 자신의 책임과 아이디어를 보다 효과적으로 전달할 수 있으며 팀의 다른 사람들이 고려하지 않았을 수 있는 프로젝트 요구 사항을 예상하도록 도울 수 있습니다. 당신을 돕기 위해 이 장에서는 당신이 할 수 있는 다양한 유형의 프로젝트와 당신이 할 수 있는 역할, 당신이 의존할 수 있는 사람들, 그들의 참여가 디자인되는 사이트나 응용 프로그램의 유형에 따라 어떻게 다른지를 식별합니다. 마지막으로 이 장에서는 프로젝트 중 작업 방식에 영향을 줄 수 있는 회사 문화의 일부 요소에 대해 설명합니다. 참고 클라이언트 회사가 프로젝트를 구성하는 방식에 따라 특정 프로젝트에 둘 이상의 사이트 또는 응용 프로그램 디자인이 포함될 수 있습니다. 단순화를 위해 이 책에서는 프로젝트가 단일 유형의 사이트 디자인과 관련되어 있다고 가정합니다. 사이트가 두 개 이상인 경우 각 사이트를 개별적으로 고려하여 프로젝트 팀에서 올바른 역할을 담당하는지 확인하십시오.

사이트 유형 식별 한 사이트 유형과 다른 사이트 사이에 흑백 구분은 없지만 사이트 초점 및 특성에서 일부 상대적 차이를 식별할 수 있습니다. 이러한 유사점과 차이점을 이해하면 스스로 디자인 목표를 설정하는 데 도움이 될 수 있습니다. 이것들은 해결해야 할 일반적인 문제들입니다.

해결(예: "회사의 비즈니스 모델 설명") 또는 사이트의 시각적 디자인 및 상호 작용 디자인 내에서 표현해야 하는 속성(예: "고객에 대한 회사의 응답성 입증").

2장: 프로젝트 생태계

프로젝트의 주요 목표를 확고히 합니다(4장 참조). 어떤 부서 또는 비즈니스 단위가 될 수 있는지(또는 있어야 하는지) 이해

비즈니스 요구 사항을 수집할 때 참여합니다(5장 참조). 사용자 조사를 통합하기 위한 최선의 방법을 결정합니다(6장 참조). 관련된 시스템과 기술에 대해 질문하십시오.

귀하의 사이트는 아마도 다음 네 가지 유형 중 하나와 강력하게 연관될 것입니다.

브랜드 존재 - 회사와 일반 청중(제품 또는 서비스에 관심이 있는 모든 사람) 간의 관계를 촉진하는 지속적으로 존재하는 온라인 플랫폼 마케팅 캠페인 - 특정 청중 또는 제한된 기간 동안의 일반 청중 콘텐츠 소스 - 잠재적으로 사용자에게 정보를 제공하거나 참여시키거나 즐겁게 하기 위한 여러 유형의 미디어(기사, 문서, 비디오, 사진, 자습서)로 구성된 정보 저장소 작업 기반 응용 프로그램 - 사용자가 일련의 주요 작업 또는 워크플로우를 수행할 수 있도록 하는 도구 또는 도구 모음

다음 섹션에서는 이러한 각 유형을 자세히 살펴보고 해당 특성과 사이트 또는 응용 프로그램을 디자인하는 동안 문제에 미치는 영향에 대해 설명합니다. 또한 전자 상거래, 전자 학습 및 소셜 네트워킹과 같은 가장 일반적인 교차 프로젝트에 대해서도 논의할 것입니다.

브랜드 존재 누군가가 브랜드라는 단어를 말할 때 어떻게 생각하십니까? 종종 가장 먼저 떠오르는 것은 Nike Swoosh 또는 Coca-Cola 스크립트 엠블럼과 같은 회사 로고입니다. 그러나 회사의 브랜드는 로고 그 이상입니다. 특정인이 회사에 대해 갖는 전체 일련의 인상입니다.

사이트 유형 식별

Dirk Knemeyer는 "Brand Experience and the Web"이라는 기사에서 브랜드에 대한 훌륭한 정의를 제시합니다. 브랜드는 사람들이 회사, 제품 또는 사람과 맺는 지적 및 감정적 연관성을 나타냅니다. 우리 각자. 브랜딩 과학은 사람들의 마음을 위해 디자인하고 영향을 미치는 것, 즉 브랜드 구축에 관한 것입니다.

서핑 회사 브랜드에 대한 고객의 경험과 회사의 브랜드 구축 노력 간의 차이에 대한 자세한 내용은 "브랜드 경험과 웹"에서 Dirk Knemeyer의 설명을 참조하십시오. www.digital-web.com/articles/brand_experience_and_the_web. 사이트의 UX 디자인이 개인의 브랜드 경험에 어떻게 영향을 미칠 수 있는지에 대한 훌륭한 논의는 Steve Baty의 기사 "Brand Experience in User Experience Design"(www.uxmatters.com/MT/archives/000111.php)을 참조하십시오.

회사는 기억에 남는 광고 캠페인을 실행하는 것부터 웹 사이트의 기능과 디자인을 통해 브랜드 특성(예: "반응성" 또는 "가치")을 표현하는 것까지 브랜드와의 연관성에 영향을 미치기 위해 많은 일을 할 수 있습니다. 회사 내의 모든 사이트는 직접적으로(고객이 방문할 수 있는 사이트를 제시함으로써) 또는 간접적으로(고객 지원과 같이 고객이 의존하는 주요 서비스를 활성화함으로써) 회사 브랜드에 어느 정도 영향을 미칠 수 있습니다. 그러나 브랜드 존재 사이트는 회사의 브랜드 메시지와 가치를 제시하는 데 가장 중점을 둡니다. 그들은 고객과 직접 연결되는 채널을 제공하고 회사 또는 제품에 대해 더 많은 정보를 찾는 데 관심이 있는 사람들을 위한 광범위한 온라인 깔때기 역할을 합니다. 브랜드 존재 사이트는 종종 GE.com과 같은 회사의 기본 .com 또는 .org 사이트이거나 더 크고 분산된 회사의 경우 GEhealthcare.com과 같이 다양한 규모의 비즈니스 단위에 대한 기본 사이트입니다. 고유한 제품 라인은 종종 온라인에서 고유한 브랜드를 보유하고 있습니다. 예를 들어 Pepsico.com에는 하나의 브랜드가 있고 Pepsi.com에는 고유한 브랜드가 있습니다.

2장: 프로젝트 생태계

브랜드 존재 사이트에서 작업하는 경우 현재 및 잠재 고객, 투자자, 파트너, 미디어(예: 뉴스 조직 및 저명한 블로그 작성자) 및 작업을 포함하여 다양한 사용자 그룹을 위해 디자인할 것입니다. 찾는 사람.

공통 브랜드 존재 사이트 회사의 주요 홈 사이트(company.com, company.org, company.net 등) 회사의 주요 비즈니스 단위를 위한 사이트(종종

특정 산업, 지역 또는 대규모 제품군) 회사 내 주요 하위 브랜드 사이트

브랜드 존재감 디자인 목표 브랜드 존재감 프로젝트에서 종종 가장 중요한 디자인 목표는 다음과 같습니다. 회사의 브랜드 가치와 브랜드 메시지 전달,

명시적으로(아마도 고객 요구에 응답하는 것이 중요하다는 설명) 또는 사이트에 들어갈 때 전반적인 경험을 통해(예: 사이트가 제대로 작동하는지 확인하고 고객이 회사와 통신하도록 장려하는 기능을 눈에 띄게 제공하는지 확인). 회사 정보에 빠르고 쉽게 액세스할 수 있습니다. 당신은 원하는

"회사는 무엇을 하는 회사입니까?"라는 질문에 답하십시오. 및 "자세한 정보를 얻기 위해 다른 사람에게 어떻게 연락합니까?" 회사의 비즈니스 모델 및 가치 제안 제시 또는 설명:

"회사가 나를 위해 무엇을 할 수 있습니까?" 그리고 "회사는 어떻게 합니까?" 일련의 기본 사용자 그룹을 참여시키고 관련 상호 작용으로 안내합니다.

옵션, 기능 또는 콘텐츠. 회사가 다음과 같은 주요 지표에 대해 설정한 목표를 달성하도록 지원

고유 방문자 수. 종종 이것은 전반적인 마케팅 전략의 한 부분입니다. 나중에 "모자 선택" 섹션에서 브랜드 존재 사이트 디자인과 관련된 다양한 역할을 배우게 됩니다. 지금은 살펴 보겠습니다.

사이트 유형 식별

브랜드 사이트와 밀접한 관계가 있는 마케팅 캠페인 사이트를 포함하여 귀하가 작업할 수 있는 다른 유형의 사이트에서.

마케팅 캠페인 마케팅 캠페인 사이트는 회사 브랜드에 대한 인식에 영향을 미치는 경험을 통해 사용자 참여에 중점을 둔다는 점에서 브랜드 존재 사이트와 유사합니다. 그러나 마케팅 캠페인 사이트는 정해진 초점(예: 특정 기간 내 또는 대상 고객) 내에서 매우 구체적인 행동을 달성하는 능력으로 평가되는 경향이 있습니다. 관심을 끌기 위한 깔때기 역할을 하기보다는 관심을 불러일으키는 엔진이 되어야 합니다. 온라인 관점에서 이것은 일반적으로 전체 마케팅 전략과 일치하며 TV 또는 라디오 광고, 인쇄 광고 및 기타 프로모션과 같은 다른 채널을 사용하는 다른 마케팅 노력과 함께 실행될 수 있음을 의미합니다.

일반 마케팅 캠페인 사이트 특정 제안을 홍보하는 랜딩 페이지입니다. 페이지는 다음을 통해 도달합니다.

다른 페이지의 배너 광고. 특정 이벤트를 홍보하는 소규모 사이트(또는 마이크로사이트)입니다. 화제를 일으킬 목적으로 제작된 게임 또는 도구

또는 교통.

마케팅 캠페인 사이트의 주요 목적은 일반적으로 특정 메트릭 집합을 대상으로 하는 좁게 초점을 맞춘 캠페인을 만드는 것입니다. 초점은 종종 다음 중 하나 이상에 의해 좁혀집니다. 시간 - 예를 들어 이벤트를 중심으로 한 캠페인(예:

회의) 또는 시즌(예: 크리스마스 쇼핑 시즌) 사용자 그룹(예: 청소년 또는 교사를 대상으로 하는 캠페인) 제품, 제품군 및/또는 해당 제품의 특정 용도

예를 들어, 일치하는 오븐, 식기 세척기 및 스토브가 있는 가상 주방을 표시하여 주방 용품을 강조 표시하는 사이트

2장: 프로젝트 생태계

이러한 전략을 혼합하여 사용하는 캠페인은 파티오 장비 판매, 시간 및 제품군 결합을 목표로 하는 봄 캠페인이 될 것입니다. 제품군과 사용자 그룹의 혼합을 보여주는 예는 그림 2.1을 참조하십시오. 마케팅 캠페인 사이트는 회사의 .com 사이트에 있는 랜딩 페이지로 연결되는 배너 광고처럼 단순할 수도 있고, .com 사이트에서 명백한 브랜딩에서 종종 방향을 바꾸는 작은 사이트인 마이크로사이트일 수도 있습니다. 하나 이상의 초점 영역에 따른 맞춤형 경험. 여기에서 "소규모"는 상대적입니다. 일부 마이크로사이트는 한 페이지이고 다른 마이크로사이트는 페이지가 많지만 어느 쪽이든 마이크로사이트는 회사의 주요 브랜드 사이트보다 작고 집중도가 높습니다.

그림 2.1 Texas Instruments는 이 교육 중심 마이크로사이트(http://timathrocks.com/index.php)를 사용하여 회사의 그래프 계산기에 대한 정보를 제공합니다. 제품군은 주로 대수 수업에서 고등학생과 대학생이 사용합니다. 이 마이크로사이트는 Texas Instruments 브랜드와의 일반적인 관계를 유지하지만 젊은 청중을 끌어들이고 필요에 따라 콘텐츠와 기능을 구성하기 위해 의도적으로 구별됩니다.

마케팅 캠페인 디자인 목표 마케팅 캠페인 사이트의 디자인 및 구현을 담당하는 사람이나 팀에게 가장 중요한 디자인 목표는 다음과 같습니다.

가치 제안(신속한 대출 자격 가능성과 같이 제품이나 서비스가 사용자에게 제공하는 가치) 또는 일종의 인센티브(특별 제안, 콘테스트 참가 또는 온라인 게임과 같은 엔터테인먼트).

사이트 유형 식별

특정 작업을 불법화하기 위해 일련의 기본 사용자 그룹을 참여시키십시오.

예를 들어 브랜드 사이트의 특정 위치를 클릭하거나 뉴스레터에 가입하거나 대출을 신청할 수 있습니다. 사용자가 이 작업을 수행하면 이를 전환이라고 합니다. 수치와 같은 주요 지표에 대해 회사가 설정한 목표를 달성하도록 지원합니다.

순 방문자 수. 종종 이것은 전반적인 마케팅 전략의 한 부분입니다.

심층 분석 마케팅 캠페인을 지원하는 페이지 디자인에 대한 자세한 내용은 방문 페이지 최적화: 전환을 위한 테스트 및 조정을 위한 최종 가이드(Tim Ash, Sybex, 2008)를 참조하십시오.

콘텐츠 원본 콘텐츠 원본 사이트에는 잠재적으로 여러 유형의 미디어(기사, 문서, 비디오, 사진, 자습서)에 정보 저장소가 포함되어 있으며 사용자에게 정보를 제공하고 참여 및/또는 즐겁게 하기 위한 것입니다.

일반적인 콘텐츠 소스 사이트 회사의 인트라넷 조직 구성원을 위한 온라인 라이브러리 또는 리소스 센터 뉴스 또는 자주 제공하는 사이트 또는 사이트 영역

업데이트된 게시물(대형 상업 블로그가 이 범주에 속할 수 있음) 고객 지원 센터

물론 모든 사이트와 애플리케이션에는 일부 콘텐츠가 있지만 일부 사이트는 콘텐츠의 표현과 구조를 특별히 강조합니다. 강조는 사이트에 너무 많은 양의 콘텐츠가 있어 자체 문제를 제기하거나 특정 유형의 콘텐츠가 높은 중요성을 지니기 때문에 발생할 수 있습니다. 예를 들어 중요한 결정을 지원하거나 사용자를 사이트로 자주 다시 끌어들일 수 있습니다.

2장: 프로젝트 생태계

콘텐츠 원본 사이트의 주요 목적은 관련 콘텐츠(예: 인트라넷)를 제공하여 사용자 지식과 자립성을 높이는 것입니다. 그들은 종종 정보를 공유하거나 설명을 검토한 후 제품을 구매하는 것과 같은 일종의 행동을 권장합니다. 콘텐츠 원본 디자인 목표 콘텐츠 원본 사이트는 다음 중 하나 이상을 수행해야 하는 경우가 많습니다. 사이트를 처음 방문하거나 반복 방문할 때 가장 많이 찾는 콘텐츠를 제공합니다. 예를 들어 회사의 사고 리더십 역량을 보여줍니다.

CEO 또는 회사 내 다른 주제 전문가가 보유한 아이디어와 관점에 대한 액세스를 제공합니다. 사용자 기반 간의 중요한 결정을 지원합니다. 아이디어를 이끌어내어 회사의 기업 지식을 향상시킵니다.

개별 부서에 묻힐 수 있습니다. 이것은 혁신을 위한 더 많은 기회를 식별하기 위한 더 큰 목표의 일부일 수 있습니다. 다양한 방식으로 정보를 찾는 사용자를 지원합니다. 예를 들어,

일부는 자신에게 필요한 특정 제품이 무엇인지 아직 모르며(그리고 검색할 가능성이 더 높음), 다른 일부는 찾고 있는 것이 무엇인지 정확히 알고 있을 수 있습니다(검색 필드를 사용할 가능성이 더 높음).

서핑 사용자가 정보를 찾는 다양한 방법에 대한 자세한 내용은 Donna Spencer의 "Four Modes of Seeking Information and How to Design for Them"을 참조하십시오.

UX 디자인과 관련하여 콘텐츠 소스 프로젝트에서 가장 일반적인 작업 중 일부는 다음과 같습니다. 사용자의 멘탈 모델에 맞는 범주화 구조 생성 콘텐츠의 유기적 성장을 위한 시스템 통합 방법 결정

(예: 태깅 및 필터링과 같은 기능) 효과적인 검색 도구 설계 사이트 유형 식별

작업 기반 응용 프로그램 작업 기반 응용 프로그램은 모기지 사이트에 내장된 간단한 계산기에서 여러 중요 워크플로우를 처리하는 전체 시스템에 이르기까지 다양합니다. 프로젝트에 후자와 관련된 경우 더 많은 역할이 관련되고 대부분 상당한 요구 사항 수집 프로세스가 있을 것입니다(이 프로세스에 대한 자세한 내용은 5장 참조).

일반 작업 기반 응용 프로그램 특정 유형의 작업 생성을 지원하는 소프트웨어 응용 프로그램

항목(예: 스프레드시트 또는 인쇄 조각)

pany (such as a ticket-management application for an IT support group or a customer tracking application for a call center) A Web site that allows for access to, and management of, personal data

(예: 플리커)

작업 기반 애플리케이션의 주요 목표는 사용자가 자신의 요구 사항과 궁극적으로 클라이언트의 비즈니스 목표에 부합하는 일련의 작업을 수행할 수 있도록 하는 것입니다. 작업 기반 응용 프로그램 설계 목표 대부분의 작업 기반 응용 프로그램은 사용자가 다른 곳에서는 할 수 없는 일을 할 수 있도록 해야 합니다.

더 잘하기 위해("더 나은"은 더 높은 수준의 만족과 함께 더 효율적이고 더 효과적으로, 또는 더 편리함을 의미할 수 있음)

핵심 업무의 집중화 바로가기 기능으로 중급 및 고급 사용자 지원

보다 심화된 기능 사용자의 부담을 줄이고 시스템 리소스를 최대한 활용

(예: 데이터 재사용 대 중복 항목 요구)

2장: 프로젝트 생태계

필요한 변경 정도에 주의를 기울여 설계 및 배포

학습을 용이하게 하는 디자인과 사용자에게 가치를 입증하는 커뮤니케이션 계획이 있는 애플리케이션 사용자의 작업 기반 애플리케이션 설계의 가장 큰 과제 중 하나는 "기능 추가"를 제어하는 것입니다. 프로젝트를 개발할 때 디자인의 후반 단계나 개발 중에 훌륭한 아이디어가 떠오르는 것은 매우 일반적입니다. 사용자 경험 디자인은 페르소나와 같은 사용자 모델을 사용하여 가치가 높은 기능을 식별하고 프로젝트 전체에 집중할 수 있기 때문에 기능 크립을 방지하는 데 매우 적합합니다. 진정으로 훌륭한 아이디어가 프로세스 후반에 나오고 우선순위가 높은 사용자 그룹의 요구 사항을 충족하고 사이트의 비즈니스 목표와 일치한다면 팀은 방향을 바꿀 수 있는 사례를 만들 수 있습니다. 아이디어가 시련을 통과할 수 없다면 지연과 비용을 들일 가치가 없을 수 있습니다.

전자 상거래 사이트 전자 상거래 사이트는 주로 전자 상거래를 목적으로 하는 사이트가 고유한 브랜드를 보유하고 콘텐츠(일반적으로 제품 사양 또는 제품 사용 설명)를 제공하고 작업을 용이하게 합니다(검색, 비교, 리뷰 작성, 체크아웃). 마케팅 캠페인은 종종 이러한 사이트에도 밀접하게 연결되어 있으며 조직 내 여러 마케팅 그룹이 포함될 수 있습니다. 전자 상거래 사이트의 일반적인 추가 디자인 목표는 비표준 사이트인 경우 사이트의 모델을 설명하는 것입니다. 온라인 마켓플레이스로

지속적으로 재인식되고 있으므로 이 설명은 기대치를 설정하는 데 도움이 될 것입니다(예: eBay, Amazon 및 Craigslist는 모델이 매우 다릅니다). 사용자가 학습에서 고려로 이동할 때 의사 결정을 지원합니다.

비교에서 구매로, 유용한 콘텐츠와 기능으로 교차 판매 및 상향 판매가 이루어지는 경험의 포인트를 활용하십시오.

방해하지 않고 눈길을 끄는 방식으로 이러한 제안을 배치합니다. 구매 시점부터 다음을 통한 커뮤니케이션 흐름 생성

배달 지점. 커뮤니케이션은 사이트 내에서뿐만 아니라 배송 추적 시스템과의 통합 및 주문 상태에 대한 이메일 커뮤니케이션과 같은 다른 채널과도 이루어져야 합니다. 사이트 유형 식별

E-Learning 애플리케이션 E-Learning 애플리케이션은 콘텐츠 소스와 작업 기반 애플리케이션 간의 크로스오버입니다. 수업용 콘텐츠를 생성해야 하며, 이를 위해 종종 팀이 다루는 주제에 대해 학습 전문가 및 주제 전문가(SME)의 역할을 추가해야 합니다. 제품은 일반적으로 사용자가 수업을 통해 흐름을 따르고 진행 상황을 추적하거나 관련 항목을 탐색해야 할 수도 있다는 점에서 작업 기반입니다. 일부 실습 수업에는 작업을 완료해야 할 수도 있습니다. 일반적인 설계 목표는 다음과 같습니다. 과정을 시작하는 데 필요한 기본 지식에 대한 이해 설정

그리고 누구를 대상으로 하는지. 에 맞게 조정 가능한 관리 가능한 단위로 콘텐츠 제공

이해력. 실습 학습을 시뮬레이션하는 활동에 학습자를 참여시키십시오. 성과와 진행 상황을 전달하고 해당되는 경우 제안

고급 과정과 같은 교육 과정을 계속하기 위한 다음 단계.

소셜 네트워킹 애플리케이션 소셜 네트워킹 애플리케이션은 사용자가 친구를 찾고 추가하고, 프로필을 관리하고, 연결하고, 게시하고, 검색할 수 있어야 하기 때문에 기본적으로 작업 기반 애플리케이션입니다. 또한 콘텐츠 소스와 관련된 문제, 특히 잠재적으로 매우 많은 양의 사용자 생성 콘텐츠를 처리할 수 있는 유기적 프레임워크에 대한 필요성도 포함합니다. 본질적으로 사이트에 자체 아이덴티티가 부여되면 브랜드 존재 사이트의 특성도 갖게 됩니다.

스노클링 소셜 네트워킹 애플리케이션에서 작업하거나 소셜 기능을 다른 유형의 사이트에 통합하려는 경우 이 책이 도움이 될 것입니다. 소셜 웹을 위한 디자인, Joshua Porter(New Riders, 2008).

2장: 프로젝트 생태계

소셜 네트워킹 애플리케이션의 일반적인 디자인 목표는 잠재 사용자를 네트워크의 목적과 가치에 집중시키는 것입니다. 지원하는 사용자 간의 의미 있는 상호 작용을 촉진하고

제공되는 기능(예: 이미지 공유, 비디오 공유 및 토론)에서 지원합니다. 네트워크 내의 사람들이 아래에 있는지 확인하여 사이트의 무결성을 보호하십시오

자신의 정보를 통제하고 부적절한 행동에 대응하는 방법을 서십시오. 기능을 발전시키기 위해 커뮤니티의 힘을 활용하고 보여줍니다.

인기 기능, 리뷰 등 활성 회원이 있어야만 가능한 기능입니다. 프로젝트 중에 작업할 수 있는 사이트 또는 애플리케이션의 유형을 식별하는 것은 첫 번째 단계에 불과합니다. 다음으로, 종종 필요한 다양한 역할과 프로젝트 유형에 따라 이들의 참여가 어떻게 달라질 수 있는지 고려해야 합니다.

모자 선택 프로젝트에서 UX 디자이너가 되면 종종 여러 역할을 수행해야 합니다. 클라이언트 조직 내에서 공식적으로 정의되었는지 여부에 관계없이 수행할 역할은 프로젝트 유형과 나머지 팀 구성, 각각에 대한 클라이언트의 경험에 따라 다릅니다. 어떤 역할을 맡는 것이 편안하고 어떤 역할을 업무에서 배울 수 있다고 생각하는지 아는 것이 좋습니다. 또한 이러한 역할이 담당하는 책임에 대해 다른 사람들이 가질 수 있는 기대치를 알아내는 것도 도움이 됩니다. 이러한 이해를 통해 프로젝트 시작부터 자신을 보다 명확하게 표현할 수 있습니다. UX 디자이너에게 기대되는 가장 일반적인 역할은 무엇입니까? 귀하가 근무하는 각 클라이언트 회사는 해당 역할에 대해 다른 직함을 가질 수 있습니다(또는 조직의 공식적인 업무가 아닌 경우 이름이 전혀 없음). 일반적으로 정보 설계자, 인터랙션 디자이너, 사용자 연구원의 빅 3를 만날 수 있습니다. 참고 여러 개인 간에 이러한 공통 역할을 분할할 수 있는 규모나 예산을 가진 회사는 거의 없습니다. 프로젝트를 정의할 때 역할 이름을 염두에 두되 클라이언트와 대화할 때 요구 사항과 책임에 대해 말하십시오. 그렇지 않으면 그들은 당신이 매우 큰 팀을 구성하고 있다고 생각할 수 있습니다! 직함보다 책임에 초점을 맞추는 것도 제정신을 유지하는 데 도움이 됩니다. 이러한 역할 중 몇 가지를 수행하고 있다고 해서 반드시 많은 사람의 일을 하고 있다는 의미는 아닙니다. 프로젝트.

모자를 선택하세요

정보 설계자 정보 설계자는 정보 구조에 대한 모델을 만들고 이를 사용하여 사용자 친화적인 탐색 및 콘텐츠 분류를 설계하는 일을 담당합니다. 사이트 및 응용 프로그램을 디자인하는 동안 일반적인 책임에는 자세한 사이트 맵을 만들고(10장에서 설명) 정보의 범주 및 하위 범주가 뚜렷하고 사용자에게 친숙하도록 보장하는 것이 포함됩니다. 기대치 이해하기 UX 분야에서는 정보 설계자와 인터랙션 디자이너의 역할이 구분됩니다(다음에 설명). 그러나 특정 회사에서는 적어도 특정 프로젝트에 대한 요구 사항에 관해서는 두 역할 사이에 공통적인 구분이 거의 없습니다. 예를 들어, 정보 설계자라는 직함을 가진 팀에 속하게 될 수 있습니다. 그 직책이 귀하의 책임에 맞는지 여부에 관계없이 역할에 대한 역사적 용어이기 때문입니다. 주어진 직함이 현재 맡고 있는 주요 역할과 일치하지 않는 경우 프로젝트 팀을 수정해야 합니까? 이것이 단기 프로젝트(예: 4개월 이하)이고 귀하가 보유한 직함이 조직 내에서 널리 인정되고 명확한 책임이 명시되어 있는 경우 변경하려고 시도하는 잠재적인 혼란을 감수할 가치가 없을 수 있습니다. . 그러나 널리 받아들여지는 직함이 없고 잠재적으로 다른 사람들이 두 역할을 모두 대표해야 할 가능성이 있다고 생각한다면 참여 및 커뮤니케이션을 계획할 때 프로젝트 초기에 구분할 가치가 있습니다. 귀하의 책임. 본질적으로 작업 기반 애플리케이션의 경우 인터랙션 디자이너의 역할을 강조하는 것이 타당하고 콘텐츠 기반 프로젝트의 경우 정보 설계자의 역할을 강조하는 것이 타당합니다. 그러나 무엇보다 가장 의미 있는 것은 클라이언트 조직에 친숙한 용어를 사용하고 팀이 맡은 책임과 관련하여 역할을 정의하는 방법을 이해하도록 하는 것입니다. 이 정의는 작업 기술서에서 명확히 하고 싶은 것입니다(3장 참조). 정보 설계자의 책임은 콘텐츠 전략가의 책임과 모호할 수도 있습니다(아래의 "기타 역할" 참조). 이러한 역할이 있는 경우

2장: 프로젝트 생태계

프로젝트 팀의 다른 사람들로 대표되는 경우 프로젝트 시작 시 협업 방법에 대해 논의해야 합니다.

인터랙션 디자이너 인터랙션 디자이너는 사용자 작업에 따라 사이트 또는 애플리케이션의 동작을 정의하는 일을 담당합니다. 여기에는 여러 보기에 걸친 사이트의 흐름과 특정 보기 내의 상호 작용이 포함됩니다. 사이트 또는 응용 프로그램을 디자인하는 동안 일반적인 활동은 사이트 내의 페이지 또는 구성 요소 간의 상호 작용을 보여주는 작업 흐름을 만들고(10장 참조) 동적 메뉴 및 확장 가능한 콘텐츠 영역과 같은 페이지 내 상호 작용을 보여주는 와이어프레임을 만드는 것입니다(10장 참조). 11). 기대 이해 소규모 팀에서 작업하거나 새로운 작업 기반 기능을 만드는 데 크게 집중하지 않는 프로젝트에서 작업하는 경우(예: 주로 일부 콘텐츠 범주를 포함하는 브랜드 존재 사이트에서 작업하는 경우 연락처 양식 및 뉴스레터 가입 양식) 인터랙션 디자이너는 프로젝트 요구 사항을 파악하는 주요 역할을 담당할 수 있습니다(5장 참조). 높은 수준의 새 기능이 포함된 프로젝트에서 인터랙션 디자이너로 작업하는 경우 팀에서 세부 요구 사항의 개요를 담당하는 별도의 사람(예: 비즈니스 분석가 또는 제품 관리자)이 있을 가능성이 큽니다. 기능적 요구 사항을 수집하고 세부적으로 설명하는 프로세스는 UX 디자이너의 기술에 의해 크게 도움이 될 수 있으며 기능 사양 및 사용 사례와 같은 문서는 경험 디자인의 영향을 받습니다. 요구 사항 수집 담당자와 함께 가장 잘 협력할 수 있는 방법에 대해 논의하십시오.

사용자 조사자 사용자 조사자는 자신이 사용자와 수행한 조사에서 생성되거나 검증된 정보를 기반으로 최종 사용자의 요구 사항에 대한 통찰력을 제공할 책임이 있습니다. 사용자 조사 범주에 속할 수 있는 많은 유형의 활동이 있으며 프로젝트 타임라인의 여러 지점에서 발생할 수 있습니다. (사용자 인터뷰, 설문 조사 및 사용성 테스트와 같은 일반적인 기술에 대한 설명은 6장을 참조하십시오.)

모자를 선택하세요

기대치 이해 사용자 조사에 대한 클라이언트 회사의 욕구는 프로젝트 팀 또는 프로젝트 스폰서가 부여한 중요성에 따라 크게 다를 수 있습니다. 프로젝트가 시작되기 전에 프로젝트 스폰서와 UX 디자인에 대해 이야기하고 있다는 사실은 클라이언트 팀의 누군가가 사용자 요구 사항을 표현하는 것이 우선 순위임을 알고 있음을 보여줍니다. 그러나 컴퓨터 기반 프로젝트에 참여해 본 사람들은 알다시피 연구 도입은 프로젝트 팀원들 사이에 불안을 야기할 수도 있습니다. 그것을 고치기 위해 큰 변화를 가하는 것?), 또는 많은 추진력을 얻은 특정 아이디어의 가치를 반증하는 것입니다. 사용자 조사에 대한 기대치는 비즈니스 이해 관계자와 프로젝트 팀 간에 다를 수 있으므로 두 그룹 모두에서 역할에 대한 기대치를 명확히 해야 합니다. 고객은 또한 사용자 리서치가 사이트 분석(자주 방문하는 페이지 및 사용자가 사이트를 떠나는 공통 지점 등 사이트에서 사용 패턴을 전달하는 도구 및 보고서)을 기반으로 통찰력을 제공할 것을 기대할 수 있습니다. 가장 일반적인 분석 도구 중 일부는 Google(www.google.com/analytics), WebTrends(www.webtrends.com) 및 Omniture(www.omniture.com/en/products/web_analytics)에서 제공합니다. 정보 설계자, 인터랙션 디자이너, 사용자 연구원의 세 가지 역할을 모두 맡게 될 수도 있습니다. 세 가지 모두 균형을 잡을 수 있습니까, 아니면 씹을 수 있는 것보다 더 많이 물어뜯고 있습니까? 부분적으로는 프로젝트의 규모와 일정에 따라 다르지만 프로젝트 유형도 각 역할의 참여 정도에 영향을 미칩니다. 표 2.1은 UX 디자인 역할이 프로젝트 유형에 따라 어떻게 달라질 수 있는지 설명합니다.

서핑 UX 디자인에 대한 사례를 만들어야 합니까? 다음 문서는 도움이 될 수 있는 접근 방식을 제공합니다. "기업의 필수 요소로서의 사용자 경험", Mir Haynes 저: www.hesketh.com/publications/user_experience.pdf "Evangelizing User Experience Design on Ten Dollars a Day," 저, Louis Rosenfeld: http:/ /louisrosenfeld.com/home/blog_archive/000131.html

2장: 프로젝트 생태계

표 2.1

UX 디자인 역할의 공통 책임

정보 설계자

브랜드 존재

마케팅 캠페인

콘텐츠 소스

작업 기반 애플리케이션

중간 참여.

소규모 사이트(단일 랜딩 페이지 등)에 대한 참여도가 낮습니다. 규모가 더 큰 마이크로사이트에서 작업하는 경우 참여도가 중간입니다.

참여도가 매우 높습니다. 컨텐츠 소스는 구조와 유연성이 적절하게 균형을 이룬 정보 아키텍처를 필요로 하여 사용자가 견실한 기반을 제공하고 계획된 성장을 허용합니다.

일부 워크플로 중에 참조해야 하는 더 큰 콘텐츠 영역이 없는 한 주로 탐색 프레임워크를 만드는 데 중점을 둔 중간에서 높은 참여도입니다.

소규모 사이트의 경우 참여도가 낮고 대규모 마이크로사이트 또는 광고 게임(플레이 및 입소문을 생성하기 위한 후원 온라인 게임)의 경우 중간에서 높은 참여도입니다.

중간에서 높은 참여.

참여도가 매우 높습니다. 이러한 종류의 프로젝트는 인터랙션 디자인 산출물(예: 사용자 프로세스 흐름 및 와이어프레임)이 요구 사항을 시각적으로 전달하는 데 핵심이기 때문에 가장 힘든 작업이 필요한 경우가 많습니다.

종종 캠페인의 일시적인 특성으로 인해 사용자 참여가 경미한 경우가 많습니다. 보다 영구적인 솔루션은 브랜드 존재 사이트와 유사한 조사를 사용할 수 있습니다. 분석 도구를 사용하여 특정 페이지의 변형을 두 개 이상 제시하여 가장 많은 전환을 유도하는 페이지를 확인하는 것도 일반적입니다. 이를 A/B 테스트라고 합니다.

상황별 조사와 같은 현장 조사는 팀이 현재 다양한 사용자가 정보를 사용하는 방법을 이해하는 데 도움이 될 수 있습니다.

콘텐츠 챌린지가 클수록 프로젝트는 콘텐츠 소스와 비슷해집니다.

인터랙션 디자인

중간 참여. 작업 수가 많을수록 프로젝트는 작업 기반 응용 프로그램과 비슷해집니다.

사용자 연구원 참여는 예산과 사용자 액세스에 따라 달라집니다. 다음은 각 프로젝트 유형에 대한 일반적인 기술입니다. 이러한 각 기술에 대한 자세한 내용은 6장을 참조하십시오.

연구 노력은 (설문 조사 또는 인터뷰를 통해) 우선 사용자 그룹의 요구를 이해하는 데 초점을 맞추거나 올바른 브랜드 메시지를 전달하는 데 있어 특정 시각적 디자인의 효과를 테스트하는 디자인 연구에 집중할 수 있습니다.

검색, 태깅 및 필터링 기능은 정보 아키텍처와 인터랙션 디자인 사이의 경계를 넘습니다. 콘텐츠 소스에는 콘텐츠 생성 및 관리와 관련된 워크플로가 있을 수도 있습니다.

카드 정렬은 사용자가 정보와 일반적인 패턴 및 정신 모델을 그룹화하는 방법을 이해하는 훌륭한 방법입니다.

사용자가 현재 완료하고 있는 작업을 이해하기 위해 컨텍스트 조회와 같은 현장 조사를 수행할 수 있습니다. 그러나 작업 기반 응용 프로그램의 디자인에 사용자를 참여시키기 위해 가장 자주 사용되고 가장 잘 이해되는 기술은 사용성 테스트입니다.

프레임워크가 설정되면 사용성 테스트를 통해 구조를 검증할 수 있습니다.

모자를 선택하세요

수행할 수 있거나 필요할 수 있는 기타 역할 여러 역할은 일반적으로 UX 디자이너의 역할에 속하지 않지만 이러한 역할의 책임은 종종 UX 디자인 역할과 중복됩니다. 특히 아무도 공식적으로 역할을 수행하지 않는 프로젝트에서 작업하는 경우 그리고 당신은 테이블에 가져올 기술이 있습니다. 보다 일반적으로 중복되는 역할은 다음과 같습니다. 브랜드 전략가 또는 관리인 비즈니스 분석가 콘텐츠 전략가 카피라이터 비주얼 디자이너 프런트 엔드 개발자

다음 섹션에서는 이러한 각 역할을 자세히 살펴보고 설계 중인 사이트 유형에 따라 역할이 어떻게 달라질 수 있는지 설명합니다. 브랜드 전략가 및 브랜드 스튜어드 브랜드 전략가는 브랜드 가치(예: "반응성")에서 카피 및 메시지에 대한 지침에 이르기까지 모든 것을 포함할 수 있는 회사 브랜드 요소의 정의 및 일관된 표현을 통해 주요 시장과의 관계를 구축하는 일을 담당합니다. 로고 처리, 색상 및 레이아웃에 대한 사양. 이 역할은 종종 브랜딩 가이드라인을 만들거나 대표하고 다양한 프로젝트에 적용하는 방법을 이해하는 것을 수반합니다. 또한 작업 중인 프로젝트에서 중요한 대상 고객을 알고 정의하는 것도 포함될 수 있습니다. 대부분의 경우 브랜드 전략가와 함께 일하지만 스스로 책임을 지지는 않을 것입니다. 브랜드 스튜어드는 반드시 가이드라인을 설정하지는 않지만 프로젝트 중에 적절하게 준수되도록 할 책임이 있습니다. 이 책임은 프로젝트의 UX 디자이너 또는 시각 디자이너에게 주어질 수 있습니다. 회사의 브랜드 속성, 가치 및 가이드라인이 이미 잘 정의되어 있고 사이트에서 이를 따를 것으로 예상되는 경우 프로젝트의 브랜드 관리인으로서 귀하의 역할은 주로 결과가 이러한 가이드라인에 부합하도록 하는 것입니다. 프로젝트 외부의 접점은 아마도

2장: 프로젝트 생태계

상담 또는 검토가 가능한 마케팅 부서의 구성원이지만 풀타임으로 팀에 속해 있지는 않습니다. 브랜드 스튜어드 역할은 사이트가 예를 들어 새로운 시장을 목표로 브랜드를 확장하려는 경우 더 활발할 수 있습니다. 완전히 새로운 브랜드 존재가 만들어지거나 회사가 브랜드에 극적인 변화를 일으켜 효과적으로 자체 브랜드를 변경할 때 가장 관련이 있습니다. 예를 들어 CellularOne은 기존 회사의 주요 노력인 Cingular로 완전히 브랜드를 변경했습니다. 그런 상황에서 당신은 브랜드 개발에 매우 경험이 많거나 회사의 사람과 명확하고 긴밀한 관계를 구축해야 합니다. 브랜드 관련 역할에 대한 기대치를 이해하는 데 도움이 되는 주요 질문은 다음과 같습니다. 브랜드 가이드라인이 이미 존재합니까? 그렇다면 이 프로젝트를 위해 얼마나 밀접하게 준수해야 합니까? 브랜드 메시지, 브랜드를 설정하거나 유지하는 책임자

모양과 느낌, 콘텐츠의 톤(예: 캐주얼 또는 전문)? 이전에 다루지 않은 새로운 잠재고객을 타겟팅할 예정입니까?

브랜드 정의? 그렇다면 브랜드 가이드라인이 해당 청중에게 여전히 적절한지 확인하는 책임은 누구에게 있습니까? 명명 또는 이름 변경 활동이 있습니까? 그렇다면 어떻게 계획해야 할까요?

관련된? (예를 들어 크게 홍보할 새 도구의 이름을 만드는 것입니다.) 내부 애플리케이션 개발, 브랜드 스튜어드 참여와 같이 브랜드에 대한 고객의 인식에 잠재적으로 큰 영향을 미치지 않는 프로젝트의 경우 브랜드가 잘 표현되고 있는지 확인하기 위해 가끔 확인하는 것만큼 가벼울 수 있습니다. 비즈니스 분석가 비즈니스 분석가(IT 프로젝트의 비즈니스 시스템 분석가라고도 함)는 주요 비즈니스 이해 관계자를 식별하고 요구 사항 수집 프로세스를 주도하며(5장 참조) 비즈니스 이해 관계자와 기술 간의 주요 연락 담당자 역할을 담당합니다. 팀. 필요한 경우 기능 사양 및 사용 사례와 같은 세부 요구 사항 문서의 기본 소유자이기도 합니다.

모자를 선택하세요

비즈니스 분석가 또는 제품 관리자의 역할은 프로젝트에 전혀 존재하지 않거나 디자인 프로세스에서 가장 중요한 역할 중 하나일 수 있습니다. 작업 기반 애플리케이션과 콘텐츠 소스는 종종 이러한 종류의 역할을 합니다. 브랜드 존재 프로젝트 및 마케팅 캠페인은 그렇지 않을 수 있습니다. 작업 기반 애플리케이션에 이 역할이 필요할 가능성이 높습니다. 기능이 많고 프로젝트가 복잡할수록 전담 인력과 기능 문서화에 대한 요구 사항도 커집니다. 비즈니스 분석가는 일반적으로 UX 팀의 구성원으로 간주되지 않지만 소규모 UX 팀이 역할을 수행하도록 요청받는 경우가 많으므로 이러한 책임이 어디에 있는지 이해하는 것이 중요합니다. 비즈니스 분석가는 기술 팀과 주요 비즈니스 이해 관계자 간의 연락 담당자 역할을 하면서 비즈니스 요구 사항을 파악합니다. 프로젝트에 비즈니스 분석가가 있는 경우 해당 사람과 인터랙션 디자이너는 종종 함께 합류합니다. 같은 역할이라면 담당자가 따라잡아야 할 문서가 많을 수 있습니다! 이 영역의 기대치를 이해하려면 프로젝트 범위 개요, 요구 사항에 대한 논의 촉진, 프로젝트 전체에서 요구 사항 문서화를 담당할 담당자를 물어보십시오. 소규모 프로젝트나 기능이 많지 않은 프로젝트의 경우 프로젝트 관리자가 이러한 책임을 맡는 경우가 있습니다. 어느 쪽이든 귀하가 아닌 경우 결과물을 동기화하기 위해 가까이 있어야 할 사람을 여전히 알 수 있습니다. 콘텐츠 전략가 콘텐츠 전략가는 다양한 미디어(기사, 문서, 사진 및 비디오)의 콘텐츠에 대한 비즈니스 및 사용자 요구 사항을 이해하고 기존 콘텐츠의 격차를 식별하며 워크플로우를 촉진하고 새로운 콘텐츠를 개발하는 일을 담당합니다. 콘텐츠 관련 노력은 종종 과소평가됩니다. 클라이언트는 하나의 매체(예: 인쇄 브로셔 또는 비디오)에 멋진 많은 양의 콘텐츠를 가지고 있을 수 있지만 해당 콘텐츠는 작업 중인 프로젝트에 적합하지 않을 수 있습니다. 또한 때때로 클라이언트 조직 내의 사람들이 콘텐츠를 생성할 것이라는 무언의 기대가 있습니다. 이러한 기대는 설명, 뉴스 및 도움말 항목으로 제품을 채울 때가 되면 해당 사람들에게 놀라운 일이 될 수 있습니다! 양질의 콘텐츠라면

2장: 프로젝트 생태계

프로젝트의 주요 비즈니스 동인인 경우 다음을 담당하는 사람이 누구인지 확인하십시오. 새 제품에 대한 콘텐츠 지침 설정(콘텐츠 유형,

톤, 양). 기존 콘텐츠의 적합성 평가

지침. 새로운 콘텐츠를 개발하고 있습니다. 이는 일반 프로젝트 유형에 따라 다릅니다. 을 위한

작업 기반 응용 프로그램에는 지침 문구, 오류 메시지 및 도움말 항목이 포함될 수 있습니다. 콘텐츠 소스의 경우 기사, 뉴스 항목 및 블로그 게시물이 포함될 수 있습니다. 이해 관계자-기술 팀 연락 담당자 역할을 하여

콘텐츠 관리 시스템의 한계와 가능성. 서로 다른 콘텐츠 유형과 각각의 메타데이터 정의(

궁극적으로 검색 및 상호 참조를 보다 효과적으로 만드는 정보). 템플릿 생성과 관련된 콘텐츠 마이그레이션 계획

다양한 콘텐츠 유형에 대해 사이트의 콘텐츠 관리 시스템으로 이동할 때 콘텐츠에 태그가 지정되고 제대로 로드되는지 확인합니다. (이는 필요한 노력이 종종 과소평가되는 또 다른 영역입니다.) 카피라이터 카피라이터는 전체 경험을 구성하는 사이트에 텍스트를 작성하는 일을 담당합니다. 경우에 따라 이 사본은 날마다 상당히 변경되지 않은 상태로 유지됩니다. 일반적으로 사이트 및 페이지 소개 또는 페이지 내 지침이 포함됩니다. 카피라이터는 뉴스 스토리나 마케팅 캠페인용 카피와 같은 동적 콘텐츠의 지속적인 생성에도 관여할 수 있습니다. 카피라이팅은 특히 와이어프레임이 생성되는 경우 UX 디자이너에게 종종 해당되는 회색 영역 중 하나입니다(11장 참조). 처음에는 사이트 설명이나 페이지 내 지침과 같은 사본의 자리 표시자 역할을 하기 위해 샘플 텍스트를 넣을 수 있지만 결국 누군가가 사용자에게 표시될 최종 텍스트로 채워야 합니다. 전용 카피라이터인 경우 이 작업은 기본적으로 귀하에게 주어질 수 있습니다. 브랜드 존재 사이트 또는 마케팅 캠페인의 유명 영역에서 카피라이터 역할을 맡도록 요청받을 가능성이 적습니다. 그 상황에서

모자를 선택하세요

각 단어는 면밀한 조사를 받을 수 있습니다. 그러나 짧은 지침 메시지, 오류 메시지 또는 반드시 명확한 콘텐츠 버킷에 속하지 않는 기타 유형의 정보가 필요한 작업 기반 애플리케이션에서 작업하는 경우 해당 쓰기 작업을 상속받게 될 수 있습니다(또는 기본적으로 개발자에게 속함). 카피라이터를 사용할 수 있는지 미리 물어보고, 와이어프레이밍을 할 때 찾지 못한 경우 다시 물어보세요. 작업이 귀하에게 해당되는 경우 프로젝트 중 활동을 계획할 때 해당 노력을 포함해야 합니다. 그리고 미리 경고하십시오. 이것은 종종 생략되거나 과소 평가되는 책임입니다. 비주얼 디자이너 비주얼 디자이너는 사용자에게 표시되는 사이트 또는 애플리케이션의 요소를 담당합니다. 이러한 노력에는 브랜드 가이드라인에 따라 사용자와 감정적인 연결을 생성하는 모양과 느낌을 디자인하는 것이 포함됩니다. 예를 들어 은행 사이트는 종종 안정적이고 신뢰할 수 있으며 액세스할 수 있어야 합니다. 시각적 디자인은 색상 및 이미지와 같은 시각적 요소를 통해 이러한 확신을 줄 수 있습니다. 그 약속은 사이트의 인터랙션 디자인과 회사와의 다른 접점(예: 콜 센터)에 의해 유지(또는 파기)됩니다. 솔직히 말해서 많은 사람들이 자신을 비주얼 디자이너, 웹 디자이너 또는 그래픽 디자이너라고 부르며 많은 사이트의 비주얼 디자인이 형편없거나 무난합니다. 효과적이고 몰입감 있고 감성적인 시각적 디자인을 만드는 것과 그냥 지나치는 것 사이에는 큰 차이가 있습니다. 때때로 프로젝트 목표를 달성하기에 충분하며 프로젝트 스폰서가 만족하지 않거나 초기 사용자가 디자인에 참여하지 않을 때 프로젝트 좌절과 지연으로 이어집니다. 반면에 시각적 디자인으로 임팩트를 만드는 데 너무 집중하기 쉬워 디자인의 유용성이 저하될 수 있습니다. 이 역할을 맡아 달라는 요청을 받았고 고객에게 올바른 영향을 미칠 수 있는 자신의 능력이 확실하지 않은 경우 회사의 현재 사이트와 고객이 시각적인 관점에서 존경하는 사이트 또는 제품을 살펴보고 편안함을 평가하십시오. 수준. 시각 디자이너는 종종 브랜드 존재 프로젝트 및 마케팅 캠페인에서 매우 중심적인 역할을 하며 회사의 브랜드를 효과적으로 전달하는 주요 역할을 담당합니다.

2장: 프로젝트 생태계

콘텐츠 소스 프로젝트의 경우 많은 페이지에 적용할 수 있는 콘텐츠 템플릿(예: 기사 템플릿)을 만드는 데 집중할 수 있습니다. 작업 기반 응용 프로그램의 경우 탐색 영역 및 도구(상호 작용 디자이너와의 높은 수준의 공동 작업이 필요함)와 같은 일반적인 상호 작용 요소에 적용할 수 있는 스타일 가이드를 제공할 수 있습니다. 프런트 엔드 개발자 프런트 엔드 개발자는 롤오버 메뉴, 확장 가능한 콘텐츠 영역, 비디오와 같은 멀티미디어 요소와의 상호 작용과 같은 사이트 내의 대화형 요소뿐만 아니라 페이지 디자인 및 흐름 뒤에 있는 기술 구조를 구축하는 일을 담당합니다. 이 작업은 종종 XHTML, CSS, Flash, JavaScript, Ajax 및 Silverlight와 같은 기술을 사용합니다. 프런트엔드 개발은 기본 플랫폼을 제공하는 백엔드의 시스템(예: 데이터베이스, 콘텐츠 관리 시스템 및 복잡한 기능 뒤의 기능). 귀하 또는 귀하의 팀 구성원이 프런트 엔드 개발자의 역할을 맡고 있는 경우 나머지 개발 팀과의 긴밀한 협력은 기대와 책임을 이해하는 데 중요합니다. 다른 중요한 질문에는 통합해야 하는 백엔드 시스템, HTML 생성에 사용되는 방법, 사용자 지정 "스킨"을 수용하기 위한 페이지 구조의 유연성 필요성, Flash와 같은 기술에 대한 기대치가 포함됩니다. 프로토타입을 계획 중인 경우(12장 참조) 프로토타입 개발 책임자는 누구이며 예상되는 기능 수준은 어느 정도인지 물어보십시오. 단순히 가능성을 전달하기 위한 프로토타입은 Flash와 같은 애플리케이션에서 신속하게 생성할 수 있지만 실제 데이터(예: 사용자가 방금 양식에 입력한 계정 정보)를 가져와야 하는 완전한 기능의 프로토타입은 가까이에서 수행해야 합니다. 백엔드 개발 팀원들과의 협업. 이 모든 역할을 맡는 것이 걱정되시나요? 아주 작은 프로젝트나 아주 작은 회사에서 작업하지 않는 한 모든 작업을 스스로 수행하지는 않을 것입니다. 핵심은 작업 중인 특정 프로젝트에 대해 필요에 따라 어떤 역할을 수행할 수 있고 수행할 의향이 있는지 이해하는 것입니다. 나머지는 클라이언트 회사 내에서 네트워크를 구축하거나 요구 사항을 충족할 추가 인력을 추천하여 프로젝트 팀에서 필요한 지원을 받을 수 있습니다. 이 작업을 수행할 수 있는 방법에 대해 잠시 이야기해 봅시다.

모자를 선택하세요

사용자 옹호 네트워크 구축 당신이 할 수 있거나 하고 싶은지 확신이 서지 않는 영역에 대해서는 도움을 구할 때입니다. 이를 수행할 수 있는 세 가지 주요 방법이 있습니다. 필요한 경우 팀 구성원을 추가하도록 권장합니다.

충분히 명백하다. 격차가 있는 주요 영역에서 자신을 교육하십시오.

능력은 관리가 가능하고 그것에 전념할 시간이 있습니다. 회사 내에서 지원 네트워크를 구축하여 주요 시점에서 도움을 받으세요.

지원 네트워크를 구축할 수 있는 방법에 대해 자세히 살펴보겠습니다. 성공에 도움이 될 수 있는 핵심 자원이 회사 내 다른 부서에 있을 가능성이 큽니다. 주로 한 부서에서 소유한 프로젝트에서 외부인의 시간을 요청하는 것은 까다로운 요청이 될 수 있기 때문에 이러한 사람들에게 얼마나 많은 시간을 의존할 수 있는지 측정해야 합니다. 게이트 밖에서 많은 시간을 요구하고 싶지 않다면 해당 역할의 주요 책임에 대한 최상의 결과를 보장하기 위해 파트너와 협력(또는 상담)할 수 있는지 물어보십시오. 파트너 관계를 맺은 후에는 필요한 상호 작용의 양과 시간을 좀 더 형식적으로 요청해야 하는지 여부를 더 잘 이해할 수 있습니다. 회사마다 구조와 부서 이름이 다르지만 파트너를 찾을 수 있는 몇 가지 일반적인 위치는 다음과 같습니다. 브랜드 전략가 역할의 경우 마케팅 부서에 사람이 있는지 물어보십시오.

귀사의 접점이 될 수 있는 부서입니다. 비주얼 디자이너와 콘텐츠 전략가를 위한 소스가 될 수도 있습니다. 시각 디자인 및 콘텐츠 전략 파트너는 다음에서도 찾을 수 있습니다.

프로그램 또는 제품 관리 또는 연구 개발, 운영 또는 기업 전략 부서에서 비즈니스 분석가 및 제품 관리자를 자주 찾을 수 있습니다. IT 또는 엔지니어링 부서는 종종 프런트 엔드에 대한 최선의 선택입니다.

사이트 분석 도구에 대한 액세스 및 통찰력을 얻는 데 도움을 줄 수 있는 개발자 및 기타.

2장: 프로젝트 생태계

최근에 새로운 회사에 고용되었고 여러 부서에서 일할 것으로 예상되는 경우, 게이트 밖에서 할 수 있는 가장 좋은 일 중 하나는 파트너가 될 수 있는 주요 인물을 식별하고 그들의 역할을 이해하기 위해 인터뷰 시간을 예약하는 것입니다. 그리고 경험. 그것은 당신이 오랫동안 의존할 수 있는 네트워크로 당신을 시작하고 당신의 책임(및 일반적인 사용자 경험 디자인)을 설명할 기회를 제공합니다. 인터뷰가 끝날 때 다음과 같은 좋은 질문을 할 수도 있습니다. "내가 누구와 이야기해야 한다고 생각하세요?" 대답은 주 프로젝트 관리자나 클라이언트 담당자에게 분명하지 않을 수 있는 사람을 찾는 데 도움이 될 수 있습니다. 한동안 회사에 있었다면 여전히 이와 같은 인터뷰 일정을 시작할 수 있습니다. 이러한 상황에서는 높은 참여를 보장하기 위해 특정 이정표(예: 새 프로젝트 시작) 또는 긴급한 기업 목표와 연결하는 것이 가장 좋습니다. 관리자가 주변을 돌아다니는 것처럼 보이지 않도록 관리자가 자신이 무엇을 하고 있는지 알고 있는지 확인하십시오. 원활한 커뮤니케이션은 역할에 대한 기대치를 이해하고 신뢰를 구축하는 데 중요합니다. 회사 내에서 신뢰를 얻는 또 다른 열쇠는 회사 문화, 과거 프로젝트 경험(긍정적 또는 부정적), 조직 계층에 관한 에티켓, 수용 가능한 작업 물류(예: 재택 근무).

회사 문화 이해 문화는 알카셀처를 유리잔에 떨어뜨리는 것과 약간 비슷합니다. 보이지는 않지만 어떻게든 작동합니다. —한스 마그누스 엔첸스베르거

회사의 문화는 모든 지역, 사업부 또는 부서에서 일관되지 않을 수 있지만 일반적으로 귀하와 귀하가 수행하는 프로젝트에 영향을 미칠 주요 특성을 식별할 수 있습니다. 다음은 프로젝트 범위를 지정하고 잠재적으로 까다로운 정치적 상황을 탐색할 때 염두에 두어야 할 몇 가지 측면입니다.

회사 문화 이해

역사 우리 모두는 과거를 기억하지 못하는 사람은 과거를 반복하게 된다는 말을 알고 있으며 프로젝트 작업도 예외는 아닙니다. 프로젝트 또는 팀이 현재 필요한 상태에 도달한 방법을 이해하면 프로젝트 중에 직면할 수 있는 문제를 이해하는 데 도움이 될 수 있습니다. 프로젝트에 영향을 미칠 수 있는 역사를 이해하기 위해 물어볼 수 있는 몇 가지 질문을 다루겠습니다. 이러한 질문에 대한 답변 중 일부는 끔찍해 보일 수 있지만 무언가가 귀하를 프로젝트에 참여시켜야 할 필요성을 유발하여 프로젝트가 험난한 역사를 가지고 있지만 여전히 성공할 수 있음을 명심하십시오. 아마도 당신은 그 성공의 핵심 요소가 될 것입니다! 그러나 아래에 설명된 많은 문제가 적용되는 것처럼 보이고 이러한 문제를 해결하는 데 도움이 될 수 없다고 생각되면 위험 신호일 수 있습니다. 이 경우 이 프로젝트가 성공할 수 있는지에 대한 전반적인 평가를 고려하십시오. 고려된 것으로 보이는 과거 프로젝트의 예는 무엇입니까?

성공을 거두었고 무엇이 성공을 이룬 것 같습니까? 실패했을 것 같은(또는 유난히 고통스러웠던) 과거 프로젝트는 무엇이며 왜 실패했는가? 이러한 질문을 하면(직접적으로 또는 더 미묘하고 대화적인 방식으로) 답변하는 사람이 성공을 정의하는 방법, 프로젝트에 대한 잠재적 위험, 이 프로젝트에 적용될 모든 편견 또는 기대치를 이해하는 데 도움이 될 수 있습니다. , 뿐만 아니라 잘 작동하는 접근 방식. 회사에서 동일한 작업을 수행하고 디자이너를 출시했습니까?

프로젝트 또는 팀? 그렇다면 무엇이 효과가 없는 것처럼 보였고 클라이언트가 귀하의 접근 방식이 어떻게 달라지기를 기대하는지 알아보십시오. 이 질문을 회사에서 한 명 이상에게 할 수 있다면 무언의 기대에 대해 많은 것을 이해하는 데 도움이 될 것입니다. 두 가지 매우 다른 답변을 얻는다면 디자이너의 책임이 잘 정의되지 않았음을 의미할 수 있으며 프로젝트 전반에 걸쳐 귀하의 책임에 대해 많은 의사 소통이 있는지 확인해야 할 수 있습니다. 프로젝트 팀이 프로젝트(또는 관련 자료) 작업을 수행했습니까?

마치지 않고 비정상적으로 긴 시간처럼 보이는 것은 무엇입니까?

2장: 프로젝트 생태계

그렇다면 이는 주요 고객 이해 관계자가 같은 페이지에 있지 않거나 적절한 시간에 참여하지 않아 여러 번의 중단, 방향 변경 또는 여러 반복으로 인한 시간 손실을 초래한다는 신호일 수 있습니다. 또한 비즈니스 목표에 계속 초점을 맞추기 위해 '아니오'라고 말할 수 있는(또는 적어도 효과적으로 우선순위를 정할 수 있는) 명확한 리더가 없다는 의미일 수도 있습니다. 프로젝트에 대한 커뮤니케이션에 영향을 미칠 수 있는 위치에 있다면 프로젝트를 진행하는 데 도움이 되는 참여 지침을 만드는 데 도움이 될 수 있습니다. 의 사전 참여 없이 회사가 디자인을 생성했습니까?

UX 디자이너? 이것은 복합적인 축복이 될 수 있습니다. 한편으로 당신은 디자인의 필요성을 이해하고 그 격차를 메우려고 시도한 팀을 상대하고 있습니다. 다른 한편으로는 사용자 경험에 대한 프로젝트 목표를 충족하지 못한다고 느끼는 디자인이 주어질 수 있습니다. 이것은 탐색하기에 민감한 상황일 수 있습니다. 존경하는 멘토나 도움이 되는 컨설턴트의 어조로 그러한 디자인을 만든 사람에게 먼저 접근하여 디자인의 좋은 측면을 먼저 지적한 다음 사용자 경험 목표와 다른 접근 방식으로 더 잘 달성할 수 있는 방법에 대해 논의하는 것이 가장 좋습니다. 크리에이터는 지원 네트워크의 소중한 구성원일 가능성이 높으므로 여기에서 다리를 불태우는 것이 아니라 열정을 유지하기 위해 협업 방식으로 역할을 재정의하는 것이 중요합니다. 메인 스폰서나 프로젝트 매니저가 특히 불안해 보이는가?

프로젝트에 대해? 특히 위의 요인 중 일부가 작용하는 경우 이러한 현상이 발생할 수 있는 많은 이유가 있습니다. 불안은 이해하는 데 도움이 될 시장 압력 때문일 수도 있습니다. 예를 들어, 회사 주가가 하락하고 있습니까? 특정 경쟁자가 최근 놀라운 진전을 이뤘습니까? 사업이 적자에서 운영되고 있습니까? 다시 말하지만, 이러한 상황이 반드시 프로젝트를 수행해서는 안 된다는 의미는 아닙니다. 결국, 처음부터 프로젝트에 자금을 지원하는 경우가 많습니다. 그러나 회사가 인보이스를 지불할 수 없을 것이라는 상당한 우려가 있다면 그것은 당신이 평가하고 싶은 위험입니다.

회사 문화 이해

계층 구조 Geert Hofstede는 종종 사람들이 상호 작용하고 의사 소통하는 방식에 영향을 미치는 "문화적 차원"이라고 부르는 문화의 차이를 설명하는 훌륭한 모델을 가지고 있습니다. 그 중 하나는 권력 거리의 개념인데, 이는 사회 구성원(우리의 경우 회사)이 서로 다른 수준의 권력을 가진 사람들 사이의 거리를 이해하고 수용하는 정도입니다. 예를 들어 회사의 경영진 구성원이 특히 강력하고 잠재적으로 접근하기 어려운 것으로 간주되는 경우 회사는 권력 거리가 멀고 직원은 계층 구조에 더 집중할 수 있습니다. 회사가 아이디어의 민주적 공유와 비전에 대한 질문을 장려한다면 상대적으로 권력의 거리가 좁을 수 있습니다.

권력 거리는 “… 가족과 같은 조직 및 기관의 덜 강력한 구성원이 권력이 불공평하게 분배되는 것을 받아들이고 기대하는 정도입니다. 이것은 불평등(더 많음과 적음)을 나타내지만 위가 아니라 아래에서 정의됩니다. 그것은 사회의 불평등 수준이 지도자만큼 추종자들에 의해 지지된다는 것을 암시합니다.” Geert Hofstede 문화 차원 www.geert-hofstede.com

일반적으로 미국에서 대부분의 직원은 직장에서 작은 권력 거리를 선호하는 것처럼 보이지만 극단은 그 자체로 좋거나 나쁘다고 간주될 수 없습니다. 흥미로운 점은 이것이 반드시 회사의 성공 정도를 나타내는 지표는 아니라는 것입니다. 애플은 (스티브 잡스 주변의 아우라를 생각해보면) 상대적으로 권력의 거리가 크고, 구글은 문화의 일부로 권력의 거리가 상대적으로 좁지만 두 회사 모두 혁신적 리더로 알려져 있다. 주목해야 할 중요한 점은 클라이언트 회사 내의 권력 거리가 프로젝트 중에 정치적인 물을 성공적으로 탐색하는 방법에 영향을 미친다는 것입니다. 이 측면은 요구 사항 수집 중(5장에서 설명) 및 승인 지점과 같은 주요 이정표(4장에서 설명)와 같은 프로젝트의 핵심 지점에서 특히 중요해집니다. 권력 거리가 큰 회사에서 일한다면 여분을 가져 가라.

2장: 프로젝트 생태계

이해관계자 인터뷰 및 검토와 같은 회의를 예약하기 전에 보고 관계를 이해하고 커뮤니케이션 중에 더 많은 중간 수준의 사람들을 참여시키는 것을 고려하십시오.

물류 위에서 언급한 문화의 더 큰 측면 외에도 본질적으로 보다 물류적인 요소를 이해하는 것도 도움이 되므로 현재 작업 방식과 더 잘 통합하거나 사려 깊은 방식으로 변화를 도입할 수 있습니다. 예를 들어, 프로젝트에 영향을 미칠 주요 릴리스 날짜 또는 기한을 포함하여 회사 내에서 예상되는 일반적인 속도를 이해하는 것이 도움이 됩니다(연간 릴리스 일정에 따라 소프트웨어 애플리케이션을 생성하는 것은 아마도 계절별 캠페인을 지원하는 마이크로사이트와 속도가 다를 것입니다. 예를 들어). 당신의 팀은 다가오는 마감일을 맞추기 위해 늦은 시간까지 일해야 합니까? 원격 작업과 현장 작업에 대한 기대도 이해하는 것이 좋습니다. 많은 현장 방문 시간이 예상되는 경우 출장 및 리소스 설정을 계획해야 합니다. 원격 작업이 허용되는 경우(또는 글로벌 기업과 협력할 때 일반적으로 권장되는 경우) 커뮤니케이션 방법과 도구를 이해하는 것이 중요합니다. 예를 들어, 인스턴트 메시징 응용 프로그램의 사용이 허용됩니까? 사용 중인 웹 회의 도구는 무엇입니까? 과거에 효과가 입증된 국제 이해관계자를 포함하는 방법이 있습니까? 기업의 '종이문화'를 이해하는 것도 흥미롭다. 일부 회사는 대부분의 경우 전자 미디어를 선호하며, 이 경우 우수한 프로젝터와 일관된 이더넷 연결이 중요합니다. 다른 회의는 매우 종이 중심적이며, 이 경우 생산성을 높이려면 회의에 충분한 사본을 가져와야 합니다. 다른 방법이 더 효과적이라고 생각한다면 프로젝트의 문화를 바꿀 수도 있습니다. 그러나 전환을 순조롭게 진행하고 특정 접근 방식이 예상대로 작동하지 않는 이유를 잠재적으로 이해할 수 있도록 사람들에게 변경을 요청하고 있다는 사실을 아는 것이 좋습니다.

회사 문화 이해

통합하기 이제 프로젝트의 영역을 탐색했으므로 프로젝트 에코시스템, 즉 작업 환경(회사 문화), 모두 참여하게 될 일반적인 작업 유형에 대해 더 잘 이해해야 합니다. (예: 디자인 중인 사이트 유형) 및 상호 작용할 사람들(역할 및 책임 포함). 이 정보는 프로젝트에서 자신의 역할을 설명하고 본격적으로 시작할 준비를 할 때 유용할 것입니다. 프리랜서나 하청업체로 일하고 있다면 프로젝트 작업을 다루는 제안서를 작성하기 위한 기반을 제공할 것입니다(UX 제안에 대해 설명하는 다음 장 참조). 더 큰 팀의 구성원으로 일하고 있고 제안서 작성에 직접 관여하지 않는 경우 새로운 지식을 팀의 첫 번째 회의인 프로젝트 킥오프에 적용할 수 있습니다. 좋은 회의를 진행하기 위한 기본 가이드는 온라인 장인 "A Brief Guide to Meetings"를 참조하고, 프로젝트가 시작될 때 물어볼 질문에 대해 직접 알아보려면 4장, "프로젝트 목표"를 참조하십시오. 접근하십시오.”

2장: 프로젝트 생태계

삼

컨설턴트 및 프리랜서를 위한 제안 자신의 비즈니스를 관리하는 비즈니스 종사자를 위한 가이드 프로젝트 및 클라이언트 기대치를 관리하는 것은 충분히 어려울 수 있지만 적절한 계약이 없으면 손해를 볼 수 있습니다. 당신이 맡은 모든 프로젝트의 끝. 제안서와 업무 기술서는 귀하의 비즈니스와 귀하 자신을 재정 및 법적 문제로부터 보호하는 데 필수적입니다. 프로젝트를 수락하고 악수를 한 후에는 고객과의 관계 조건과 지불 일정을 자세히 설명하는 계약서를 작성하는 데 적절한 시간을 할애해야 합니다. 러스 웅거

제안 "어떤 선행도 처벌받지 않는다"는 오래된 속담이 있으며 일반적으로 모든 프로젝트를 시작하는 경우에도 마찬가지입니다. 하이파이브와 기분 좋은 순간은 "오, 젠장! 제안서를 작성할 시간입니다!” 제안서를 작성할 때 가장 어려운 점은 첫 번째 제안서를 작성하는 것입니다. 직접 작성해 본 적이 없다면 어디서부터 시작해야 할지 아는 것이 거의 불가능하며, 바로 이 장이 유용할 것입니다. 접하는 모든 유형의 프로젝트에는 제안서를 작성해야 할 때 긴장을 늦추지 않는 다양한 특징이 있습니다. 다행스럽게도 모든 제안에 공통적이고 프로젝트마다 재사용할 수 있는 핵심이 있습니다. (프로젝트 유형에 대한 자세한 내용은 2장을 참조하십시오.) 언제 제안서를 작성해야 합니까? 언제나. 왜 제안서를 작성해야 합니까? 프로젝트 작업의 역사를 통틀어 사람들을 가장 불편한 상황에 처하게 한 것은 고객과 공급업체 사이에 합의가 이루어지지 않은 상황이었습니다. 잠재 고객과 처음으로 연결하고 모든 것이 클릭되는 것처럼 보일 때 이 단계를 건너뛰고 싶은 유혹이 매우 강할 수 있습니다. 클라이언트의 요구 사항을 명확하게 이해하고 클라이언트가 이해하는 방식으로 명확하게 설명할 수 있지만 실제로는 아직 작업을 시작할 준비가 되지 않았습니다. 사실 여기가 바로 속도를 늦추고 숨을 쉬어야 하는 지점입니다. 바로 일을 시작하는 대신 시간을 들여 전문적인 관계와 새 고객과의 관계 규칙을 정의하십시오. 워싱턴 D.C.에 있는 로펌 Peer, Gan & Gisler, LLP의 Jean Marc Favreau는 다음과 같이 말했습니다. 기다리고 있습니다. 모든 우발 상황에 대비하는 것은 거의 불가능하지만 포괄적인 서면 계약서는 최선의 방어책이자 나중에 법정에서 관계 조건에 대해 다투는 일이 없도록 하는 가장 현명한 방법입니다. 서면 계약에서 고객과의 관계에 대한 조건과 매개 변수를 더 명확하게 정의할수록 각 당사자의 의무를 놓고 다투게 될 가능성이 줄어듭니다.

3장: 컨설턴트 및 프리랜서를 위한 제안

새로운 프로젝트와 새로운 사람들은 흥미진진합니다. 종종 제안을 혼합하여 "거래를 죽이지" 않으려는 욕구가 있지만, 여느 관계에서와 마찬가지로 신혼 여행의 느낌은 결국 가라앉을 수 있습니다. 약속은 관계의 양쪽에서 깨질 수 있습니다. 클라이언트는 콘텐츠에 대한 적시 액세스를 제공하지 못할 수 있습니다. (나는 이것이 거의 들어본 적이 없다는 것을 알고 있지만, 믿거 나 말거나, 그것은 일어난다! 당신이 그것을 놓친 경우에 대비하여 비꼬는 것입니다.) 한때 프로젝트에 사용할 수 있었던 자금이 다른 곳으로 이동할 수 있습니다. 작업에 종사하는 사람은 가방을 들고 있을 수 있습니다. 기업은 또한 외부 공급업체, 특히 영세 기업이나 독립 계약업체와 협력할 때 위험을 감수하고 있음을 인식하고 있습니다. 잘 작성된 제안서는 고객에게 안정감과 보호감을 제공하여 발생할 수 있는 많은 우려 사항을 완화하는 데 도움이 될 수 있습니다. 또한 제안을 통해 무언가 변경되는 경우 양측을 보호하는 조건을 정의할 수 있습니다. 클라이언트가 리소스에 대한 적시 액세스를 제공하지 않으면 타임라인이 미끄러질 수 있습니다. 당신은 그들이 프로젝트의 성공에 대한 의무를 인식하도록 해야 합니다. 고객이 자금을 잃고 프로젝트가 중단되고 제안이나 다른 형태의 계약이 없는 경우 이미 완료한 작업에 대한 대가를 받지 못할 위험이 있습니다. 요점은 명확해야 합니다. 항상 제안서를 작성하십시오.

제안서 만들기 프로젝트를 착수한 후에는 제안서를 완료할 때입니다. 제안서가 빨리 승인되고 서명될수록 작업을 더 빨리 시작할 수 있고 가장 중요한 작업에 대한 대가를 받기 시작할 수 있습니다. 좋은 제안서의 핵심 구성 요소는 다음과 같습니다. 제목 페이지 개정 내역 프로젝트 개요 프로젝트 접근 방식

제안서 작성

작업 범위 가정 산출물 소유권 및 권리 추가 비용 및 수수료 프로젝트 가격 지불 일정 승인 및 승인

제안서의 각 부분에 대해 자세히 살펴보겠습니다.

제목 페이지 제목 페이지는 문서를 소개하는 간단한 페이지입니다. 제목 페이지는 흥미로운 짐승입니다. 스타일 및 정보 관점에서 제목 페이지를 만들 수 있는 여러 가지 방법이 있습니다. 당신이 그것을하는 방법은 당신에게 달려 있습니다. 일반적인 제목 페이지는 다음 요소로 구성됩니다. 클라이언트 회사 이름 클라이언트 회사 로고(사용 권한이 있는 경우) 프로젝트 제목 문서 유형(제안서) 제안 버전 제출 날짜 회사 이름 제안 작성자 프로젝트 참조 번호 비용 기밀성

첫 번째 제안에는 클라이언트의 회사 로고, 비용 및 (잠재적으로) 프로젝트 참조 번호를 제외한 모든 것을 포함하십시오. 제목 페이지에 이러한 요소를 포함하지 않는 이유는 무엇입니까?

3장: 컨설턴트 및 프리랜서를 위한 제안

고객은 자신이 누구인지 알고 있습니다. 회사 로고 사용 허가를 요청하는 데 시간과 노력을 들일 가치가 없을 수도 있고, 부주의로 로고를 오용할 경우 불쾌한 일이 생길 수도 있습니다. 본문에서 프로젝트의 다양한 구성 요소를 확인한 후 비용을 배치하는 것이 가장 좋으며 비용 정보는 지불 일정으로 잘 연결됩니다. 프로젝트 참조 번호는 알아야 할 사항입니다. 많은 회사에서 전혀 사용하지 않습니다. 그러나 일부 정부 기관은 이 특정 항목에 의존하는 것으로 알려져 있으며 제목 페이지에 해당 항목이 없으면 제안이 거부될 수 있습니다.

그림 3.1 샘플 제안 제목 페이지

그림 3.1에서는 (가상의) 클라이언트 로고가 사용되었습니다. 허가를 받지 않았거나 관계가 성립되지 않은 경우에는 클라이언트 회사의 로고를 표시하지 않는 것이 좋습니다.

제안서 작성

개정 내역 개정 내역은 제안서 자체 섹션이며 원래 버전 이후 제안을 업데이트한 횟수를 식별하는 데 사용됩니다. 일반적으로 독자에게 수정 사항에 대한 컨텍스트를 제공하기 위해 버전 번호, 날짜, 작성자 및 수정된 내용과 같은 버전과 관련된 설명을 제공하는 것이 가장 좋습니다(표 3.1). 표 3.1 개정

샘플 개정 이력 표 섹션

설명

편집자

날짜

원본 문서

REU

2009년 1월 8일

가정

소프트웨어 요구 사항을 반영하도록 업데이트됨

REU

2009년 1월 11일

1.0 1.1

때때로 클라이언트는 제안서에 서명한 다음 추가 수정을 요청합니다. 클라이언트와 함께 진행하고 이러한 변경을 수행하기로 선택한 경우 문서를 버전 1.x에서 2.0으로 업데이트할 기회를 가져야 합니다. 본질적으로 클라이언트가 제안을 승인하고 양 당사자가 조건에 동의하면 작업을 시작할 준비가 된 것입니다. 따라서 추가 수정이 요청되면 매우 신중하게 검토해야 합니다. 이렇게 하면 비용이 여전히 타당하고 수정 사항과 프로젝트가 다시 시작되는 단계(필요한 경우)에 대해 양측이 명확하게 이해할 수 있습니다. 또한 개정 내역에서 개정이 완전히 새로운 버전을 구성하는 이유에 대한 적절한 설명을 항상 제공해야 합니다.

프로젝트 개요 개요 섹션은 작업할 프로젝트에 대한 설명입니다. 이 설명은 고객에게 제품이 수반할 것으로 예상하는 명확한 그림과 제안서의 나머지 부분에서 찾을 수 있는 내용에 대한 설명을 제공해야 합니다. 다음은 개요 시작의 예입니다. [클라이언트 회사 이름]은(는) 새로운 온라인 웹 존재를 만들려고 합니다. 이 웹 존재는 [Client Company Name] 고객에게 온라인으로 제품을 검색하고 구매할 수 있는 기능과 회사를 통해 제공되는 기타 서비스 및 혜택을 제공합니다. 온라인 웹 존재의 목표는 다음과 같습니다.

3장: 컨설턴트 및 프리랜서를 위한 제안

고객이 귀하에게 무엇을 기대해야 하는지에 대해 매우 높은 수준의 세부 정보를 제공하여 한두 단락으로 확실한 개요를 제공할 수 있어야 합니다. 권장 사항에 대한 건전한 설명과 프로젝트 완료를 위한 제안 접근 방식으로 개요를 마무리하는 것이 좋습니다. 이 제안은 [고객 회사 이름]의 설계 및 개발에 대한 [귀사 이름]의 권장 사항과 접근 방식을 자세히 설명합니다. 의 온라인 웹 존재. [마감일]의 기한을 감안할 때…

프로젝트 접근 방식 프로젝트에 대한 접근 방식은 수행 중인 프로젝트의 유형에 따라 달라집니다. 이것은 고객과 함께 프로젝트 작업을 계획하는 방법을 고객에게 알리는 기회입니다. 참여 규칙을 정의하고 앞에 놓인 작업에 대한 기대치를 설정하게 됩니다. 많은 개인과 회사가 매우 유사한 방법론으로 운영되지만 전체 브랜딩에 딱 맞는 다른 이름이나 영리한 약어를 사용합니다. 옛날 옛적에 (잠재적) 고객에게 보여주기 위해 신화적인 방법론이 만들어졌고 많은 제안에서 그 방법을 찾았습니다. 이 프로세스는 The PURITE Process™("purity"로 발음됨)라고 불렸으며, 이것을 여러분과 공유하면서 신화적 존재가 내부에서 약간 죽었습니다. 프로세스의 이름은 약간 치즈 맛이 있으며 프로세스는 분명히 다소 불완전합니다. 출시 후 분석은 이 방법론에서 생략되었지만(감독), 물론 모든 클라이언트에 대해 포함되어야 합니다. 더 이상 지체하지 않고 다음은 PURITE 접근 방식입니다. [회사 이름]은(는) 고객과의 프로젝트 성공을 위한 표준 프로세스를 확인했습니다. 이러한 각 단계가 [프로젝트 제목]에 적용되지 않을 수 있지만 전체 프로세스는 다음과 같이 정의됩니다. PURITE Process™는 모든 이니셔티브의 전반적인 성공을 보장하기 위한 [회사 이름]의 사내 방법론입니다. PURITE를 활용함으로써 [Your Company Name]은(는) 고객 및 사용자/청중과 긴밀히 협력하여 제공 기대치를 안정적으로 유지하고 초과하기 위한 입증된 지침을 보유하고 있습니다. P – 준비하십시오. 우리는 요구 사항 수집을 시작하기 전에 가능한 한 정보를 얻기 위해 귀사의 산업과 경쟁사 및 그들이 비즈니스를 수행하는 방식을 이해하는 데 모든 이니셔티브의 일부를 바칩니다. 이해 했어. 우리는 귀하의 주제 전문가 및/또는 사용자와 긴밀히 협력하여 프로젝트를 올바르게 구축하기 위한 요구 사항을 정의합니다.

제안서 작성

R – 렌더링. 렌더 단계를 통해 우리는 프로젝트/제품의 모든 부분을 만들고 개발합니다. 우리의 경험에 따르면 모든 개발 단계에는 머리를 숙이고 집중적인 작업 노력이 많이 필요하지만 팀과 시기적절하고 열린 커뮤니케이션이 필요합니다. 그것은 또한 우리가... I – 반복을 요구합니다. 반복 단계는 프로젝트의 전체 수명 주기 동안 반복됩니다. 우리는 프로젝트에 생명을 불어넣기 위해 가능한 한 빨리 움직이며, 이를 위해서는 종종 빠른 일정에 여러 번 반복해야 합니다. 이를 위해서는 귀하와 전담 리소스의 직접적이고 시기적절한 참여가 필요합니다. 최종 결과는 귀하가 지정하고 제작에 도움을 준 제품입니다. T – 테스트. 렌더링 단계 전체에서 모든 프로젝트를 테스트합니다. 그러나 목표 기반 테스트를 수행하려면 자체 테스트 팀과 지정된 사용자 그룹/대상 그룹의 추가 눈이 필요합니다. 이 추가 테스트 라운드는 여러 수준에서 엄격하게 평가된 프로젝트를 제공하기 위해 가능한 한 적은 수의 돌이 남아 있는지 확인하는 데 도움이 됩니다. 이자형 - 활성화합니다. 이전 5단계를 성공적으로 완료하고 서명한 승인을 받으면 솔루션을 활성화하고 실행합니다. PURITE Process™는 여기서 끝나지 않습니다. 프로젝트 완료 후 고객과 정기적으로 소통합니다. 우리는 계속해서 귀하의 만족도를 측정하고, 변화하는 목표 또는 프로젝트 개선 사항을 이해하고, 향후 프로젝트 개발을 위한 최선의 접근 방식을 정의하는 데 도움을 드릴 것입니다.

귀하에게 적용 가능하거나 유용한 만큼 적게 또는 많이 사용하는 것을 환영합니다. 그 과정을 만든 신화 작가는 당신이 출처를 밝히지 않아도 상관하지 않습니다. 프로세스 정의는 위와 같이 상세하거나 다음과 같이 간단할 수 있습니다. 계획, 정의, 개발, 확장 전체 전략 계획 세부 프로젝트 요구 사항 정의 작업 제품 개발, 테스트, 수정 및 시작 개발, 테스트 및 출시 후 학습한 정보를 기반으로 한 개선 사항

프로세스를 정의한 후에는 접근 방식의 각 단계에서 발생할 다양한 노력과 각 노력이 귀하와 고객에게 의미하는 바를 자세히 설명할 기회가 있습니다. 제안서의 접근 방식 섹션은 프로젝트, 프로세스 및 프로세스의 각 단계에서 발생하는 활동에 따라 길이가 달라집니다. 그래도 최대 2~3페이지로 유지하고

3장: 컨설턴트 및 프리랜서를 위한 제안

문서를 추가로 업데이트하거나 프로젝트 가격을 다시 확인하는 것을 방지하기 위해 고객에게 제공할 수 있는 출력만 포함해야 합니다.

작업 범위 작업 범위 섹션에서는 프로젝트의 분업을 식별합니다. 즉, 귀하가 담당하는 프로젝트 구성 요소와 클라이언트가 담당하는 구성 요소를 식별합니다. 그것을 다시 읽으십시오. 잠시 생각해 보십시오. 가라 앉게 놔두세요. 좋아요. 이것은 당신이 고객에게 서면으로 우리는 이것을 할 것이고 당신은 저것을 할 것이라고 말하는 제안서의 일부입니다. 그런 다음 나중에 고객이 귀하의 제안서에 서명하면 그들은 이 합의에 동의하는 것이며 오해가 있는 경우 귀하를 뒷받침할 문서 추적이 있습니다. 여기서 의도는 누가 프로젝트의 어떤 측면을 처리할 것인지, 그리고 제안서에 포함된 프로젝트의 측면과 예상 가격을 명확하게 식별하는 것입니다. 제안서를 작성해야 할 다른 설득력 있는 이유를 찾을 수 없다면 이것만으로도 충분한 이유가 될 것입니다. 다음은 작업 범위에 대한 매우 간단한 예입니다. [프로젝트 유형]을(를) 구축하는 데 필요한 모든 서비스를 제공하기 위해 [고객 회사 이름]이(가) 우리에게 접근했습니다. [Your Company Name]은(는) [Client Company Name] 웹사이트의 [User Experience Design Aspect(s)]에만 초점을 맞춥니다. [Client Company Name]은(는) 프로젝트 계획에 따라 [Project Type]의 모든 측면에 대한 자세한 피드백을 제공합니다. [클라이언트 회사 이름]은(는) 글꼴, 색 구성표, 브랜드 표준 등을 포함하여 프로젝트에서 사용하는 데 필요한 모든 자산을 제공합니다.

가정 제안서의 가정 섹션은 논의의 여지를 남기지 않고 성공을 보장하기 위해 고객에게 필요한 사항을 설명하기에 좋은 곳입니다. 즉, 프로젝트 성공을 위해 액세스할 수 있거나 전달될 것이라고 가정하고 클라이언트와 통신하는 것입니다.

제안서 작성

이 섹션에서 가정이라고 부르는 것은 실제로 예상입니다. 가정하는 것이 훨씬 더 정중합니다. 원하는 만큼 많은 프로젝트 계획을 세울 수 있지만 귀하와 고객 모두 이정표와 목표를 달성하지 못한다면 양측 모두 특정 프로젝트 실패를 약속하는 것입니다. 일반적으로 가정은 자원과 자산에 대한 기대와 이 두 가지 모두에 대한 시기적절한(번역: 신속하고 즉각적인) 액세스입니다. 다음은 가정을 작성하는 방법의 예입니다. 가정 [고객 회사 이름]은(는) 다음 자산과 리소스를 제공해야 합니다. 이러한 자산과 자원을 시기 적절하고 완전한 방식으로 제공할 수 없으면 이 프로젝트의 전달이 실패하거나 지연될 수 있습니다. 다음과 같은 자산 및 리소스가 필요합니다. 필요한 모든 [고객사 이름] 직원에게 적시에 액세스합니다. 사용 가능한 경우 모든 소스 파일을 포함하여 현재 상태에서 [프로젝트]의 모든 필수 자산에 적시에 액세스합니다. 필요에 따라 [프로젝트]의 모든 측면에 대한 사본, 이미지, 오디오 등을 포함하되 이에 국한되지 않는 콘텐츠.

산출물 산출물은 귀하가 작성하여 고객에게 제공할 작업 산출물입니다. 이 섹션은 프로젝트 과정에서 고객이 기대할 수 있는 작업 결과물의 유형을 고객에게 자세히 설명할 수 있는 기회입니다. 프로젝트가 끝날 무렵 상태 보고를 별도로 처리하는 것이 좋지만 프로젝트의 이 부분에 자유롭게 추가할 수 있습니다. 작업 산출물이 생성되지 않더라도 포함할 수 있는 작업 산출물에 대한 설명을 제공하십시오. 이것은 과잉일 수 있거나 "제안서에서 [발행물 유형]에 대해 읽었지만 여기에서는 보이지 않습니다"라는 웜 캔을 열 가능성이 있는 것처럼 보일 수 있지만, 작은 단어 하나가 만들 수 있습니다. 차이점. 산출물 [회사 이름]은(는) 프로젝트 과정 전반에 걸쳐 다양한 산출물을 제공합니다. [Client Company Name]의 경우 다음 결과물을 확인했습니다.

3장: 컨설턴트 및 프리랜서를 위한 제안

Creative Brief Creative Brief는 프로젝트의 첫 번째 단계입니다. 이 문서는 프로젝트에 대한 빠르고 효과적인 높은 수준의 개요를 만드는 데 도움이 됩니다. Creative Brief의 목적은 사용자의 목표와 요구 사항을 명확히 하고 프로젝트와 관련된 특수 리소스 및/또는 제약 조건을 정의하는 것입니다. 등등…

소유권 및 권리 귀하가 제작한 작업 산출물을 클라이언트가 사용하도록 허용할 범위를 고려하는 것이 중요합니다. 이러한 권리는 여러 가지 방법으로 정의할 수 있지만 작업의 대부분은 두 가지 범주로 나뉩니다. 고용 작업 라이선스 작업

고용을 위한 작업(법률 세계에서 "고용을 위한 작업"으로 알려짐) 프로젝트는 실제 작업을 수행할 책임이 있는 당사자가 아니라 작업 비용을 지불하는 당사자가 생성하고 저작권이 있는 것으로 간주됩니다. 즉, 고용 작업인 프로젝트에서 작업을 수행할 때 작업에 대한 권한이 전혀 없으며 프로젝트와 관련하여 생성한 모든 것이 클라이언트의 소유입니다. 이러한 상황은 많은 회사와 개인이 대처하기 어렵습니다. 고객이 프로젝트가 완료된 후 자체적으로 유지 관리하기로 결정할 수 있기 때문에 다운스트림 "유지 관리" 작업(추가 수익 포함)이 없음을 의미하는 경우가 많습니다. 클라이언트가 약정을 강요하는 프로젝트에서 동요하지 마십시오. 그것은 드문 일이 아닙니다. 회사에 정규직 고용이라는 맥락에서 고용 프로젝트를 위해 일을 할 때 이것은 고용주-고용인 관계의 표준입니다. 또한 가격 책정 모델을 방문할 수 있는 기회이기도 합니다. 많은 프로젝트는 향후 잠재적인 수익 손실을 보상하기 위해 다소 증가된 요금으로 청구됩니다. 이 모든 것은 고객과의 관계 및 비즈니스 수행 방법에 따라 달라집니다. 시간과 경험은 수행하는 작업 유형과 선택한 가격 책정 모델에 대해 올바른 결정을 내리는 데 도움이 됩니다. 라이선스가 있는 작업 프로젝트를 사용하면 작업에 대한 저작권을 보유할 수 있지만 다른 당사자에게 복사 및/또는 배포할 수 있는 권한을 부여할 수 있습니다. 라이센싱 계약에 여러 규정을 포함할 수 있습니다. 당신은 아마도 제안서를 작성하게 될 것입니다.

작업의 모든 원본 자료에 대한 소유권을 보유하고 제한적으로 사용되는 작업 제품만 고객에게 제공할 때 작업 라이선스를 활용하십시오(예: 편집 가능한 원본 Word, Visio, Axure, OmniGraffle 또는 기타 문서 대신 PDF) ). 저작물을 수정하지 않고 비상업적으로 사용하거나 상황에 맞는 여러 가지 방법으로 저작물에 라이선스를 부여하는 등 다양한 방식으로 저작물에 라이선스를 부여할 수 있습니다. Creative Commons(http://creativecommons.org/about/licenses)는 사용할 수 있는 다양한 라이센스 유형에 대한 이해하기 쉬운 설명을 제공하지만 라이센스 세계의 일부에 불과합니다. 매우 상세하고 구체적인 요구 사항이 있는 상황에 처한 경우 최상의 솔루션을 만드는 데 도움을 줄 저작권 변호사에게 문의하는 것이 가장 좋습니다.

추가 비용 및 수수료 귀하가 그들에게 제공할 프로젝트 가격이 외부 자원을 고려하는지 여부를 클라이언트가 이해하는 것이 중요합니다. 예를 들어 일부 프로젝트에서는 공급업체로부터 스톡 사진을 구매해야 할 수 있습니다. 이미지를 구매하고(적절한 사용 권한 포함) 비용의 일부로 포함하거나 고객에게 전달될 추가 비용으로 이미지 구매를 명확하게 식별할 수 있습니다. 고객에게 알리고 싶은 서비스를 제공할 수도 있습니다. 이러한 서비스를 홍보할 수 있는 좋은 기회입니다. 다음은 추가 비용 및 수수료 처리 방법에 대한 예입니다. 추가 비용 및 수수료 외부 리소스(예: 콘텐츠, 이미지, 글꼴 등)가 필요한 경우 이를 확인하고 [클라이언트 회사 이름]으로 청구됩니다. 또한 [Your Company Name]은(는) 매우 낮은 오버헤드로 고객에게 호스팅 서비스를 제공할 수 있습니다. 구성 가능한 웹 기반 이메일을 포함한 호스팅 서비스를 월 $25부터 시작하여 $25의 설치 비용으로 제공합니다. [Client Company Name]이(가) "유지 관리" 패키지를 구매하려는 경우 [Your Company Name]은(는) 상호 동의하고 양 당사자에게 유익한 패키지를 만들기 위해 노력할 것입니다.

3장: 컨설턴트 및 프리랜서를 위한 제안

프로젝트 가격 책정 프로젝트 작업을 수행하는 방법에 대한 세부 정보를 문서화한 후 고객에게 비용을 알리는 것이 좋습니다. 가격에 도달하는 방법은 주로 귀하에게 달려 있지만 여기에 팁이 있습니다. 특정 수의 수정을 포함하여 프로젝트를 수행하는 데 소요될 것으로 예상되는 시간을 추정하고 프로젝트 관리를 위한 합리적인 시간을 추정합니다. 약 25%; 그런 다음 청구하려는 시간당 청구 가능 요율을 결정하고 모두 계산하십시오. 프로젝트의 각 부분에 난이도를 적용하는 등 클라이언트에게 제공할 비용 범위를 제시하는 데 도움이 되는 다양한 공식이 있습니다. 대부분의 경우 경험은 시간과 재료의 관점에서 프로젝트를 적절하게 평가하는 데 도움이 되는 열쇠가 될 것입니다. 청구 요금은 어떻게 결정합니까? 급여 설문 조사 및 계약자 요율을 찾아 비교를 위해 다른 사람들이 청구하는 것을 조사하십시오. 예를 들어 Information Architecture Institute(www.iainstitute.org), AIGA(www.aiga.com), Coroflot(www.coroflot.com), 연예기획사 Aquent(www.aquent.com) 등의 조직에서 급여를 지급합니다. 계약자 요금 조사. 귀하의 경험, 귀하의 시장에 있는 다른 사람들이 청구하는 금액, 귀하가 다소 공정하다고 느끼는 금액을 고려하여 청구할 수 있는 요율에 대한 적절한 아이디어를 얻을 수 있습니다. 기억하십시오: 귀하는 언제든지 요율을 낮출 수 있습니다. 고객이 페이지에서 숫자를 본 후에 더 많은 돈을 지불하도록 요청하는 것이 훨씬 더 어렵습니다! 프로젝트 가격을 구성하는 방법에는 여러 가지가 있습니다. 프로젝트의 특성에 따라 다양한 가격 옵션을 허용하는 여러 추정치를 제공하기를 원하거나 제공해야 할 수 있습니다. 예를 들어 클라이언트에게 정적 HTML 웹 사이트와 동적 콘텐츠(클라이언트가 전용 리소스 없이 관리할 수 있음)를 허용하는 콘텐츠 관리 시스템(CMS)이 있는 웹 사이트의 두 가지 옵션을 제공한다고 가정합니다. 다음은 프로젝트 견적을 표현하는 방법입니다. 프로젝트 견적 [회사 이름]은 귀하의 즉각적인 및/또는 미래의 요구에 가장 적합한 옵션을 제공하기 위해 [고객 회사 이름]에 대해 여러 견적을 제안했습니다. [Your Company Name]은(는) 모든 콘텐츠가 [Client Company Name]에서 제공될 것이라고 가정합니다. [Your Company Name]에 콘텐츠 서비스 제공을 요청하는 경우 견적을 재정의해야 합니다.

제안서 작성

[Your Company Name]의 추정치는 비용 및 필요 관점에서 유연성을 허용합니다. 견적은 다음과 같습니다. 견적 1 [귀하의 회사 이름]은 [고객 회사 이름]의 [프로젝트]가 대화형 콘텐츠 없이…

현금 흐름이 마이너스가 되지 않는 한 프로젝트 추정치를 합산하는 데 정말 잘못된 방법이 없다는 것을 기억하십시오!

지불 일정 모든 프리랜서 프로젝트는 작업이 시작되기 전에 선불로 50%를 지불하고 프로젝트 완료 후 50%를 지불한다는 잘못된 믿음이 있습니다. 이 신화는 바로 지금 당장 불식되어야 합니다! 이것은 사업을 할 수 있는 방법이 아니며 작업을 수행하는 동안 시기 적절하고 일관된 수입을 보장할 수 있는 방법이 아닙니다. 변경 주문 프로세스를 통해 작업하는 대신 프로젝트를 완료하고 비용을 받고 싶다는 이유만으로 고객을 위해 변경 후 변경해야 하는 위치에 자신을 두기를 원하지 않습니다. 미리 정해진 기간에 제출된 청구서부터 마일스톤 기반 지불에 이르기까지 다양한 방법으로 프로젝트 가격을 책정할 수 있습니다. 더 현명한 접근 방식은 정기적이고 상세한 송장을 사용하여 프로젝트를 반복 지불 일정으로 조정하는 것입니다. 이 접근 방식은 또한 클라이언트가 무엇이 완료되었고 프로젝트에 남아 있는 작업이 무엇인지 명확하게 이해할 수 있도록 해야 합니다. 다음 예는 작업에 대한 지불을 구조화하는 한 가지 방법입니다. 지불 일정 [회사 이름] 일반적인 지불 일정은 시작 전에 프로젝트의 총 예상 가격의 XX%에 해당하는 보유 수수료를 받는 것입니다. [회사 이름]은(는) 매월 1일과 15일에 인보이스를 제출합니다. 지불 기한은 14일 이내입니다. 프로젝트가 완료되면 [Your Company Name]은(는) 모든 작업 제품을 [Client Company Name]에 전달합니다. 자료가 만족스럽게 승인되면 [귀사의 회사 이름]은(는) 보유자에게 남은 지불 초과액을 환불하거나 [귀사의 회사명]은(는) 보유자가 부담하지 않는 금액에 대한 최종 청구서를 제출합니다. 참고: [프로젝트]가 작업 진행 없이 14일 이상 보류된 경우 [회사 이름]은(는) 보유자가 부담하지 않는 모든 비용에 대한 최종 청구서를 제출해야 하며 다음 권리가 제공됩니다. 프로젝트가 재개되는 경우 첫 번째 거부.

3장: 컨설턴트 및 프리랜서를 위한 제안

필수는 아니지만 프로젝트가 장기간 보류될 경우 프로젝트를 처리하는 방법에 대한 메모를 포함하면 도움이 됩니다. 이 규정은 프로젝트를 순조롭게 진행하고 진행하는 데 도움이 될 수 있으며 고객과의 논의 지점을 제공합니다. 오랫동안 그들을 위해 추가 작업을 수행하지 않을 경우 계속해서 공백을 채울 작업을 찾을 수 있기를 원합니다.

확인 및 승인 제안서를 준비하는 것이 매우 중요하지만 그것만으로는 충분하지 않습니다. 고객 회사의 적절한 사람이 승인하고 서명하기 전에는 제안이 큰 의미가 없습니다. 모든 사람이 무슨 일이 일어날지, 각 측에서 얼마나 많은 것을 기대하는지 명확하게 이해하고 있는지 확인하는 것이 중요합니다. "반복 초고속 도로"로부터 자신을 보호하고 클라이언트가 "기능 크립"에 관여하도록 허용하는 위험을 줄이는 것도 마찬가지로 중요합니다. 즉, 포함해야 할 "한 가지만 더"를 지속적으로 요청하는 것입니다. 승인은 매우 간단하고 명확합니다. 제안 문서를 작성하고 나면 고객에게 두 회사 간의 계약을 승인하는 승인 및 사인오프를 제공하게 됩니다. 항상 각 당사자당 하나씩 두 장의 사본을 준비하고 두 사본 모두에 서명했는지 확인하십시오. 다음은 사용할 수 있는 승인의 예입니다. 승인 이 제안은 [클라이언트 회사 이름]에 의해 전체적으로 승인되고 동의되었습니다. 이 제안서는 [고객 회사 이름]의 공식 대리인이 서명하고 날짜를 기입해야 효력이 발생합니다. 또는 이 제안을 언급하는 서명된 구매 주문서가 이 서명된 문서 대신 수락으로 간주됩니다(단, 해당 구매 주문서에 사전 인쇄된 조건은 무효이며 효력이 없는 것으로 간주됩니다). 이 제안은 이 제안의 주제와 관련하여 당사자 간의 완전한 합의를 구성합니다. 이 제안은 이전의 모든 구두 또는 서면 계약, 토론, 협상, 약속, 서면 또는 이해를 통합하고 대체합니다. 여기에는 판매 인쇄물, 브로셔 또는 기타 서면 설명 또는 광고 자료에 포함된 모든 표현이 포함되며 이에 국한되지 않으며 당사자 간의 계약 조건에 대한 완전하고 배타적인 진술입니다. 각 당사자는 이 제안을 실행하는 데 있어 여기 또는 계약에 명시되지 않은 진술이나 진술에 의존하지 않았으며 이에 대한 의존을 명시적으로 부인한다는 점을 인정하고 동의합니다.

제안서 작성

[귀하의 회사 이름]의 공식 대리인이 승인함

[고객사명]

에 의해: ________________________________

이름: _____________________________

이름:_____________________________

제목: _______________________________

제목: ______________________________

날짜: ______________________________

(Video) Food App Design | UX/UI ( Wireframe, Prototype, Export)

날짜: ______________________________

모든 수표의 수취인은 [회사 이름]입니다.

작업 명세서 작업 명세서(SOW)는 2~3페이지 분량의 문서(표지 제외)로 구성할 수 있는 프로젝트 목표에 대한 높은 수준의 정의입니다. SOW는 일반적으로 세부적인 요구 사항에 도달하기 전에 작성되지만 클라이언트 및 프로젝트 요구 사항에 따라 요구 사항에 가장 적합한 하이브리드 문서를 만들도록 선택할 수 있습니다. 일반적으로 SOW는 팀과 클라이언트의 이해 관계자 간의 합의를 조기에 구축하는 데 사용되어야 합니다. SOW는 프로젝트의 입력 및 출력은 물론 가정 및 제한 사항을 정의합니다. 이 시점에서 고객이 고객을 위해 수행할 작업에 대한 "개괄적인 그림"을 제공하도록 요청하는 것은 드문 일이 아닙니다. 이 시점에서 대답하는 것은 약간 위험할 수 있습니다. 세부 사항을 정의하지 않고 특정 사항이나 약속을 피하도록 최선을 다하는 것이 좋습니다. 제안 및/또는 요구 사항 문서를 아직 작성하지 않은 경우 프로젝트 비용이 얼마인지 알 수 없습니다. 즉, 이 시점에서 판단을 내려야 합니다. 기본 웹 사이트와 같은 프로젝트에서 작업 중이고 이전에 여러 유사한 프로젝트를 성공적으로 완료했거나 동일한 클라이언트와 작업한 적이 있다면 약간의 여지가 있습니다. 프로젝트 후반에 불편한 상황이 발생하는 것보다 항상 주의를 기울이는 편이 낫다는 점을 기억하십시오. 작업 기술서는 약 2~3페이지여야 하며 최소한 다음을 포함해야 합니다.

3장: 컨설턴트 및 프리랜서를 위한 제안

제목 페이지 개정 내역 프로젝트 참조 번호 프로젝트 요약 시작일 종료일 요율/가격 프로젝트 설명 활동 및 산출물 항목별 비용 및 지급 일정 확인 및 승인

요소가 친숙해 보입니까? 제안서의 축소된 버전을 활용하여 SOW를 구성할 수 있습니다. 이제 클라이언트를 위해 수행하는 작업을 식별할 수 있는 두 가지 유형의 문서를 작성하는 방법을 배웠습니다. 이 문서는 모든 고객을 위해 수행하는 모든 프로젝트 작업의 기초가 되어야 하며 귀하와 귀하의 고객에게 귀하의 프로젝트에 대해 잘 정의된 행진 명령 세트를 제공할 것입니다.

작업 명세서

프로젝트 목표 및 접근 방법 탐색할 별을 파악하십시오 좋은 프로젝트의 핵심 중 하나는 명확한 프로젝트 목표와 잘 이해된 접근 방식으로 팀을 시작하는 것입니다. 이상적으로는 프로젝트 리더가 귀하를 위해 이를 정의해 줄 것입니다. 하지만 그렇지 않은지 어떻게 알 수 있습니까? 이 장에서는 프로젝트 목표 설정에 대해 설명하고 이러한 목표를 확고히 하는 데 도움이 되는 몇 가지 질문을 제공합니다. 또한 몇 가지 일반적인 프로젝트 접근 방식(또는 방법론)과 이것이 작업 방식에 어떤 영향을 미칠 수 있는지에 대해서도 논의할 것입니다. 캐롤린 챈들러

와이

전체 팀과 함께 처음으로 프로젝트 시작 단계에 있습니다. 프로젝트 관리자는 몇 가지 자료를 나눠주고 프로젝트에 대한 개요를 제공합니다. 회의가 끝날 때까지 이상적으로는 다음 정보가 있어야 합니다.

프로젝트가 회사에 중요한 이유는 무엇입니까? 이해 관계자는 프로젝트의 성공 여부를 어떻게 판단합니까? 프로젝트는 어떤 접근 방식이나 방법론을 따를 것인가? 다음과 같은 핵심 사항에 대한 주요 날짜 또는 이정표는 무엇입니까?

비즈니스 이해 관계자의 승인? 이러한 모든 질문은 이해관계자가 프로젝트에 대해 갖는 기대치, 즉 프로젝트가 달성할 내용과 참여 방법에 관한 것입니다. 처음 두 질문은 프로젝트의 목표와 관련이 있고 마지막 두 질문은 프로젝트 접근 방식과 관련이 있습니다. 프로젝트 목표는 프로젝트의 측정 가능한 목표에 대한 진술입니다. 목표에 대해 더 자세히 이야기합시다.

프로젝트 목표 구체화 목표는 프로젝트 전체에서 사용할 중요한 초점 렌즈입니다. 이는 클라이언트 회사의 전반적인 비즈니스 전략에서 비롯되어야 하므로 프로젝트 목표는 회사 내 전략적 이니셔티브와 일치해야 합니다. 예를 들어, 새로운 잠재 고객 그룹(시장이라고 함)에게 어필하기 위한 전략적 이니셔티브가 있는 경우, 귀하가 만들고 있는 사이트나 응용 프로그램은 관련 제품 및 서비스에 대한 온라인 액세스를 해당 시장에 제공하기 위한 노력일 수 있습니다. . 그러면 해당 프로젝트의 목표는 해당 시장에 도달하고 참여하는 데 집중됩니다. 명확한 목표는 프로젝트 전체에 반영됩니다. 비즈니스 이해관계자로부터 아이디어를 수집할 때 올바른 질문을 합니다. 사용자와 함께 조사를 계획하고 결과 분석에 집중합니다. 이해관계자와 사용자로부터 수집한 아이디어를 세부적으로 변환하고 변환합니다.

프로젝트 요구 사항의 통합 목록으로 회사에 대한 가치를 기준으로 해당 프로젝트 요구 사항의 우선 순위 지정

프로젝트 목표를 확고히 하다

효과적인 인터랙션 디자인 생성 개발이 시작된 후 디자인 변경 요청 관리 배포 활동(예: 교육 및 커뮤니케이션) 동안 노력 집중

새 사이트 또는 애플리케이션 출시 전과 출시 중에 사용자에게 알림) 고객 회사의 요구 사항을 충족했는지 한 번 결정

프로젝트가 시작됨 새 프로젝트를 시작할 때 프로젝트 스폰서(프로젝트의 성공에 직접적인 책임이 있는 비즈니스 이해 관계자)의 프로젝트 목표와 비즈니스 이해 관계자의 프로젝트 관련 요청 세트가 있을 수 있습니다. 그리고 고객으로부터, 그러나 그들은 모두 약간 흐릿할 수 있습니다(그림 4.1). 귀하의 목표는 프로젝트 성공의 척도로 사용할 수 있는 확실한 진술로 이러한 내용을 명확히 하는 것입니다.

프로젝트 관련 요청

회사 전략 퍼지 목표

사용자 니즈 이해관계자 아이디어

퍼지 목표

사용자 불만 이해관계자 아이디어

그림 4.1 모호한 목표, 아이디어 및 요구 사항

확실한 목표는 이해하기 쉽습니다. 내부 용어를 사용하지 마십시오. 별개의. 모호한 진술을 피하십시오. 대신 다음과 같은 문구를 사용하십시오.

요구 사항의 우선 순위를 정할 때 유용합니다. 측정 가능. 독립적으로 설정할 수 있음을 구체적으로 진술하십시오.

당신의 성공을 결정하기 위한 측정. 모호한 목표를 정의하여 명확하고 측정 가능하게 만들면 결정의 기반이 될 수 있는 견고한 목표가 됩니다.

4장: 프로젝트 목표 및 접근 방식

그림 4.2 구체화 중인 목표

회사 전략 프로젝트 목표

목표로 간주될 수 있는 많은 진술을 듣게 될 것입니다. 아래와 같은 퍼지 항목을 분석하면 목표를 공고히 하고 프로젝트 팀 내에서 보다 효과적으로 커뮤니케이션하는 데 도움이 됩니다. 사업 옹호자

비

"우리의 목표는 산업 x에서 시장 리더가 되는 것입니다."

이는 회사 전체의 목표이지만 특정 프로젝트에는 너무 광범위합니다. 이를 위해서는 회사의 여러 이니셔티브가 함께 모여야 합니다. 하나의 사이트나 응용 프로그램이 이에 도움이 될 수 있지만 회사 전체가 이 하나의 사이트나 응용 프로그램에 대해 관심을 갖고 결국 대성공을 거두지 않는 한 전체 부담을 처리할 수 없을 것입니다. 사업 옹호자

비

"우리의 목표는 고객층 사이에 흥분을 불러일으키는 것입니다."

사이트나 애플리케이션이 이에 영향을 미칠 수 있기 때문에 이것이 더 좋지만 여전히 너무 모호합니다. 흥분을 일으키는 것이 왜 중요합니까? 그 흥분이 어떻게 비즈니스 요구를 충족시키는 것으로 해석됩니까? 성공했는지 어떻게 알 수 있습니까? 사업 옹호자

비

"우리의 목표는 웹 사이트의 트래픽 양을 늘리는 것입니다."

이제 우리는 거기에 도달하고 있습니다. 이것은 측정하기 쉽지만 중간 단계에 너무 집중되어 있습니다. 더 많은 트래픽을 생성한다고 가정해 보십시오. 사람들이 도착한 후 원하는 작업을 수행하지 않으면 도움이 되지 않을 수 있습니다.

프로젝트 목표를 확고히 하다

퍼지 목표는 클라이언트의 욕구와 더 큰 목표에 대한 감각을 제공할 수 있습니다. 이를 통해 온라인 판매 수익을 10% 늘리는 것과 같은 보다 견고한 프로젝트 목표를 세울 수 있습니다. 온라인 광고 수익을 20% 늘립니다. 고객의 현재 및 잠재 고객 수를 늘립니다.

데이터베이스를 최소 20,000으로 설정합니다. 기본 사용자에게 높은 평가와 참조가 많은 콘텐츠를 제공합니다.

(이 항목은 "높은 평가" 및 "높은 참조"를 측정하는 방법을 결정하기 위해 약간의 작업이 필요하지만 그 요소를 기반으로 합니다.)

이들 각각은 프로젝트에 의해 측정되고 영향을 받을 수 있습니다. 또한 귀하의 디자인 및 제공되는 기능과 매우 밀접하게 매핑할 수 있습니다. 예를 들어, 고객 데이터베이스 확장이라는 목표를 달성하기 위한 방법으로 온라인 뉴스레터를 제공하는 것은 매우 일반적입니다. 뉴스레터를 전달하려면 데이터베이스에 추가될 고객 이메일 주소를 캡처해야 합니다. 목표는 또한 새로운 요구 사항을 가져올 수 있습니다. 예를 들어 사이트의 기사에 부여된 평균 등급으로 성공을 측정하는 경우 사용자가 등급을 부여할 수 있는 기능이 필요합니다. 이러한 방식으로 목표는 사이트에 대한 아이디어를 수집할 때 집중하는 데 도움이 되며 나중에 프로젝트 요구 사항이 될 수 있습니다. 여러 목표가 있는 경우 비즈니스 스폰서 및 프로젝트 팀과 함께 우선 순위 목록을 작성하십시오. 목표는 때때로 설계 중에 서로 충돌하며 팀은 우선 순위가 무엇인지 알아야 합니다. 우선 순위가 지정된 최종 목표 목록은 프로젝트 스폰서가 제공해야 하지만 논의의 핵심 부분이 될 수 있습니다. 방법에 대해 이야기합시다.

UX 디자이너가 어떻게 도울 수 있습니까? 프로젝트 초기에 프로젝트 목표가 명확하지 않은 경우 촉진 기술을 발휘할 수 있습니다. 주요 이해관계자와 워크숍을 개최하여 프로젝트 팀이 프로젝트의 비즈니스 관련 맥락을 이해하도록 돕습니다(올바른 이해관계자 식별에 대한 자세한 내용은 다음 장 참조). 일반적으로 2~4시간 동안 진행되는 이 세션의 목표는 회사의 강점, 약점,

4장: 프로젝트 목표 및 접근 방식

기회와 위협. SWOT 분석이라고 하는 이것은 일반적인 비즈니스 분석 기술이며 시장에서 회사의 위치를 논의하는 한 가지 방법입니다. 이 시간을 회사의 경쟁에 대해 논의하는 데 사용할 수도 있습니다. 강점과 약점 이해 SWOT 분석의 SW는 프로젝트와 관련된 회사의 현재 강점과 약점입니다. 강점과 약점에는 내부 프로세스와 외부 인식이 포함될 수 있으며 종종 서로 영향을 미칩니다. 예를 들어 대규모 연구 개발(R&D) 부서가 있는 회사는 출판된 원본 연구의 대규모 소스에 액세스할 수 있지만(강점) 일반 사용자가 해당 콘텐츠에 더 쉽게 액세스할 수 있도록 도와줄 사람이 없을 수 있습니다. , 회사가 "너무 학문적"(약점)이라는 인식으로 이어집니다. 기회와 위협 식별 OT는 SWOT의 미래 지향적 절반입니다. 경쟁업체와 회사를 차별화하는 점을 고려할 때 새로운 틈새 시장을 개척하거나 현재 틈새 시장을 강화하기 위해 추구할 수 있는 미래 이니셔티브는 무엇입니까? 어떤 상황이 그러한 계획을 위협할 수 있습니까? 예를 들어, 우리 R&D 회사는 원래 연구(기회)에 대해 보다 접근하기 쉬운 특집 기사를 게시하기 위해 작가를 고용하기로 결정할 수 있지만 현재 사이트 도구 집합에 강력한 콘텐츠 관리 기능이 없으면 게시 프로세스가 엄청나게 느려질 수 있습니다. 이는 경쟁자에게 보다 신속하게 대응할 수 있는 기회(위협)를 제공할 수 있습니다. 경쟁사 비교 회사의 주요 경쟁사는 무엇입니까? 개발 중인 사이트의 경쟁자는 누구입니까? 특히 대기업이나 새로운 사이트의 경우 다를 수 있습니다. 직접적인 경쟁자는 아니지만 고려해야 할 흥미로운 모델을 나타내는 사이트가 있습니까? 다른 전자 상거래 사이트를 검토하여 귀하가 판매하는 제품을 판매하는지 여부와 판매 방법을 확인하면 많은 것을 배울 수 있습니다. Pull It Together SWOT와 경쟁사 토론은 서로 상호 작용하기 때문에 동시에 토론하기에 좋은 주제입니다. 이야기하기 어렵다

프로젝트 목표를 확고히 하다

경쟁자가 누구인지 모른 채 미래의 위협—미래의 기회에 대해 이야기하기 시작하면 새로운 경쟁자가 떠오를 수 있습니다. 여기에서 회사의 경쟁사와 SWOT에 대한 전체적인 그림을 갖게 되면 회사 전략 내에서 프로젝트의 전반적인 적합성뿐만 아니라 프로젝트 목표를 정의하기가 더 쉬워지고 우선 순위가 명확해집니다. 프로젝트 목표를 확고히 하면 프로젝트가 달성할 내용에 대한 기대치를 이해하는 데 도움이 됩니다. 다음으로 프로젝트 실행 방법에 대한 기대에 대해 이야기해 보겠습니다. 프로젝트 접근 방식을 이해하면 효과적으로 협업하고 적시에 적임자를 참여시키는 데 도움이 됩니다.

프로젝트 접근 방식 이해 프로젝트의 전반적인 접근 방식 또는 방법론을 아는 것은 언제 어떻게 참여할 것인지, 프로젝트 팀 및 비즈니스 이해 관계자와 같은 다른 사람을 어떻게 참여시켜야 하는지 이해하는 데 중요한 부분입니다. 때로는 프로젝트 수만큼 많은 프로젝트 접근 방식이 있는 것처럼 보입니다. 프로젝트에 대한 올바른 접근 방식을 선택하는 방법은 그 자체로 큰 주제입니다. 선택하는 방법론은 프로젝트 팀의 구조와 위치, 프로젝트에 사용되는 기술, 공동 작업이 회사 문화의 일부인 정도 등 많은 요소에 따라 달라질 수 있습니다. 이 책의 목적상 프로젝트 스폰서 및 프로젝트 관리자와 같이 프로젝트의 성공에 책임이 있는 사람들에 의해 접근 방식이 주로 결정되는 프로젝트에 참여했다고 가정합니다. 이 상황에서 주요 목표는 접근 방식을 이해하고 비즈니스 이해 관계자와 사용자에게 효과적으로 적용하는 것입니다. 여기서는 가장 일반적인 접근 방식 두 가지와 프로젝트에서 발생할 수 있는 변형을 보여주는 세 번째 접근 방식에 중점을 둘 것입니다. 주목해야 할 중요한 점은 대부분의 접근 방식이 동일한 단계를 포함한다는 것입니다. 전체 전략, 접근 방식 및 팀 구조를 계획합니다. 프로젝트 요구 사항을 정의합니다. 상호 작용 및 시각적 개념을 디자인하고 이를 세부적으로 발전시킵니다.

사양. 솔루션을 개발, 테스트 및 개선합니다.

4장: 프로젝트 목표 및 접근 방식

메시징, 교육 및 계획된 출시를 통해 솔루션을 배포합니다. 개선 사항을 제안하여 프로젝트를 확장하십시오.

이러한 단계의 이름은 겹치는 정도와 정보가 문서화되는 방식에 따라 다를 수 있습니다. 그러나 각 단계의 일반적인 활동은 대부분의 프로젝트와 여기에 제시된 세 가지 모델 모두에 공통적입니다.

폭포수 접근 방식 폭포수 접근 방식은 프로젝트의 단계를 별도의 개별 단계로 처리하는 것과 관련되며, 다음 단계가 시작되기 전에 한 단계의 승인이 필요합니다. 예를 들어, 정의 단계가 끝날 때 하나 이상의 요구 사항 문서에 서명하는 비즈니스 이해 관계자가 요구 사항을 승인할 때까지 설계 단계는 본격적으로 시작되지 않습니다. 승인

계획

승인

디자인 정의 개발 배포 확장

그림 4.3 각 단계가 다음 단계로 "떨어지는" 폭포수 접근법의 예

순수한 폭포수 접근법의 문제점은 각 단계가 이전 단계에 대한 최소한의 변경으로 완료될 수 있다고 가정한다는 것입니다. 따라서 일반적으로 디자인 단계에서 새로운 요구 사항이 나오면 정의 단계가 끝날 때 승인된 문서에 변경 사항을 제안해야 하므로 계획과 일정이 취소될 수 있습니다.

민첩한 접근 방식 변경이 일정하기 때문에 프로젝트 팀은 지속적으로 폭포수 모델보다 더 유연한 접근 방식을 찾고 있습니다. 많은 방법론이 보다 유동적인 접근 방식을 따르며 일부 단계는 서로 나란히 발생합니다. 예를 들어 웹 사이트 버전은 기민하거나 신속한 개발 접근 방식을 사용하여 신속하고 반복적인 일정에 따라 릴리스될 수 있습니다. 민첩한 접근 방식은 일반적으로 신속한 협업에 더 중점을 두고 자세한 문서 및 공식적인 승인에 대한 초점을 줄입니다. 프로젝트 접근 방식 이해

반복 1

개발하다

반복 2

개발하다

반복 3

개발하다

디자인 전개 디자인 전개 디자인 전개 정의

정의하다

승인 정의

계획

릴리스 확장 배포

그림 4.4 민첩한 접근 방식의 예

진정한 애자일 접근 방식(예를 들어 애자일 얼라이언스의 구성원이 개발한 모범 사례를 따름)은 팀 구성원 간의 공식적인 역할 정의에 거의 초점을 두지 않고 구성원이 물리적으로 서로 옆에 있는 소규모 팀을 필요로 합니다. 이러한 방식으로 작업하면 매우 높은 수준의 협업이 가능하므로 설계, 개발 및 테스트 단계 사이에 무거운 문서의 필요성이 줄어듭니다. 팀원은 질문을 하고, 빠른 화이트보드 세션에서 다른 팀원과 함께 답을 찾고, 자세한 문서화 및 승인의 지연 없이 솔루션을 구현할 수 있습니다. 이해관계자 검토는 많은 반복 중 하나가 릴리스될 때 완전히 작동하는 시스템에서 발생하며 결과 입력은 다음 반복이 계획될 때 고려됩니다. (반복은 특정 사이트 또는 애플리케이션의 초안 버전입니다.) 애자일 접근 방식이 설계된 대로 작동하면 아름답습니다. 그러나 대부분의 회사와 대부분의 컨설팅 계약 내에서 팀은 순수한 애자일 접근 방식을 거의 따르지 않습니다. 부분적으로는 회사에서 점점 더 분산된 팀과 원격 작업자를 사용하고 있기 때문에 순수한 애자일 접근 방식을 최대한 활용하는 데 필요한 높은 수준의 협업을 유지하기가 어렵습니다.

수정된 접근 방식 대부분의 프로젝트는 분산된 팀과 팀원의 이직으로 인한 위험을 줄이기 위해 충분한 구조와 문서를 제공하면서도 비교적 민첩한 방식으로 변화에 대응할 수 있는 충분한 협업과 반복을 통해 두 세계의 장점을 결합하는 접근 방식을 따르려고 합니다. . 예를 들어, 프로젝트는 폭포수 모델을 따를 수 있지만 팀 간에 주요 협업 지점이 있도록 단계에 중복을 포함할 수 있습니다. 이를 통해

4장: 프로젝트 목표 및 접근 방식

각 단계에서 더 일찍 표면에 대한 잠재적 변화. 여기에는 반복 주기가 더 짧은 초기 릴리스(예: 특정 사용자 그룹에 대한 베타 릴리스)도 포함될 수 있습니다. 그런 다음 새 사이트를 완전히 배포하기 전에 해당 릴리스의 피드백을 통합할 수 있습니다. 계획

정의하다

디자인 개발

설계

정의하다

개발 배포 베타

릴리스 확장 배포

그림 4.5 베타 릴리스로 수정된 폭포수

그림 4.5에서 설계 단계 내의 더 작은 반복을 주목하십시오. 이는 UX 디자이너로서 팀에 제공하는 가장 큰 가치 중 하나입니다. 와이어프레임(11장) 및 프로토타입(12장)과 같은 도구를 사용하면 많은 개발 시간이 투입되기 전에 아이디어의 빠른 반복에 대한 피드백을 수집할 수 있습니다. 그림 4.5와 같은 수정된 폭포수 접근 방식은 가장 일반적으로 사용되는 방법론이므로 이 책의 틀을 형성하는 접근 방식입니다. 그러나 정의 및 설계와 같은 기본 활동이 여전히 필요하기 때문에 여기에서 다루는 많은 주제는 접근 방식의 세부 사항에 관계없이 프로젝트에 적용됩니다.

딥 다이빙 프로젝트에서 민첩한 접근 방식을 사용하는 경우 요구 사항을 캡처하는 방법으로 "사용자 스토리"를 작성하는 것과 같이 요구 사항을 수집하는 동안 고유한 요구 사항이 있을 것입니다. User Stories Applied: For Agile Software Development(Mike Cohn 저)(Addison-Wesley Professional, 2004)를 추천합니다.

프로젝트 접근 방식 이해

접근 방식은 나에게 어떤 영향을 줍니까? 접근 방식을 알면 다음과 같은 여러 가지 사항을 이해하는 데 도움이 됩니다. 언제, 어떤 질문을 해야 하는지. 예를 들어, 당신이

순수한 폭포수 접근 방식으로 작업하려면 정의 단계에서 캡처한 요구 사항에 설계 단계에 필요한 모든 정보가 포함되도록 추가 노력을 기울여야 합니다. (다음 장에서 요구 사항에 대해 논의할 것입니다.) 프로젝트 팀원이 협업하는 방법과 방법에 대한 기대

가까운 협력이 될 것입니다. 예를 들어 민첩한 접근 방식에는 매우 긴밀한 협업이 필요합니다. 폭포수 접근 방식은 대부분의 시간 동안 개별 작업을 포함할 수 있으며 접점은 일주일에 한 번 또는 여러 번 있습니다. 문서에 필요한 세부 수준과

형식. 승인 지점에서 제출되는 문서는 거의 법적 계약과 같이 형식적이어야 합니다. 일반적으로 다음 단계로 이동하기 전에 승인이 필요한 폭포수 접근 방식에서는 더 공식적인 문서가 필요합니다. 그러나 전체 릴리스 및 배포를 위해 특정 반복이 준비되는 경우와 같이 주요 결정 지점에서 정보를 캡처하기 위해 애자일 접근 방식을 사용할 때 일부 공식적인 승인 문서가 있을 수도 있습니다. 이해 관계자의 승인을 포함하는 중요한 이정표 및

다른 그룹에 배포. 이 접근 방식은 승인 지점에서 이해 관계자의 승인 및 베타 릴리스 동안 잠재적 사용자의 피드백을 포함하여 프로젝트의 다양한 지점에서 다양한 대상이 제공해야 하는 것을 결정합니다. 이제 프로젝트 목표를 확정하고 프로젝트 접근 방식을 이해했으므로 다음 장에서는 정의 단계의 기본 작업인 요구 사항 수집부터 시작하겠습니다.

4장: 프로젝트 목표 및 접근 방식

비즈니스 요구 사항 솔루션을 만들기 전에 문제를 알아야 합니다. 프로젝트 팀이 모일 때까지 수행해야 할 작업에 대한 많은 아이디어를 듣거나 떠올렸을 것입니다. 어떤 기능이 가장 중요한지에 대한 의견과 함께 회사의 일부 저명한 구성원(비즈니스 이해 관계자)이 제공한 기능 목록이 이미 있을 수 있습니다. 이들은 프로젝트에 대한 비즈니스 요구 사항의 요소이며 좋은 시작입니다. 프로젝트 종료 시 완벽한 솔루션을 확보하려면 여러 관점에서 요구 사항을 생성하고 명확히 해야 합니다. 이 장에서는 비즈니스 이해 관계자의 요구 사항을 수집하고 자세히 설명하는 데 중점을 둘 것입니다. 캐롤린 챈들러

씨

4장에서는 모호한 목표를 다루고 자신과 프로젝트 팀을 위해 목표를 명확히 하는 데 도움이 되는 몇 가지 방법에 대해 논의했습니다. 프로젝트의 초기 단계에서는 상대적으로 모호한 일련의 요청이 있을 가능성이 있습니다. 이해 관계자의 아이디어, 사용자 불만 또는 사용자 요청일 수 있습니다. 프로젝트에서 이러한 유용하고 추적 가능한 구성 요소를 만들려면 이러한 아이디어를 요구 사항으로 통합해야 합니다. 요구 사항은 사이트 또는 응용 프로그램에서 수행해야 하는 작업을 정의하는 설명입니다. 이상적으로는 비즈니스 요구 사항 해결해야 하는 전반적인 요구 사항에 대한 통찰력 제공 다양한 이해 관계자가 제공하는 요구 사항을 표현하고 통합 설계 방법에 대해 너무 구체적이지 않고 방향을 제시합니다.

달성 우선 순위 지정 및 추적 목적을 위한 고유한 작업 단위 역할을 합니다.

다음은 전자 상거래 웹 사이트의 기능에 대한 아이디어의 예입니다. 정의 단계 초기에 두 명의 다른 비즈니스 이해 관계자로부터 "고객은 온라인으로 주문을 추적할 수 있습니다."라는 동일한 아이디어를 얻을 수 있습니다. 이것은 요구 사항에 대한 좋은 기반이지만 모호합니다. 고객이 자신의 상태를 추적할 수 있는 것이 비즈니스에 중요한 이유와 같이 요구 사항의 세부 사항에 대한 질문을 시작하십시오.

온라인 주문? 예를 들어 고객 지원 전화 횟수를 줄이기 위한 것입니까? 회사는 현재 온라인으로 패키지를 추적할 수 있는 기능이 있습니까?

그렇지 않은 경우 추적 기능에 대한 새로운 요구 사항을 캡처하거나 회사가 타사와 파트너 관계를 맺어야 할 수 있습니다. 추적은 얼마나 정확해야 합니까? 어떤 종류의 정보

추적 세부 정보에 포함되어야 합니까? 예를 들어 사이트에서 배송 시간에 대한 업데이트된 추정치를 제공해야 합니까? 이러한 종류의 질문을 하면 모호한 아이디어를 견고한 요구 사항으로 통합하는 데 도움이 됩니다. 또한 동일한 진술이 다른 사람들에게 다른 것을 의미할 수 있음을 분명히 할 것입니다.

5장: 비즈니스 요구 사항

예를 들어, 한 이해 관계자는 패키지 추적이 UPS.com 또는 다른 사이트에 입력할 수 있는 추적 번호가 포함된 확인 이메일 Stakeholder Idea를 수신하는 것과 관련이 있다고 생각할 수 있으므로 고객 이해 관계자는 패키지가 도달한 최신 중지를 볼 수 있습니다. 아이디어 또 다른 이해관계자는 회사가 패키지 추적의 한계를 뛰어넘고 고객이 GPS를 통해 패키지를 추적하고 온라인 지도를 사용하여 실시간으로 정확한 위치를 확인할 수 있는 기능을 개발하는 데 투자해야 한다고 생각할 수 있습니다. 상상할 수 있듯이 여기에는 사용자 경험과 범위에 상당한 차이가 있습니다! 프로젝트 초기에 이러한 차이점을 설명하는 것이 중요합니다. 그렇지 않으면 비즈니스 이해 관계자의 의도를 놓치고 잠재적으로 프로젝트 목표를 놓치는 솔루션을 개발하게 될 것입니다. 이로 인해 이해 관계자가 불행해지고 기능을 재설계해야 하는 경우 시간과 비용을 낭비하게 됩니다. 따라서 명확하고 상세한 요구 사항은 전체 프로젝트의 핵심 부분입니다. 통합된 프로젝트 요구 사항 목록에 도달하려면 다음 단계가 필요합니다. 1. 사이트 또는 경쟁업체의 현재 상태를 이해합니다. 2. 현재 및 잠재적 사용자뿐만 아니라 비즈니스 이해 관계자로부터 요구 사항과 아이디어를 수집합니다. (사용자 작업에 대한 자세한 내용은 6장을 참조하십시오.) 3. 아이디어를 요구 사항으로 통합합니다. 4. 프로젝트 목표에 따라 요구 사항의 우선 순위를 지정합니다. (우선 순위 설정에 대한 제안은 9장을 참조하십시오.)

비즈니스 및 사용자 프로젝트 요구 사항 요구 사항 회사 전략

그림 5.1 비즈니스 이해 관계자의 아이디어를 비즈니스 요구 사항으로 통합하고 사용자와 함께 조사한 아이디어를 사용자 요구 사항으로 통합합니다. 그런 다음 프로젝트 목표를 사용하여 우선순위를 정하는 노력에 집중하고 통합된 프로젝트 요구 사항 목록을 만듭니다.

비즈니스 요구 사항

먼저, 요구 사항 수집 중에 나올 아이디어에 대한 컨텍스트를 가질 수 있도록 사이트의 현재 상태를 이해하는 방법에 대해 이야기해 보겠습니다.

현재 상태 이해 디자인 중인 사이트나 응용 프로그램의 세부 사항에 뛰어들 때 사이트의 현재 상태를 이해하거나(이미 존재하는 사이트를 재설계하는 경우) 주요 경쟁업체를 더 철저히 이해하여 자신의 기반을 다지는 것이 중요합니다. (새 사이트나 애플리케이션을 디자인하는 경우). 이해관계자 인터뷰를 통해 현재 상태에 대해 많은 것을 알 수 있습니다(자세한 내용은 몇 페이지에 있음). 스스로도 많은 이해를 얻을 수 있으며, 이는 이해관계자 인터뷰 및 사용자 연구 노력을 위한 강력한 기반이 될 수 있습니다. 배경 정보를 얻고 요구 사항이 될 수 있는 아이디어를 생성하는 좋은 방법은 휴리스틱 분석을 수행하는 것입니다.

다른 이름으로… 휴리스틱이라는 단어는 경험 법칙 또는 모범 사례를 의미합니다. 휴리스틱 분석은 일반적으로 UX 디자이너가 수행하는 사용 가능한 디자인에 대한 일련의 규칙(휴리스틱)에 대한 제품 검토를 의미하게 되었습니다. 사용자 친화적인 사이트는 분석에 사용하는 휴리스틱의 대부분 또는 전부를 따릅니다. 휴리스틱 평가, 전문가 검토 또는 이러한 용어의 일부 조합이라고 하는 이 기술을 들을 수도 있습니다.

휴리스틱 분석 휴리스틱 분석은 사용자 경험 분야의 모범 사례를 기반으로 기존 디자인의 유용성을 평가하는 데 사용할 수 있는 기술입니다. 재설계 프로젝트 초기에 현재 사이트에서 이러한 분석을 수행하거나 경쟁 사이트를 분석하여 다른 회사보다 더 나은 사용자 경험을 제공할 수 있는 기회를 파악할 수 있습니다. 결과는 개선을 위한 권장 사항을 포함하여 사이트의 강점과 약점을 설명하는 문서입니다. 완료 후 더 깊은

5장: 비즈니스 요구 사항

분석된 사이트에 대한 이해 및 새 사이트의 요구 사항에 기여할 아이디어 목록. 예를 들어, 일반적으로 사용되는 휴리스틱은 Jakob Nielsen의 10가지 사용성 휴리스틱 목록(Jakob Nielsen 사이트, www.useit.com/papers/heuristic/heuristic_list.html에서 전체 목록 보기)에 있는 것입니다.

시스템 상태의 가시성. 시스템은 합리적인 시간 내에 적절한 피드백을 통해 사용자에게 무슨 일이 일어나고 있는지 항상 알려야 합니다.

사이트에는 이 휴리스틱을 따르지 않을 수 있는 많은 상황이 있습니다. 예를 들어 사용자가 다운로드 버튼을 클릭했는데 파일이 다운로드되고 있다는 메시지가 표시되지 않는다고 가정해 보겠습니다. 다운로드가 시작되었지만 시스템에서 사용자에게 파일이 다운로드 중임을 알리지 않았습니다. 따라서 사용자는 처음에 버튼을 놓쳤다고 생각하고 버튼을 다시 클릭할 수 있습니다. 그런 다음 다시 클릭합니다.... 이로 인해 여러 다운로드가 발생할 수 있으며 잠재적으로 사이트의 성능과 사용자 모두에게 문제를 일으킬 수 있습니다. 깨닫지 못한 채 여러 다운로드가 진행 중입니다. 휴리스틱 분석 중에 이를 문제 영역으로 기록하고 설명하고 그 영향을 평가할 수 있습니다. 요구 사항 목록에 추가할 수 있는 문제를 해결할 수 있는 아이디어를 공유할 수도 있습니다. 휴리스틱 분석을 수행하는 이유는 무엇입니까? 이러한 종류의 분석을 수행하는 것은 설계에 대한 피드백을 얻는 비교적 빠르고 저렴한 방법입니다. 휴리스틱 분석은 설계 품질에 대한 일반적인 이해를 제공하고 잠재적인 설계 문제를 식별하는 데 도움이 될 수 있습니다. 이 활동은 최종 사용자와 직접 관련되지 않으며 실제 사용자 조사를 대체해서는 안 됩니다. 예를 들어, 휴리스틱 결과의 50%만이 나중에 연구에 의해 실제로 검증될 수 있습니다. 그러나 분석을 통해 팀은 우려할 만한 영역을 잘 처리할 수 있습니다. 기존 제품이나 사이트를 재설계하는 경우 재설계 노력이 배후에서 계속됨에 따라 즉각적인 개선으로 이어질 수 있는 명백한 빠른 수정 사항을 식별하는 데에도 유용할 수 있습니다.

현재 상태 이해

어떻게 해야 합니까? 사용하는 특정 휴리스틱은 프로젝트마다 다를 수 있지만 분석을 수행하는 프로세스는 일반적으로 동일하게 유지됩니다. 1. 제품 및 프로젝트 배경 지식을 수집합니다. 사이트의 목표, 지원해야 하는 주요 사용자 그룹 목록, 사용자가 작업할 가능성이 있는 환경 종류에 대한 정보, 사용자가 가질 수 있는 전문 지식에 대한 기본적인 이해가 있는지 확인하십시오. 가지다. (예를 들어 일반 소비자를 위한 사이트와 약사를 위한 사이트의 분석은 다를 것입니다.) 마지막으로 도움이 필요한 경우 다양한 경쟁 사이트나 애플리케이션을 방문하면 가장 일반적인 용어 및 응용 프로그램을 이해하는 데 도움이 될 수 있습니다. 관심 분야. 2. 사용할 휴리스틱을 선택합니다. 참조할 휴리스틱이 많이 있습니다. Jakob Nielsen의 목록 외에도 많은 UX 디자이너는 Bruce Tognazzini의 디자인 원칙 목록(www.asktog.com/basics/firstPrinciples.html)을 참조합니다. 사이트의 주제에 익숙해지면 특히 둘 이상의 사이트를 분석하는 경우 몇 가지 자신의 주제를 추가할 수 있습니다. 목록을 관리 가능한 크기(예: 8~12)로 유지해야 합니다. 너무 많은 휴리스틱은 당신과 당신의 독자들에게 다루기 힘든 기술을 만들 수 있습니다. 3. 사이트에서 우선 순위가 지정된 영역을 살펴보고 휴리스틱을 잘 따르거나 놓친 영역을 식별합니다. 각 관찰에는 다음 정보가 있어야 합니다. 일반적인 관찰. 조사 결과를 요약하는 짧은 진술. 사람들이 보고서를 살펴볼 때 빠르게 참조할 수 있도록 번호가 매겨지는 것이 이상적입니다. 간단한 설명입니다. 관찰의 맥락을 설명하는 한두 단락(예: 특정 프로세스에서 문제를 발견한 지점). 임팩트 순위. 이 등급은 문제 관찰에 대해 높음, 중간 또는 낮음일 수 있으며, 사이트가 잘한 것을 공유하는 경우 긍정적인 발견에 대한 메모가 될 수 있습니다. 일반적으로 영향력이 큰 문제는 많은 사용자가 특정 작업을 실패하거나

5장: 비즈니스 요구 사항

영구적으로 정보 손실(예: 사용자가 작업 중인 문서에 대한 변경 사항을 잃게 만드는 문제) 중간 영향 문제는 불만과 오류를 유발하지만 돌이킬 수 없는 문제를 일으키지는 않는 문제입니다. 영향이 적은 문제는 약간의 혼란을 야기할 수 있지만 일반적으로 시간 손실이나 좌절로 이어지지는 않는 사소한 문제입니다. 추천. 이는 귀하가 공유하는 다음 단계 또는 아이디어이며 귀하가 직면한 문제에 대한 해결책이 될 수 있습니다. 그림 5.2는 휴리스틱 분석에 나타날 수 있는 이러한 요소의 예를 보여줍니다. 관찰 #4 검색 기능이 모든 가능한 결과를 가져오지 않는 것 같습니다.

높은 관심

검색 기능의 샘플 테스트 결과가 엇갈렸습니다. 덜 일반적으로 다루는 주제를 특징으로 하는 상대적으로 새로운 게시물에서 이름을 사용하여 검색하면 때때로 결과가 반환되지 않았습니다. 또한 기본 검색은 비디오가 아닌 새로운 스토리에 대한 링크만 반환하는 것으로 보입니다. 권장 사항 1. 새로 추가된 콘텐츠가 공개되기 전 또는 직후에 색인화되고 검색 가능한지 확인합니다. 2. 탐색 중인 사용자가 팔로우할 스레드가 더 많도록 검색 결과가 다시 표시될 때 관련 콘텐츠(예: 유사한 카테고리의 스토리 또는 유사한 태그가 있는 스토리)를 표시하는 것을 고려하십시오. 3. 범주별로 정리된 결과를 제공하는 범용 검색을 고려하십시오. 4. 검색어 로그를 활용하여 자주 검색되는 항목을 파악합니다. 또한 사용자가 찾는 데 어려움을 겪고 있는 항목에 대한 통찰력을 제공할 수도 있습니다.

그림 5.2 휴리스틱 분석 보고서의 샘플 관찰

4. 조사 결과를 프로젝트 팀과 주요 이해관계자에게 제시합니다. 귀하의 관찰 및 권장 사항을 통해 안내하십시오. 왜 그렇게 평가했는지 토론하십시오. (이는 또한 6장에서 설명한 기술 중 하나를 사용하여 결과를 검증하는 방법에 대한 준비된 권장 사항을 가질 수 있는 좋은 시간입니다.) 휴리스틱 분석은 요구 사항 수집에 어떻게 도움이 됩니까? 휴리스틱 분석을 완료하면 사이트(또는 경쟁업체)의 현재 상태와 요구 사항 수집에 기여할 수 있는 아이디어 목록을 더 깊이 이해할 수 있습니다. 또한 요구 사항 수집 세션에서 다루어야 할 주제를 구성하는 방법에 대한 몇 가지 아이디어를 얻을 수 있으며, 이는 해당 프로세스의 다음 단계로 이어집니다.

현재 상태 이해

이해관계자로부터 아이디어 수집 이 장 시작 부분의 예에서 보았듯이 "고객은 온라인에서 주문을 추적할 수 있습니다."와 같은 아이디어에 대한 컨텍스트를 얻지 못하면 다음과 같은 이해관계자 간의 기대 차이를 놓칠 위험이 있습니다. 패키지가 GPS로 추적되기를 원하는 우리 친구의 것. 프로젝트에서 저지르는 가장 흔한 실수 중 하나는 솔루션에 대한 기대와 문제를 먼저 이해하지 않고 기능을 포착하고 요구 사항이라고 부르는 것입니다. 그렇다면 요구 사항 수집 프로세스가 왜 그렇게 자주 단축됩니까? 아이디어를 수집하고 이를 요구 사항으로 결합하는 데는 상당한 시간이 걸릴 수 있습니다. 우선 순위를 정할 수 있도록 요구 사항을 설명하는 데 필요한 질문의 수를 과소 평가하기 쉽습니다. 그리고 프로세스가 제대로 구성되지 않았거나 참여가 불완전한 경우 프로젝트 전체에서 지속될 수 있는 많은 변동이 있을 수 있습니다. (이동은 의사 소통 및 참여 부족으로 인한 추가 회의 및 작업 반복에 시간을 낭비하는 것입니다. 이는 최상의 솔루션을 찾기 위한 노력으로 유효한 솔루션을 설계하고 테스트하는 작업의 일부인 보다 생산적인 작업 반복과 다릅니다.) 비즈니스 요구 사항에 초점을 맞추면서도 시간 낭비를 피하는 균형 잡힌 요구 사항 프로세스를 권장합니까? 효율적인 프로세스를 위한 몇 가지 단계는 다음과 같습니다. 1. 역할과 책임을 설명합니다. 프로젝트 팀 구성원이 요구 사항을 수집할 때 채워야 하는 역할을 이해하도록 합니다. 2. 요구 사항에 초점을 맞춘 인터뷰 또는 회의 중에 시간을 가장 효율적으로 사용할 수 있도록 올바른 이해 관계자를 올바른 그룹으로 모으십시오. 3. 다룰 주제와 회의 중에 물어볼 질문을 포함하여 회의 계획을 세웁니다. 4. 회의를 효율적으로 운영하여 아이디어를 포착하고 설명을 얻습니다. 아이디어를 조사하여 각각의 필요 사항을 파헤칩니다. 회의가 끝나면 관련된 이해 관계자에게 감사하는 것을 잊지 말고 통합된 우선 순위 목록으로 이동한 후 진행 상황을 업데이트하십시오. 이러한 각 단계를 자세히 살펴보겠습니다.

5장: 비즈니스 요구 사항

개요 책임 비즈니스 요구 사항을 수집하는 작업에는 일반적으로 아이디어를 수집하기 위해 주요 비즈니스 이해 관계자를 인터뷰하는 프로젝트 팀 구성원이 포함됩니다. 비즈니스 이해 관계자는 회사 내에서 프로젝트의 성공에 비즈니스 중심 이해 관계가 있거나 기여할 주제 전문 지식이 있거나 둘 모두를 가진 사람들입니다. 이 사람들은 프로젝트에 풀타임으로 참여하지는 않지만 프로세스의 주요 지점에 참여해야 하며 요구 사항 수집이 그러한 지점 중 하나입니다. 그들은 또한 (말하자면) 하루 일과를 가지고 있기 때문에 미리 계획하지 않는 한 그들의 시간은 귀중하고 종종 얻기가 어렵다는 것을 명심하십시오. 프로젝트 스폰서(또는 스폰서)는 프로젝트의 성공에 대한 직접적인 책임을 지는 비즈니스 이해 관계자이며, 종종 이사와 같이 회사의 상대적으로 높은 수준에 있습니다. 그 또는 그녀는 전체 프로젝트 수명 주기 동안 매일 프로젝트에 참여하지는 않지만 요구 사항 수집에 적극적으로 참여하고 비즈니스 이해 관계자의 높은 수준의 참여를 보장할 것입니다. 후원자는 일부 또는 모든 세션에 참석할 수도 있습니다. 프로젝트 팀에는 진행 중인 리소스로 프로젝트에 공식적으로 할당된 사람들이 포함됩니다. 이들은 프로젝트 관리자, UX 디자이너, 비즈니스 분석가, 기술 책임자, 비주얼 디자이너, 품질 보증 책임자 등으로 참여할 수 있습니다. 프로젝트의 규모에 따라 이것이 주요 작업일 수 있습니다. 프로젝트 팀 자체 내에서 요구 사항 수집 중 책임이 명확하지 않은 경우가 많습니다. 초기에 책임을 정의하는 데 시간을 할애하면 효율적인 수집 프로세스를 보장하는 데 도움이 됩니다. 다음은 요구 사항을 수집하는 동안 각 팀원이 담당할 특정 책임을 결정할 때 물어볼 몇 가지 질문입니다.

가장 생산적인 그룹의 이해관계자? 여기에는 내부 및 외부 이해 관계자(파트너, 공급업체 등)가 모두 포함될 수 있습니다. 누가 비즈니스 이해 관계에 대한 주제 및 질문의 구조를 만듭니다.

홀더 회의? 이것은 시간이 허락한다면 팀을 위한 훌륭한 공동 작업입니다. 그런 다음 주 퍼실리테이터는 회의에 잘 어울리는 구조로 그것들을 배열할 수 있습니다. 회의를 주관하는 사람은 누구입니까? 누가 메모하고 어떻게 공유합니까?

이해관계자로부터 아이디어 수집

나중에 누가 누구와 후속 조치를 취합니까? 기술 팀의 누군가가 모든 회의에 참석합니까?

그렇다면 그 사람은 어떻게 관련되어 있습니까(듣고 있습니까, 입력을 제공하고 있습니까, 아니면 다른 무엇인가)? UX 디자이너로서 이러한 영역 중 하나 이상을 주로 담당하는지 여부에 관계없이 프로세스에 가져올 중요한 기술이 있습니다. 주제와 질문에 대한 구조를 만들려면 명확한 범주화 요령이 필요하며(정보 아키텍처와 잘 어우러지는 것처럼 들림) 진행 기술은 물론 모든 참석자가 참여하는 회의 주제를 유지하는 데 중요합니다.

올바른 이해 관계자 수집 이해 관계자 인터뷰의 주요 목적은 다양한 관점에서 관련 프로젝트 관련 아이디어, 요구 사항, 지식 및 불만 사항을 이해하여 프로젝트 요구 사항에 적용할 수 있도록 하는 것입니다. 또한 많은 다른 그룹을 참여시켜 각 그룹이 프로젝트에서 자신의 발언권을 가졌다고 느끼고 결과적으로 최종 솔루션을 구매할 수 있도록 때로는 언급되지 않은 이점이 있습니다. 동의를 얻기 위해 사람들을 참여시키는 것이 실용적이기보다는 정치적인 것처럼 보일 수 있지만 프로젝트 전반에 걸쳐 귀하를 지원할 네트워크와 연결하는 핵심 단계인 경우가 많습니다. 또한 대화하지 않은 사람이 프로세스 후반에 문제를 제기할 때 발생할 수 있는 11시간 변경을 피하는 데 도움이 될 수 있습니다. 따라서 다양한 사람들을 참여시키는 것이 종종 좋은 생각입니다. 반면에 일정과 예산을 염두에 두어야 합니다. 많은 수의 사람들을 참여시키려면 회의에만 시간이 걸립니다. 추세를 파악하고 중복 사항을 통합하기 위해 메모를 정렬하는 시간은 말할 것도 없고요. 효율성과 자신의 건전성을 위해 대화할 그룹의 우선 순위를 정하고 해당 그룹에서 팀의 사고 리더 역할을 할 핵심 인물을 선택하는 것이 좋습니다. 참여할 수 있는 이해관계자는 누구입니까? 이러한 그룹은 종종 좋은 아이디어 소스가 됩니다. 사이트에 의존하는 이니셔티브가 있는 그룹(예:

사이트에 정보를 표시해야 하는 마케팅 캠페인)

5장: 비즈니스 요구 사항

사이트 뒤에서 직접 프로세스를 지원해야 하는 그룹 또는

콘텐츠 제공, 데이터 입력 및 관리, 수집된 정보에 대한 즉각적인 대응 등 전화나 온라인 지원 등 고객 서비스의 일선 또는

고객을 직접 대면하여(예: 소매점에서 또는 배송을 통해) 판매, 제품 관리 또는 컨설팅 서비스를 제공하는 사람

제공되는 제품 및 서비스 채용 목표를 충족하기 위한 인적 자원 투자자 및 미디어에 정보를 제공하기 위한 홍보 개발해야 하는 기타 관계를 담당하는 모든 그룹

포함해야 하는 개인을 선택할 때 프로젝트 스폰서 및 관련 그룹에 익숙한 프로젝트 팀 구성원의 도움을 받아 올바른 것을 선택하십시오. 사람들. 좋은 토론을 진행할 수 있는 그룹을 만듭니다. 올바른 방법은 없지만 한 가지 일반적인 방법은 다음과 같이 이해 관계자를 부서별로 그룹화하는 것입니다. 마케팅(5명) 제품 관리(4명) 고객 지원(2명) 영업(4명)

소규모 프로젝트에는 모든 사람이 함께 만나는 두 개 이상의 일련의 공동 작업 세션에서 이러한 각 그룹의 한 사람이 포함될 수 있습니다. 이해 관계자와 회의의 일반적인 구조(다음 섹션에서 설명)를 염두에 두고 나면 회의 예약을 시작할 수 있습니다. 적어도 몇 주 전에 일정을 잡으십시오. 모든 사람을 한 방에 모이게 하는 것은 어려울 수 있습니다.

이해관계자로부터 아이디어 수집

회의 계획 수립 올바른 이해 관계자를 선택하려는 노력과 병행하여 다루어야 할 주제 목록과 질문해야 할 질문을 함께 모으십시오(이는 이해 관계자 목록을 수정하는 데도 도움이 됨). 몇 가지 질문이 그룹마다 동일할 수 있지만 만나는 각 그룹마다 다른 계획이 있어야 합니다. 또한 회의에서 목표로 삼고 있는 세부 수준을 결정해야 합니다. 한 번만 많은 사람들과 만나는 경우(예: 위에서 제안한 여러 부서의 구성원) 아이디어를 수집하고 싶을 것입니다. 회의 중 세부 사항. 이 경우 이해 관계자 중 한 명이 "고객이 온라인으로 주문을 추적할 수 있습니다"라는 아이디어를 제공하는 경우 이 기능이 중요한 이유와 이해 관계자가 이를 잘 수행하는 사이트를 즉석에서 생각할 수 있는지 간단히 물어볼 수 있습니다. 이러한 질문은 하나의 진술에 전체 회의를 소비하지 않고도 기능에 대한 이해 관계자의 기대치 간의 주요 차이점을 제기하는 데 도움이 됩니다. 그런 다음 프로젝트 팀과 함께 아이디어의 특정 세부 사항을 작업하고 이해 관계자와 함께 돌아가서 생성한 요구 사항이 여전히 원래 아이디어를 나타내는지 확인합니다. 전자 상거래 사이트를 재설계하고 있으며 각 그룹별로 한 번씩 회의를 갖고 다양한 이해 관계자를 만나고 있다고 가정해 보겠습니다. 다음은 영업 부서의 그룹과 회의 계획의 예입니다.

영업: 요구 사항 수집 회의 참가자 내부 영업: Jenny Bee, Tracy Kim, Joseph Arnold 관리 책임자: Kevin Abernathy, Cat Parnell 시간 프레임: 2시간 목표: 현재 영업 프로세스를 이해하고 웹이 더 나은 지원을 할 수 있는 방법에 대한 문제와 기회를 식별합니다. 그 과정. 배경: 구매 결정을 내리는 방법에 대한 좋은 배경 정보를 제공하는 구매 프로세스에 대한 PowerPoint 프레젠테이션을 검토했습니다. 고객 서비스팀과도 이야기할 계획입니다.

5장: 비즈니스 요구 사항

판매: 요구 사항 수집 회의 계속 질문 판매 프로세스: 제품 라인마다 판매 프로세스가 어떻게 다릅니까? 지역차가 있나요? 고객 규모(예: 소기업 대 대기업)에 따라 약간의 차이가 있습니까? 지난 2년 동안 이 프로세스가 어떻게 발전했으며 향후 3~5년 동안 어떻게 발전할 것으로 예상됩니까? 잠재 고객은 구매해야 하는 모든 항목과 함께 작동하는 방식을 어떻게 이해합니까?

전체 인상: 현재 사이트의 주요 방문자는 누구라고 생각하십니까? 왜? 그들은 어떤가요? 그들은 사이트에서 무엇을 달성하려고 합니까? 오늘날 웹은 판매 프로세스 및/또는 판매 완료율에 어떻게 기여합니까? 고객이 구매 결정을 내리기 위해 어떤 정보가 필요합니까? 현재 사이트에서 해당 정보를 사용할 수 있습니까? 찾기 쉽나요? 정확합니까? 오늘날 사이트의 콘텐츠를 유지하는 것이 얼마나 어렵습니까? 사이트에서 어떤 메트릭을 얻습니까? 어떤 추가 지표가 유용하다고 생각하십니까? 왜?

미래 구상: 미래의 웹 사이트에 대해 생각할 때 판매 프로세스를 더 잘 지원하기 위해 무엇을 할 수 있습니까? 판매에 중요한 사이트의 현재 기능과 기능은 무엇입니까? 필요하지 않은 것은 무엇입니까? 없어진 물건 있어요?

요약: 우리가 해결하지 못한 다른 생각, 제안 또는 우려 사항이 있습니까? 어떤 웹 사이트가 영업 지원에 탁월한 역할을 한다고 생각하십니까? 회사가 고객 만족도를 향상시키기 위해 할 수 있는 가장 중요한 일은 무엇입니까?

이해관계자로부터 아이디어 수집

효과적인 회의 운영 다음은 요구 사항 수집 회의에 도움이 되는 몇 가지 방법입니다. 공유 어휘가 사용되는지 확인 팀 모임 요구 사항이 용어 및 정의의 공통 목록에 동의하면 많은 혼란을 피할 수 있습니다. 예를 들어 시스템을 사용하는 사람들을 사용자, 고객 또는 클라이언트라고 부를 것인가? 사람들은 인터랙션 디자이너 또는 정보 설계자라는 용어에 더 익숙합니까? 혼동을 피하기 위해 각 회의를 시작할 때 시간을 내어 어떤 용어가 사용되었고 그 의미가 무엇인지 설명하십시오. 다른 용어나 역할 간의 관계를 설명하는 데 도움이 되는 몇 가지 시각적 요소를 만들면 도움이 될 수도 있습니다(그림 5.3 참조). 범주

범주

하위 카테고리

주제

기사

그림 5.3 프로젝트 용어 및 관계를 보여주는 다이어그램

프로젝트에서 사용될 산출물에 대한 공통 용어는 이해 관계자가 프로세스와 예상되는 결과 유형을 이해하는 데 도움이 됩니다. 이것은 그들의 시간과 노력이 아이디어의 블랙홀에 들어가지 않을 것이라는 신뢰를 쌓을 수 있습니다. 일반적으로 동일한 단어를 한두 번 이상 정의하는 경우(특히 정의가 매번 미묘하게 변경되는 경우) 프로젝트 용어집에 넣고 프로젝트 팀과 공유하는 것을 고려하십시오. 프로젝트를 시작할 때 정리하면 좋은 다른 용어의 예는 다음과 같습니다.

5장: 비즈니스 요구 사항

상호 작용할 역할(예: 구직자 대 클라이언트 또는

텐트 제작자 대 편집자) 광범위하게 참조될 주요 산출물(기능적 특성-

정보, 와이어프레임, 사이트 맵) 및 차이점에 대한 간략한 설명 서로 다른 수준의 정보 간의 구분(예: 범주)

그림 5.3의 정보) 니즈와 아이디어의 구분

아이디어에 귀를 기울이고 필요 사항 파악 이해관계자는 필요한 것처럼 보이는 진술을 할 수 있습니다. 예를 들어 보겠습니다. 사업 옹호자

"사이트에 블로그가 필요합니다."

비

이것은 실제로 아이디어이지 필요가 아닙니다. 그런 다음 블로그 기능이 완전히 설계되고 구현되면 솔루션이 되지만 이를 요청하는 이해 관계자의 핵심 요구 사항을 가장 잘 충족하는 솔루션은 아닙니다. 블로그가 왜 중요한지 물어보면 “관련성이 있고 연락이 닿아야 합니다. 모두가 블로그에 대해 이야기하고 있는데 블로그를 포함하지 않으면 시대에 뒤쳐질 것 같은 느낌이 듭니다.” "우리는 더 많은 광고 수익을 창출하기 위해 사람들이 사이트를 반복적으로 방문하도록 하는 방법이 필요하며 블로그는 팔로어가 있는 갓 게시된 콘텐츠를 의미합니다." "우리는 생각의 리더로 자리매김해야 하며 블로그는 우리의 전문성을 보여줄 수 있는 보다 개인적인 방법입니다." "우리는 고객과 소통하고 혁신할 수 있는 더 나은 방법이 필요하며, 블로그를 통해 댓글을 받아 고객의 생각을 들을 수 있습니다." 이러한 각 진술은 유효한 요구 사항을 설명합니다. 이를 통해 특정 기능에 대한 요청 이면의 동인에 대해 배우게 되며, 이를 통해 요구 사항을 통합하고 우선 순위를 정할 때 합의를 도출하는 데 도움이 됩니다.

이해관계자로부터 아이디어 수집

통합 요구 사항 회의가 끝나면 수집한 아이디어를 일반적인 기능 영역으로 분류합니다. 겹치는 부분이 많다는 것을 알게 될 것입니다. 이는 특정 아이디어가 이해 관계자로부터 많은 지지를 받고 있다는 좋은 신호입니다. 중복을 제거하고 이해 관계자의 의도를 효율적으로 포착하는 아이디어 목록을 통합하십시오. 수집한 아이디어를 프로젝트의 유용하고 추적 가능한 구성 요소로 바꾸려면 이러한 아이디어를 요구 사항으로 통합해야 합니다. 구름에서 형성되는 빗방울을 생각해 보십시오. 하나의 크고 정의되지 않은 구름에서 더 많은 수의 잘 정의된 빗방울로 이동하고 있습니다. 따라서 "고객은 온라인으로 주문을 추적할 수 있습니다"와 같은 아이디어 클라우드를 얻을 때 시스템이 수행해야 하는 작업을 정의하는 고유한 설명으로 변환해야 합니다. 결과 요구 사항은 해결해야 하는 전반적인 요구 사항에 대한 통찰력을 제공해야 합니다. 다양한 이해 관계자가 제공한 요구 사항을 표현하고 통합합니다.

우선 순위 지정 및 추적 목적을 위해 고유한 작업 단위 역할을 합니다.

아이디어에서 요구 사항으로 이동하기 시작할 때 기술 책임자(또는 프로젝트에서 개발 팀을 대표할 수 있는 다른 사람)가 참여하여 나중에 우선 순위를 정할 때 필요한 노력을 추정하는 데 도움이 되는 질문을 하도록 합니다. 전담 품질 보증 팀원이 있는 경우 해당 팀원이 요구 사항을 통합하는 데 도움이 되는 매우 상세한 질문을 제공할 수도 있습니다. 추적 아이디어를 요구 사항에 자세히 설명하려면 추적이 얼마나 정확해야 합니까? 추적 세부 정보에 어떤 종류의 정보를 포함해야 합니까? ~을 위한

예를 들어 업데이트된 배송 시간 추정치를 제공해야 합니까? 이러한 종류의 질문은 프로젝트에 할애할 시간이 많은 경우 독창적인 아이디어를 제공한 이해 관계자와 함께 질문하고 자세히 설명할 수 있습니다. 해당 이해 관계자에 대한 액세스 권한이 많지 않은 경우 프로젝트 팀 토론을 통해 세부 사항을 직접 해결할 수 있습니다.

5장: 비즈니스 요구 사항

그런 다음 프로젝트 스폰서와 함께 요구 사항을 검토하여 선택 사항이 비즈니스에 적합한지 확인합니다. 표 5.1에는 추적 아이디어에서 통합할 수 있는 요구 사항의 종류와 이를 캡처할 수 있는 방법이 나열되어 있습니다. 표 5.1

비즈니스 요구 사항의 예

영역

주문 추적

삼

주문 추적

요구 사항

비즈니스 요구 사항

주문은 다음을 통해 추적할 수 있습니다.

셀프 서비스 장려

추적 코드 입력

배달 중 (지원

온라인

혜택)

사용자는 팩을 추적할 수 있습니다.

효율성의 혁신을 보여주십시오.

트럭을 따라가는 GPS에 의한 연령

cient 납품 (경쟁력 있는

또는 비행기

혜택)

사용자는 지난 365일 동안의 모든 과거 주문을 볼 수 있습니다.

셀프 서비스 (영업, 지원 혜택)

어떤 경우에는 표의 처음 두 요구 사항의 경우와 같이 요구 사항이 서로 겹치는 경우가 있습니다. 둘 다 추적 방법입니다. GPS 보기를 통해 패키지를 찾기 위해 코드를 입력할 수 있기 때문에 동일한 시스템에서 함께 살 수 있습니다. 그러나 GPS 관련 요구 사항은 아마도 더 많은 노력이 필요하고 다른 기능과 독립적으로 우선 순위를 지정해야 하기 때문에 분리됩니다. 진술을 통합할 때 사용자 요구와 충돌할 수 있다고 생각되는 비즈니스 요구 사항을 기록합니다. 예를 들어 비즈니스 요구 사항은 전자 메일 주소와 같은 잠재 고객의 개인 정보를 수집하는 것일 수 있습니다. 그러나 고객은 정보 제공에 대해 의구심을 가질 수 있습니다. 결국 양식을 작성하는 데 시간이 걸리고 보안 및 개인 정보 보호가 문제이며 이 단계는 수행하려는 더 큰 작업을 방해할 수 있습니다. 이와 같은 충돌을 식별하면 비즈니스 및 사용자 요구를 모두 충족하는 데 도움이 될 수 있는 아이디어를 제공하기 시작할 것입니다. 트래킹의 예로는 "친구에게 보내기" 기능을 사용하여 이메일 주소를 캡처하여 사용자에게 편의를 제공할 수 있습니다. 이것은 친구에게 보내기가 우선 순위를 정하기 위해 조합에 넣는 요구 사항이 될 수 있음을 의미합니다. 이와 같은 아이디어

이해관계자로부터 아이디어 수집

비즈니스 및 사용자 요구 사항을 모두 충족하는 데 도움이 될 수 있으므로 캡처하기에 좋습니다. 또한 비즈니스 문제에 대한 디자인 솔루션을 생각하기 시작했기 때문에 정의 단계와 디자인 단계(4장 참조) 사이의 겹치는 영역에 있습니다.

디자인 정의 개발 비즈니스 요구와 사용자 요구 사이의 잠재적 충돌은 다음 장에서 논의할 사용자 조사 중에 탐구할 훌륭한 사항입니다. 사용자 조사를 통해 표 5.1을 전체 잠재적 요구 사항으로 확장할 수 있으며 프로젝트 요구 사항 목록의 우선 순위가 지정됩니다(그림 5.1 참조, 9장에서 자세히 설명). 비즈니스 요구 사항 수집은 일반적으로 기술적 가능성 탐색 및 사용자 요구 사항 수집과 동시에 발생합니다. 다음: 사용자에 대해 이야기할 시간입니다!

5장: 비즈니스 요구 사항

사용자 조사 파티에 초대하는 손님에 대해 알아보기 사용자를 더 잘 이해하거나 사이트 버전에서 사용자 행동을 테스트하기 위해 프로젝트 수명 주기 전반에 걸쳐 사용할 수 있는 많은 사용자 조사 기법이 있습니다. 이 장에서는 프로젝트의 초기 단계에서 가장 일반적으로 사용되는 몇 가지 방법에 중점을 둘 것입니다. 이러한 기술은 프로젝트 중에 가장 우선 순위가 높아야 하는 사용자 그룹을 정의하고, 사용자 경험 디자인 분야의 모범 사례를 사용하여 그들의 요구 사항과 좌절감을 상황에 맞게 배치하고, 현재 사이트(존재하는 경우)의 성능을 평가하는 데 도움이 됩니다. . 캐롤린 챈들러

사용자 조사의 기본 단계 1. 기본 사용자 그룹을 정의합니다. 여기에는 디자인하려는 사용자의 주요 유형을 설명하는 프레임워크를 만드는 것이 포함되어 연구를 위해 사용자를 모집하는 데 노력을 집중할 수 있습니다. 2. 사용자 참여 계획. 여기에는 프로젝트의 필요에 따라 연구에 사용자 그룹을 참여시키는 하나 이상의 기술을 선택하는 것이 포함됩니다. 3. 연구를 수행합니다. 여기서는 인터뷰 및 설문 조사와 같은 기본 기술을 다루고 이를 수행하는 방법에 대한 팁을 제공합니다. 4. 사용자 그룹 정의를 확인합니다. 연구에서 배운 내용을 사용하여 사용자 그룹 모델을 강화할 수 있습니다. 그런 다음 이 모델은 페르소나(7장에서 논의)와 같은 보다 상세한 도구 개발을 위한 플랫폼 역할을 할 것입니다. 5. 사용자 요구 사항을 생성합니다. 이는 사이트에 포함될 수 있는 특징 및 기능에 대한 설명입니다. 이러한 문을 비즈니스 요구 사항에 추가하고(5장에서 설명) 프로젝트 요구 사항이 되도록 우선 순위를 지정합니다(9장에서 설명). 이 장에서는 첫 번째 단계인 사용자 그룹 정의부터 시작하여 처음 세 단계를 다룹니다.

사용자 그룹 정의 프로젝트 초기에 사용자 조사를 계획하는 것은 닭이 먼저냐 달걀이 먼저냐의 딜레마처럼 느껴질 수 있습니다. 필요한 사람이 누구인지 아직 모르는 경우 올바른 사람과 대화하고 있는지 어떻게 확인합니까? 시작하는 한 가지 방법은 디자인할 사용자의 초기 또는 임시 정의를 만드는 것입니다. 이것은 사이트의 기본 사용자 그룹을 설명하며 사용자가 사이트를 경험하는 방식에 영향을 미칠 수 있는 올바른 역할, 인구 통계 또는 기타 변수에 대한 조사 노력을 집중하는 데 도움이 될 수 있습니다. 사용자 그룹 정의는 높은 수준(각 대상 사용자 그룹을 정의하는 목록)이거나 상세하고 시각적(여러 유형의 사용자와 사용자가 상호 작용하는 방식을 보여주는 다이어그램)일 수 있습니다.

6장: 사용자 조사

회사의 기본 .com 사이트에 대한 높은 수준의 정의에는 잠재적 구매자, 현재 구매자, 파트너 및 구직자와 같은 사용자 그룹이 포함될 수 있습니다. 사용자 조사를 위한 그룹 정의를 시작하면 사용자 그룹의 우선 순위를 더 자세히 지정하기 시작합니다. 초기 정의는 사이트와 상호 작용할 수 있는 잠재적 사용자 유형에 대한 비즈니스 이해 관계자 및 프로젝트 팀 구성원의 집단 지식을 기반으로 합니다. 이러한 정의는 다양한 사용자 그룹이 가질 수 있는 일부 목표 및 속성을 수집하여 구축할 수 있습니다. 다음은 사용자 그룹을 정의하는 기본 단계입니다. 1. 사이트의 다양한 사용자를 정의하는 데 도움이 되는 속성 목록을 만듭니다(다음 섹션에서는 가장 일반적인 일부를 다룹니다). 2. 관련 유형의 사용자(예: 고객)와 접촉하는 회사의 사람들과 특성에 대해 논의합니다. 3. 잠재 사용자가 사이트나 애플리케이션을 사용하는 이유와 방법에 가장 큰 영향을 미치는 특성에 우선 순위를 지정합니다. 4. 연구 및 디자인에 집중할 사용자 그룹을 정의합니다. 다음 섹션에서는 이러한 속성을 수집하는 데 도움이 되는 몇 가지 브레인스토밍 기술과 우선 순위를 지정하고 모델링하는 방법(연구 노력을 집중하는 데 도움이 되는 다양한 사용자 유형의 표현 생성)을 자세히 살펴봅니다.

속성 목록 만들기 속성 목록의 좋은 시작은 사용자와 관련하여 지침을 제공할 수 있는 조직이 보유한 조사 또는 기타 문서를 수집하고 흡수하는 것입니다. 다음은 몇 가지 가능한 출처입니다.

소소한 정보, 마케팅 전략 및 사업 계획 현재 고객 및 기타 인구 통계 데이터의 시장 세분화

마케팅 부서에서 수집 이전에 실시한 사용자 조사(몇 가지 예는 표 6.1 참조)

사용자 그룹 정의

사용자 만족도 조사, 피드백 양식 등 설문조사 자주 발생하는 문제에 대한 고객 서비스 보고서

다음으로, 조직 내에서 현재 또는 잠재 사용자에 대한 통찰력이 있는 사람을 식별합니다. 포함해야 하는 사람의 수와 다양성은 프로젝트 유형과 범위 및 일정에 따라 다릅니다. 사용자 그룹의 초기 정의가 수명이 짧을 수 있다는 것을 알고 있는 경우(예: 사용자 조사가 계획되는 동안 1~2개월만 사용) 2~3명의 참가자만 포함할 수 있습니다. 초기 정의가 디자인 프로세스의 상당한 부분을 유지해야 한다고 생각하는 경우(예를 들어 일부 디자인이 완료된 후 사용성 테스트를 수행할 때까지 작업할 이 정의만 있는 경우) 더 많은 참가자를 포함하고 관점의 단면이 있는지 확인하십시오. 일부 가능한 참가자에는 브랜드 표현, 세분화 및 캠페인을 담당하는 마케팅 직원이 포함됩니다. 영업사원; 제품 관리자; 고객 서비스 또는 지원 담당자 그리고 트레이너. 또한 이 연습에 프로젝트 팀 리더십 및 기타 비즈니스 이해 관계자를 포함시키는 것이 좋습니다. 그룹에 그들이 상호 작용하는 경향이 있는 다양한 유형의 잠재 사용자에 대해 생각하도록 요청하십시오. 그런 다음 그들이 접한 몇 가지 일반적인 속성을 나열하도록 요청하십시오. 다음은 다를 수 있는 몇 가지 예입니다. 사이트의 주제와 관련된 기본 목표. 왜

사용자가 와서 무엇을 달성하려고 합니까? 예를 들어, 품목 구매, 주식 거래 또는 특정 질문에 대한 답변을 얻는 것이 일반적인 목표입니다. 역할. 이것은 여러 가지 방법으로 정의할 수 있지만 한 가지 방법은 역할을

사용자의 주요 목표: 구직자, 지원 구직자, 잠재 고객 등. 더 많은 사용자 정보가 있으면 다양한 요구 사항이나 스타일에 따라 역할을 세분화할 수 있습니다. 예를 들어, 전자 상거래 사이트에서 쇼핑객은 특가 상품을 찾는 사람과 감식가를 포함할 수 있습니다. 연령, 성별, 가족(미혼, 기혼, 자녀),

소득 수준 및 지역. 교육 수준, 관련 지식 수준을 포함한 경험

기술(종종 기술 지식이라고 함), 주제 전문 지식 수준 및 사용 빈도(일회성, 간헐적, 빈번한). 88

6장: 사용자 조사

회사 사용자가 작업하는 규모를 포함한 조직 속성

부서, 직업 유형(초보자, 프리랜서, 중간 관리자, 임원), 임기(장기 또는 높은 이직률?), 작업 패턴(원격 근무, 출장 횟수). 이해 관계자가 잠재적 사용자를 설명할 때 가장 자주 나타나는 몇 가지 특성 목록이 있으면 중요도에 따라 우선 순위를 정한 다음 해당 계층을 사용하여 사용자 그룹을 정의하고 모델링할 수 있습니다.

우선 순위 지정 및 정의 위에 나열된 속성 중 다양한 사용자 그룹이 사이트를 사용하는 방법과 이유에 가장 큰 영향을 미친다고 생각하는 것은 무엇입니까? 사용자의 목표나 행동에 가장 큰 영향을 미칠 것으로 생각되는 것에 집중하세요. 이러한 특성의 우선순위를 정하고 4장에서 만든 목표를 기억하십시오. 이러한 목표는 선택을 유도하는 데에도 도움이 될 것입니다. 속성의 우선 순위를 지정하는 방법을 가장 잘 보여주는 예입니다. 주식, 옵션 및 선물의 온라인 거래를 위한 도구를 제공하는 회사와 협력하고 있다고 가정해 보겠습니다. 이 특정 회사는 전략의 일부가 온라인에서 스스로 주식을 거래하는 비전문가를 참여시키고 옵션 및 선물과 같은 새로운 유형의 제품 거래를 시도하도록 권장하는 것이라고 결정했습니다. 회사는 안전한 환경에서 실습을 원하는 사람들을 대상으로 사용하기 쉽고 거래 도구를 제공함으로써 이를 수행할 계획입니다. 비즈니스 이해 관계자와 속성을 논의할 때 다음 항목이 개인이 이러한 도구를 사용하는 방법에 가장 큰 영향을 미치는 것으로 보일 수 있습니다. 현재 거래 빈도, 특히 직접 온라인 거래 빈도

ing(예: 분기에 한 번, 하루에 한 번, 하루에 여러 번). 거래에 손을 대는 사람들(예: 한 달에 한 번)은 새로운 것을 시도하는 데 진지하지 않을 수 있는 반면, 이미 정규 거래를 하고 있는 사람들은 새로운 거래자를 대상으로 하는 도구에서 많은 가치를 찾지 못할 수 있습니다. 그러나 활동적인 시간제 트레이더는 회사 도구에 큰 관심을 가질 수 있습니다. 거래되는 상품 유형의 수: 주식 또는 주식, 옵션 및

선물. 이미 모든 유형의 제품을 거래하고 있는 사람들은 이미 자신의 도구에 대한 선호도가 있을 수 있지만 한 가지 유형만 거래하는 사람들은 다른 유형으로 확장할 준비가 되어 있을 수 있습니다. 사용자 그룹 정의

주제 전문 지식 수준(예: 거래에 대한 친숙함)

자귀). 이것은 튜토리얼과 용어집을 통해 그들이 얼마나 많은 도움이 필요한지 결정하는 데 도움이 될 것입니다. 기술에 정통한 수준(예: 구매에 익숙함)

온라인 및 온라인 뱅킹 및 거래). 이는 정보 프라이버시에 대해 얼마나 많은 안심이 필요한지, 온라인 인터페이스가 얼마나 고급 또는 단순해야 하는지에 영향을 미칩니다. 이러한 속성은 조사를 위해 타겟팅할 사용자 유형에 영향을 줄 수 있으므로 우선순위를 지정할 수 있습니다. 트레이더가 사는 곳이 트레이딩 방법이나 이유에 실질적인 영향을 미치지 않는 것 같으면 지역 특성이 연구 참가자를 위한 고려 사항으로 목록에서 제외될 수 있습니다. 반면에 특정 속성의 중요성이 많은 논의를 불러일으킨다면 설문 조사 질문이나 인터뷰 질문에 대한 좋은 주제가 될 수 있습니다(이 장의 뒷부분에서 설문 조사에 대해 논의할 것입니다).

높은

두 개 이상의 속성을 비교하면 우선순위를 정하는 데도 도움이 됩니다. 예를 들어 온라인 거래자에 대한 두 가지 속성을 사용하여 차트를 만들면 그룹이 일부 범위에 속하는 방식을 확인할 수 있습니다. 그림 6.1은 직접 거래 빈도와 거래된 제품 유형 수라는 두 가지 속성을 사용하여 만들 수 있는 대략적인 사용자 모델의 예입니다. 또한 토론에서 형성될 수 있는 결과 사용자 그룹을 보여줍니다.

전임 제품 전문가

정규직 정통한 제너럴리스트

직접 거래 빈도

"부업" 트레이더

보충 소득 거래자

활성 탐험가

장기 투자자

낮은

아마추어

낮은

높은

거래된 상품 유형의 수(주식, 옵션, 선물)

6장: 사용자 조사

그림 6.1 대략적인 사용자 모델을 나타내는 두 가지 속성의 차트. 이 모델을 공동으로 만들면 사용자 동기와 경험의 잠재적 차이에 대한 토론을 용이하게 할 수 있습니다.

이 사용자 모델은 다양한 사용자 유형에 대해 논의할 수 있는 높은 수준의 방법을 제공합니다. 이것은 최종 모델을 의미하지 않으며 사용자 그룹에 독점적으로 레이블을 지정하지 않습니다(사용자는 주식에 대한 장기 투자자일 수 있으며 옵션 또는 선물의 다른 가능성을 적극적으로 탐색할 수도 있습니다). 그러나 다양한 사용자 그룹에 대한 이해와 그들이 사이트를 사용하도록 동기를 부여하는 방법을 표현하기 시작합니다. 중요한 속성에 관한 이 토론은 또한 연구를 위해 사용자를 모집할 때 집중하고 싶은 속성을 찾는 데 도움이 됩니다. 거래 빈도가 중요하다고 판단하고 우선 순위가 현재 중간 수준의 빈도를 가진 사람들을 참여시키는 것이라고 판단되면 중간 빈도(예: 일주일에 1-3회)가 무엇인지 정의하고 싶을 것입니다. 그에 따라 연구 참가자를 모집하십시오. 조사 얘기가 나와서 말인데, 사용자를 프로젝트에 참여시키는 데 사용할 수 있는 기술에 대해 이야기해 봅시다.

사용자 모델만으로 설계할 수 있습니까? 조사를 수행하기 전에 사용자 모델을 만드는 것에 대한 사용자 경험 분야 내에서 논쟁이 있습니다. 그렇게 하면 실제 사용자 데이터를 얻기 전에 생각을 색칠할 수 있고 프로젝트 팀이나 프로젝트 스폰서가 모델을 사용자 조사의 대체물로 볼 수 있기 때문입니다. 검증되지 않은 모델을 사용하면 가정이 잘못될 위험이 더 커집니다. 그러나 사용자와 전혀 접촉하지 않는 프로젝트에서는 신중하게 고려한 모델(고객 서비스 그룹 또는 교육 그룹과 같은 프로젝트 팀 외부 소스로 확인)이 사용할 모델이 없는 것보다 낫습니다. 디자인 중.

조사 기법 선택 이제 포함하려는 사용자 그룹에 대한 대략적인 아이디어를 얻었으므로 다음 단계를 계획할 때입니다. 프로젝트 중에 수행할 사용자 조사 활동의 양과 유형에 대한 권장 사항입니다. 표 6.1은 가장 일반적으로 사용되는 연구 기법과 가장 유용한 시기에 대한 정보를 제공합니다. 프로젝트에 가장 적합한 것을 선택하는 데 도움이 되는 참조로 이 표를 사용하십시오. 다음 섹션에서는 각 기술에 대해 자세히 설명합니다.

연구 기법 선택

표 6.1

일반적인 사용자 조사 기법

활동

그것이 무엇인가

유용할 때

도전

일반적인 기간 *

사용자 인터뷰

사이트의 기본 사용자 그룹 중 하나에 속한 참가자와의 일대일 대화입니다.

사용자에 대한 액세스가 있지만 액세스 유형(직접 방문, 전화 등)은 다양합니다.

솔직한 의견을 얻습니다. 특히 인터뷰가 원격으로 진행되는 경우 태도와 맥락에 대한 정보를 수집하기 어려울 수 있습니다.

12번의 인터뷰에 2-4주: 계획하는 데 최대 1주, 인터뷰하는 데 1-2주, 결과를 모으는 데 최대 1주가 걸립니다.

문맥 조사

참가자가 일상적인 환경에서 어떻게 작업하는지 관찰하고 배우기 위해 현장을 방문합니다.

액세스 권한을 얻는 프로젝트 팀에는 정보 참여자가 거의 없습니다. 대상 사용자를 진행합니다. 사용자의 환경에 대해 사용자는 고유한 환경에서 작업하여 보안, 지적(예: 병원)에 대한 우려를 제기할 수 있습니다. 속성 및 intruUsers가 작동 중입니다. 상당히 복잡한 응용 프로그램을 사용하는 비즈니스의 경우 작업 또는 워크플로입니다. 평일에 방문하시면 더욱 편리합니다.

12개의 문의에 대해 3~4주: 계획하는 데 1주, 관찰하는 데 1~2주, 결과를 분석하고 보고하는 데 1주.

설문조사

다수의 사람들 사이에서 패턴을 식별하는 데 사용되는 주로 폐쇄형 답변(객관식)으로 구성된 일련의 질문입니다.

보다 정량적인 용어로 결과를 설명하고 싶습니다(예: "대상 사용자 그룹의 80%가 온라인에서 자동차를 구매하지 않는다고 말했습니다").

단기 설문조사의 경우 3~4주: 설문조사를 계획하고 작성하는 데 1주, 설문조사를 실행하는 데 1~2주, 결과를 분석하고 보고하는 데 1주가 걸립니다.

컨텍스트를 얻고 싶지만 사용자에게 갈 수 없습니다.

실제 성능보다 선호도에 대한 정보 수집에 더 관심이 있습니다.

6장: 사용자 조사

적절한 샘플을 얻습니다. 응답자를 특정 답변으로 유도하지 않고 정확한 답변을 얻을 수 있도록 질문을 잘 작성했는지 확인합니다.

표 6.1

일반적인 사용자 조사 기법(계속)

활동

그것이 무엇인가

유용할 때

도전

일반적인 기간 *

포커스 그룹

진행자가 특정 주제에 대한 질문을 통해 참가자를 이끄는 그룹 토론입니다. 주제에 대한 참가자의 감정, 태도 및 아이디어를 밝히는 데 중점을 둡니다.

팀은 사용자의 태도가 솔루션 사용에 큰 영향을 미칠 것이라고 믿습니다(예: 역사적으로 문제가 있었던 경우).

올바른 정보를 얻기 위해 질문을 타겟팅하는 방법을 이해합니다.

3–4주: 질문을 계획하고 작성하는 데 1주, 포커스 그룹을 수행하는 데 1–2주, 결과를 분석하고 보고하는 데 1–2주가 소요됩니다.

카드 분류

참가자에게는 카드에 항목(예: 주제)이 주어지고 의미 있는 그룹으로 분류하도록 요청받습니다.

항목이 많은 콘텐츠 소스 사이트에서 작업 중이며 사용자 그룹을 위한 효과적인 구조를 원합니다.

어떤 주제를 포함하는 것이 가장 좋은지 결정합니다.

3-4주: 계획 및 준비에 1주, 조사를 수행하는 데 1주, 결과를 분석하고 보고하는 데 1-2주가 소요됩니다.

사용성 테스트

사용자는 진행자가 관찰하는 동안 사이트나 애플리케이션에서 일반적인 작업을 수행하려고 시도하고 경우에 따라 사용자의 행동을 이해하기 위해 질문을 합니다.

기존 솔루션이 개선되고 있습니다.

집중할 적절한 작업 선택.

10명의 사용자 및 중간 형식의 경우 3~4주: 작업을 계획하고 작성하는 데 1주, 테스트를 실행하는 데 1주, 결과를 분석하고 보고하는 데 1~2주가 소요됩니다.

경쟁 솔루션을 테스트할 수 있습니다. 사용자가 작업을 완료(또는 시뮬레이션)할 수 있는 프로토타입이 있습니다.

그룹을 효과적으로 촉진합니다.

테스트를 수행하는 방법을 결정합니다.

* Typical Time Frame은 사용자가 예약한 시점부터 자주 필요한 시간을 나타냅니다. 6~8명의 사용자로 구성된 두 그룹을 가정합니다(사용자 수가 더 많은 설문 조사 제외). 여기에는 선별 설문지 작성 후 1~2주가 소요될 수 있는 모집 시간은 포함되지 않습니다.

얼마나 많은 연구 활동을 포함할 수 있습니까? 활동 중에서 선택하기 전에 팀이 사용자 연구에 얼마나 많은 돈과 시간을 할애할 수 있는지 스스로에게 물어보십시오. 클라이언트 회사가 사용자 조사에 얼마나 많은 관심을 갖고 있는지 이해하려면 다음 상황을 고려하십시오. 프로젝트 리더와 프로젝트 스폰서가 사용자 조사에 익숙하고 사이트가 특정 프로젝트 목표를 충족하는지 확인하는 것과 같은 알려진 목표를 위해 사용자 조사를 사용하는 데 관심이 있다면 연구 기법 선택에 더 많은 여유가 있을 것입니다.

둘 이상의 활동 또는 여러 번 수행하는 하나의 활동(예: 설계 테스트, 결과에 따라 변경, 새 설계 재테스트)을 계획할 때. 조직의 아무도 사용자 연구에 익숙하지 않고 그것에 대해 약간의 저항이 있다면, 한 라운드의 연구를 제안하고 당신과 프로젝트 팀, 비즈니스 이해 관계자. 연구 결과를 얻으면 프로젝트 팀은 무엇이 관련되어 있고 프로젝트가 어떤 이점을 얻을 수 있는지 더 잘 알 수 있습니다. 그러면 나중에 필요한 경우 더 많은 연구를 포함할 수 있는 강력한 사례를 갖게 됩니다. 최소 2회 이상의 연구를 할 여지가 있다면 사용자를 더 잘 이해하기 위해 정의 단계 또는 설계 단계 초기에 1회를 포함하는 것이 좋습니다. 그런 다음 개발이 시작되기 전에 한 번 더 포함하여 설계를 검증합니다. 예를 들어 작업 기반 애플리케이션의 경우 디자인하기 전에 사용자 인터뷰를 수행한 다음 프로세스 후반에 프로토타입에 대한 사용성 테스트를 수행할 수 있습니다. 또는 콘텐츠 소스의 경우 상황별 조회로 시작한 다음 카드 정렬 연습을 포함할 수 있습니다.

연구를 계획할 때 고려 사항 연구 기법을 계획할 때 다음 사항을 고려하십시오. 연구를 수행하는 이유: 연구를 통해 배우고 싶은 것 포함 대상: 위에서 설명한 기본 사용자 그룹 참가자 확보 방법: 참여할 사람들 모집 및 선별(즉, 그들이 목표로 하는 사용자 그룹에 속하는지 확인하기 위해 질문하기) 참가자에게 보상하는 방법 필요한 공간 및 장비 다루는 내용: 주요 주제 정보를 수집하는 방법: 관련된 사람의 수와 그들이 사용하는 도구 13장에서는 UX 디자이너가 사용하는 가장 일반적인 기술 중 하나인 사용성 테스트를 자세히 살펴보는 과정에서 이러한 각 고려 사항을 다룰 것입니다.

6장: 사용자 조사

참고 작업 기반 애플리케이션 및 콘텐츠 소스에 대한 자세한 내용은 2장을 참조하십시오.

Surfing Steve Baty는 개발 단계, 정보 요구 사항 및 사용자 조사를 통합해야 하는 유연성에 따라 다양한 방법과 그 중에서 선택하는 방법을 설명하는 기사를 작성했습니다. "Bite-Sized UX Research"라는 제목의 Steve Baty, UXmatters: http://uxmatters.com/MT/archives/000287.php.

이러한 각 기술과 일반적으로 사용되는 방식에 대해 자세히 살펴보겠습니다.

사용자 인터뷰 사용자 인터뷰는 사이트의 현재 또는 잠재 사용자와의 구조화된 대화입니다. 이는 전화로, 중립적인 장소(예: 회의실)에서 직접 수행하거나 이상적으로는 사용자가 사이트를 사용할 가능성이 있는 환경에서 수행할 수 있습니다. (이 마지막 상황은 아래에서 다루는 상황에 맞는 조사를 수행하는 데에도 유용합니다.) 인터뷰는 참가자의 선호도와 태도를 이해하는 데 도움이 되지만 실제 성과에 대한 공식적인 진술을 하는 데 사용되어서는 안 됩니다. 사람들이 사이트와 상호 작용하는 방식에 대한 구체적인 정보를 찾고 있다면 사이트를 사용하는 것을 관찰하거나(예: 상황에 맞는 조사에서) 사이트에서 작업을 수행하도록 요청하는 것이 좋습니다(사용성 테스트 중). 사이트 분석은 또한 데이터에 대한 컨텍스트를 제공하는 인터뷰 또는 문의와 함께 사용할 때 특히 강력할 수 있는 일부 성능 정보에 대한 통찰력을 제공할 수 있습니다. 기본 프로세스 사용자 인터뷰를 위해 UX 디자이너는 다음과 같은 정보를 도출하기 위한 질문 목록을 작성합니다. 사이트 또는 주제와 관련된 경험

연구 기법 선택

참여자가 경험한 회사의 브랜드 태도, 예를 들어 다루는 주제 범주에 대한 태도(연속적으로

텐트 소스), 설계 중인 프로세스(작업 기반 애플리케이션의 경우) 또는 마케팅 방법(마케팅 캠페인의 경우) 사용자를 귀하의 사이트 또는

경쟁자 회사 사이트를 방문한 후 사용자가 수행하는 일반적인 다음 단계 경험에 관련된 다른 사람들. 예를 들어

사용자는 달성하려는 더 큰 목표의 일부로 다른 사람과 협력하는 경향이 있습니까? 그 과정에서 정보를 공유하거나 다른 사람의 의견을 물을 가능성이 있습니까? 가정을 검증하는 데 도움이 되는 기타 정보

예를 들어 임시 사용자 모델을 만들 때 논의한 변수가 실제로 사용자가 사이트를 경험하는 방식에 영향을 미치는지 여부입니다. 인터뷰에서 일관성을 유지하는 데 사용할 수 있는 질문 목록과 스크립트 소개를 설정합니다. 원하는 인터뷰 구조를 미리 선택하십시오. 공식적인 보고서를 작성하려는 경우 질문 순서가 크게 다르지 않고 모든 질문이 거의 추가되지 않은 높은 수준의 구조를 원할 것입니다. 데이터의 풍부함이 일관성보다 더 중요한 경우 질문 목록으로 시작하지만 대화가 자연스러운 경로를 따르도록 허용하는 반구조화된 인터뷰를 선택하기로 결정할 수 있습니다. ). 인터뷰 시간은 다를 수 있습니다. 45분에서 60분은 종종 촬영하기에 가장 좋은 범위입니다. 참가자를 지치게 하지 않으면서 관계를 구축하고 다양한 질문을 다룰 수 있는 충분한 시간을 제공합니다. 사용자 인터뷰는 7장에서 다루는 페르소나를 작성하는 데 사용할 수 있는 풍부한 데이터 세트를 제공합니다.

6장: 사용자 조사

인터뷰 요령 인터뷰에서 얻는 정보의 질은 묻는 질문의 질과 많은 관련이 있습니다. 참가자의 개인적인 경험에 초점을 맞춥니다. 그들이 미래에 무엇을 할지 또는 다른 사람들이 무엇을 할지 추측하도록 요구하지 마십시오. 이러한 종류의 정보는 그들이 실제로 무엇을 할지 예측하는 경우가 거의 없습니다. 특정한 대답을 암시하거나 참가자를 긍정적 또는 부정적인 방향으로 이끄는 질문을 하지 마십시오. 이상적으로 질문은 단순하고 중립적이며 개방형입니다. 주요 질문의 몇 가지 예는 다음과 같습니다. PseudoCorporation.com에 대해 어떤 점이 마음에 드십니까?

이것은 사용자가 사이트 사용을 좋아한다고 가정합니다. 이 질문은 그들이 그것에 대해 무엇을 싫어하는지 묻는 경우에만 사용하십시오. PseudoCorporation.com이 귀하의 기대를 충족합니까?

이것은 간단한 예 또는 아니오로 대답할 수 있으며, 이는 디자인 작업에 도움이 되는 세부 정보를 제공하지 않습니다. PseudoCorporation.com 또는 CompetitorVille.com을 사용하시겠습니까?

그리고 만약 후자라면 왜 그들이 Pseudo보다 낫다고 생각합니까? 여기에는 몇 가지 문제가 있습니다. 하나의 진술에 두 가지 질문을 하고 참여자에게 암묵적인 의견을 강요합니다. 더 좋은 질문은 다음과 같습니다. PseudoCorporation.com을 마지막으로 방문한 일에 대해 알려주십시오. 왜 거기에 갔습니까? 당신의 방문에 대해 무엇을 기억합니까?

대규모의 보다 공식적인 인터뷰를 수행하는 경우 일부 객관식 질문을 포함할 수 있습니다. 그러나 대부분의 경우 매우 풍부한 정보를 제공하지는 않습니다. 참가자가 구두로 요청하면 따르기 어려울 수 있으며 사용자가 자세히 설명할 수 없습니다. 일반적으로 스크리너 또는 설문 조사를 위해 해당 유형의 질문을 저장하십시오. 핵심 팀의 구성원이 아닌 조직 내의 누군가와 함께 테스트 실행을 수행합니다. 이렇게 하면 명확하지 않을 수 있는 질문을 발견하고 타이밍과 흐름을 다듬는 데 도움이 됩니다. 가능하고 참가자가 동의하는 경우 다른 사람들이 참가자의 입에서 직접 답변을 들을 수 있도록 인터뷰를 녹음합니다.

연구 기법 선택

상황적 질문 상황적 질문은 사용자 관찰과 인터뷰 기술을 결합합니다. UX 디자이너는 참여자, 이상적으로는 사이트를 사용할 가능성이 높은 환경으로 이동합니다. 예를 들어 사무실 응용 프로그램의 경우 상황별 조회에는 참가자의 책상에 앉아 있는 것이 포함됩니다. 이 방법은 사용자가 직면하고 있는 실생활 문제 그들이 사용하는 장비의 종류 그들이 작업하는 공간, 특히 그들이 사용하는 공간의 양을 포함하여 참가자가 작업하는 컨텍스트에 대한 풍부한 정보를 제공합니다.

개인 정보 보호 수준, 방해 빈도, 전화 및 종이 사용 방법(게시한 인쇄물이나 편리하게 보관하는 메모에 특히 주의하십시오). 마우스 대 키보드 사용에 대한 선호도. 이것은 크게 영향을 미칠 수 있습니다

특히 많은 데이터 입력이 필요한 도구를 디자인하는 경우 디자인 선택. 공동 작업 및 공유 측면에서 다른 사람과 작업하는 방식

리소스를 사용합니다. 예를 들어, 둘 이상의 사람이 같은 컴퓨터를 사용하는 경우 로그인 및 보안 기능을 설계하는 방법에 영향을 미칩니다. 온라인과 오프라인 모두에서 사용 중인 다른 도구입니다. 사람들이 종이를 사용하는 방법은

특히 흥미로운 점은 일부 작업의 경우 종이와 경쟁하는 온라인 솔루션을 설계하기 어려울 수 있다는 것입니다! 문의는 관찰 시간과 인터뷰 시간을 합산한 것입니다. 몇 시간에서 며칠까지 어디에서나 지속될 수 있습니다. 참가자가 최소 2시간을 할애할 수 없다면 인터뷰만 수행하는 것을 고려해야 합니다. 관찰하는 동안 참가자가 귀하의 존재에 적응하고 어느 정도 자연스럽게 행동하는 데 시간이 걸리며 이는 15분 후에 발생하지 않습니다. 기본 프로세스 각 참가자와 함께 사용할 수 있는 10~15분 분량의 소개를 준비합니다. 여기에는 문의 목적, 함께 무엇을 할 것인지에 대한 높은 수준의 설명(관찰 및 인터뷰), 98

6장: 사용자 조사

정보가 사용됩니다. 이것은 또한 동의서에 서명을 받고 참여자들이 공유하는 내용이 기밀로 유지될 것임을 확신시키기에 좋은 시기이기도 합니다. 참가자의 일반적인 프로세스, 특히 사이트 디자인과 관련된 질문에 대한 높은 수준의 질문으로 시작하십시오. 말을 멈추고 관찰을 시작할 준비가 되면 참가자에게 알립니다. 관찰은 능동에서 수동에 이르기까지 다양합니다. 능동적 관찰의 일반적인 접근 방식은 참가자가 스승의 역할을 맡고 당신이 견습생의 역할을 맡는 것입니다. 마스터는 마치 자신의 과정을 가르치는 것처럼 자신이 하는 일을 설명합니다. 능동적 관찰은 종종 참가자의 행동에 대한 이유에 대한 더 많은 배경 정보를 제공하지만 참가자가 작동하는 방식에 영향을 미칠 수 있습니다. 수동적 관찰에서는 참가자가 자신이 거기에 없는 것처럼 행동하도록 격려합니다. 당신의 목표는 가능한 한 자연스러운 행동을 관찰하는 것입니다. 예를 들어, 참가자가 당신과 이야기하고 있다면 전화를 받거나 그녀가 해결하려는 문제에 대해 다른 사람에게 질문을 할 가능성이 적을 수 있지만 수동적으로 관찰하고 있다면 이것을 볼 가능성이 더 큽니다. 일어나다. 그런 다음 인터뷰 부분에서 후속 조치를 취하여 관찰한 일부 행동의 이유에 대해 질문할 수 있습니다. 두 접근 방식 모두 잘 작동할 수 있습니다. 일반적으로 참가자들과 시간이 많지 않다면(예를 들어 각각 2~4시간만) 능동적 관찰을 사용하여 필요한 깊이 있는 정보를 얻을 수 있습니다. 하루 종일 시간이 있다면 수동적 관찰을 통해 자연스러운 행동과 토론의 균형을 잘 잡을 수 있습니다. 문의에서 정보를 얻으면 정렬할 풍부한 데이터가 많이 생깁니다! 그렇다면 결과에서 패턴이나 경향을 어떻게 식별합니까? 도움이 되는 한 가지 방법은 친화성 다이어그램이라는 기술입니다. 이 주제에 대해 사용할 수 있는 훌륭한 리소스가 많이 있지만 여기에 간단한 설명이 있습니다. 친화성 다이어그램 작성에 대한 빠른 가이드 친화성 다이어그램 작성은 다수의 개별 항목(예: 사용자가 작성한 진술 또는 연구원이 관찰한 내용)을 함께 그룹화하여 패턴과 추세를 형성하는 기술입니다. 간단한 친화도 다이어그램 세션과 관련된 단계는 다음과 같습니다. 1. 메모와 함께 문의를 수행한 팀을 모으십시오.

연구 기법 선택

2. 각 사람에게 포스트잇을 한 팩씩 나눠주고 각자의 이니셜과 같은 참가자의 진술을 추적할 수 있는 짧은 코드와 함께 각 노트에 진술을 쓰도록 요청합니다. 구체적으로(기능 설명) 또는 보다 일반적인 방식(회사 또는 주제에 대한 참가자의 태도를 나타내는 설명)으로 사이트 디자인과 관련이 있는 것으로 보이는 설명에 중점을 둡니다. 3. 모두 포스트잇을 벽에 붙입니다. 대규모 서재를 작업하는 경우 큰 빈 벽이 필요합니다. 적어도 며칠 동안 액세스할 수 있는 것을 얻으십시오. 4. 모든 메모가 작성되면 유사한 문장을 서로 옆에 그룹화하기 시작합니다. 연습의 이 부분에는 더 큰 팀이 포함될 수 있습니다. 결과 공유를 시작하는 좋은 방법입니다. 5. 그룹이 자연스럽게 형성되기 시작하면 그룹에 레이블을 지정하여 추가 구조를 제공합니다. 일부 포스트잇이 둘 이상의 그룹에 속해 있는 경우 복제본을 작성하여 각 적절한 그룹에 배치할 수 있습니다. 참고 이 방법은 상황별 조회에 적합하지만 다른 많은 상황에도 적용할 수 있습니다. 예를 들어 정렬되지 않은 주제에 대한 범주를 공동으로 생성하는 좋은 방법이므로 카드 정렬 결과를 추가 구조 수준으로 이동하는 데 도움이 될 수 있습니다.

패턴은 다양한 방식으로 나타날 수 있으므로 스스로 형성되도록 하는 것이 가장 좋습니다. 그러나 다음은 해당 범주에서 찾을 수 있는 진술을 포함하여 볼 수 있는 범주 종류의 예입니다. 정신 모델(사용자가 어떻게 행동하는지 보여주는 진술 포함

외부 경험을 내부 사고에 매핑): "나는 이 온라인 도구를 서류 가방으로 사용합니다. 참조가 많지만 휴대하고 싶지 않은 것들을 위한 것입니다." 아이디어 및 기능 요청: “실행을 취소할 수 있으면 좋겠습니다. 나는 계속

실수로 전체 폴더를 이동했는데 취소하는 데 시간이 오래 걸립니다.” 좌절감: “헬프 데스크에 이것에 대해 물어보고 싶지만 절반은 그렇지 않습니다.

문제가 무엇인지 알고 있습니다.”

100

6장: 사용자 조사

해결 방법: “여기서 작업하는 데 시간이 너무 오래 걸려서

목록을 작성하고 하루 종일 작업합니다. 그런 다음 하루가 끝나면 결과를 입력합니다.” 가치 진술: “여기서 이 도구는 많은 시간을 절약해 줍니다.

ing 변경 사항을 제거하지 마십시오!”

딥 다이빙 상황적 탐구에 대한 전형적인 리소스는 Hugh Beyer와 Karen Holtzblatt(Morgan Kaufmann, 1997)의 Contextual Design입니다. 이 책에는 친화도 다이어그램과 같은 기술을 통해 결과를 해석하는 방법에 대한 자세한 정보도 포함되어 있습니다. Mental Models: Aligning Design Strategy with User Behavior, by Indi Young(Rosenfeld Media, 2008)을 참조하십시오. 이는 콘텐츠 소스의 정보 아키텍처에서 작업할 때 특히 유용합니다.

설문조사 설문조사에는 많은 청중에게 배포되는 잘 정의된 질문 모음이 포함됩니다. 응답 중 패턴을 표시할 수 있는 도구로 쉽게 수집할 수 있는 선택형 질문(예: 객관식 질문)으로 구성되는 경우가 가장 많습니다. 설문조사는 실제보다 더 정량적인 방식으로 결과를 설명하고자 할 때 유용한 도구입니다(예: "조사 대상자 중 재택 근무자의 82%가 어떤 형태로든 고속 인터넷 연결을 사용하고 있음"). 인터뷰에 사용되는 개방형 질문의 종류에 대해 알아보십시오. 그러나 사용자 습관 및 태도에 대한 질적 정보도 수집할 수 있습니다. 사용자 경험 분야에서 설문조사는 사용자 만족도(기존 사이트 또는 애플리케이션 사용)를 측정하거나 세분화 또는 페르소나와 같은 사용자 모델을 구축하거나 검증하는 데 자주 사용됩니다.

연구 기법 선택

101

기본 프로세스 사용자 인터뷰와 마찬가지로 사용자가 추측해야 하는 질문을 하고 싶지 않습니다. "기능 X가 있으면 사용하시겠습니까?"라고 묻지 마십시오. 인터뷰와 달리 설문 조사에서는 객관식 또는 예/아니요, 참/거짓 질문이 나중에 분석하기 가장 좋고 가장 쉽습니다. 또한 참가자가 더 빨리 답변할 수 있습니다. 다음과 같이 인구통계학적 데이터에 대한 사실적 요청인 질문이 있는 경우 설문조사를 사용하십시오. 아래 나열된 기기 중 개인적으로 소유하고 있는 기기는 무엇입니까? 해당하는 것을 모두 선택하십시오. 컴퓨터 휴대폰 Xbox, Playstation 또는 Wii와 같은 게임 시스템

또는 일련의 명확한 선택 범위가 있는 태도 질문의 경우: 다음 문장을 읽고 각 문장에 동의하거나 동의하지 않는 정도를 선택하십시오. Pseudo Corporation의 고객 서비스는 제 요구에 부응합니다. 매우 동의함 동의함 동의도 반대하지도 않음 동의하지 않음 매우 동의하지 않음

특히 두 번째 예시와 같은 질문은 사용성 테스트 작업을 보완하기 위해 자주 사용됩니다. 이 유형을 후속 질문으로 사용하여 참가자가 작업을 완료할 때 좌절했는지 확인할 수 있습니다. 참가자들은 부정적인 의견을 큰 소리로 말하는 것을 항상 좋아하지는 않지만 순위 시스템에 직면했을 때 기꺼이 의견을 표현하는 경우가 많습니다. 이는 또 다른 요점을 제시합니다. 설문조사는 사용자 인터뷰 또는 상황에 맞는 질문과 같이 수행할 수 있는 다른 형태의 연구에 대한 훌륭한 보완책입니다. 두 가지 연구 방법을 결합하면 한 가지 방법이 단독으로 제공할 수 있는 것보다 사용자에 대한 더 풍부한 그림을 제공합니다.

102

6장: 사용자 조사

검색 결과에 대한 높은 확신을 원하고 그에 대한 예산이 있는 경우 사용 편의성과 관련하여 사용자 만족도를 측정할 수 있는 공식적인 도구가 있습니다. 이러한 도구에는 광범위한 청중을 이끌거나 혼동하지 않도록 테스트된 질문이 포함됩니다. ACSI(American Customer Satisfaction Index): www.theacsi.org/ WAMMI(Website Analysis and MeasureMent Inventory): www.wammi.com SUMI(Software Usability Measurement Inventory): http://sumi.ucc .즉

설문조사를 계획할 때 다음 사항을 고려하십시오. 누구를 대상으로 합니까?

이를 결정하려면 임시 모델을 사용하십시오. 여기에서 나머지 질문에 답하는 방법에 차이가 있을 것입니다. 어떤 방법으로 설문조사를 배포하면 최상의 결과를 얻을 수 있습니까?

기본 사용자 그룹이 특정 위치에 모이는 경향이 있는 경우 그곳에 가서 사람들이 종이에 설문 조사를 작성할 테이블을 설정하면 더 많은 결과를 얻을 수 있습니다. 사용자 그룹이 활동적인 인터넷 사용자인 경우 온라인 설문 조사를 하는 것이 많은 참가자에게 최선의 선택이 될 수 있습니다. 또는 현재 고객 목록을 사용하여 전화 설문조사를 통해 사용자 그룹을 가장 잘 찾을 수 있다고 결정할 수 있습니다. 참가자들이 작성하는 데 기꺼이 얼마나 많은 시간을 할애할 것입니까?

설문 조사? 어떤 종류의 보상을 제공하거나 작성을 통해 다른 이점을 얻는 경우 일반적으로 완료하는 데 30분 정도 걸리는 더 긴 설문지를 만들 수 있습니다. 그렇지 않은 경우 사람들이 완료할 수 있도록 짧게 유지해야 합니다. 5~10분 정도로 생각하세요. 어느 쪽이든 참가자들에게 예상 소요 시간을 제공하고 진행 상황을 업데이트하도록 합니다(예: "2/4"와 같은 페이지 번호를 사용하거나 완료율을 표시).

연구 기법 선택

103

데이터 분석을 언제 시작해야 하는지 어떻게 알 수 있습니까?

특정 수의 참가자에 도달할 때까지 또는 특정 마감일에 도달할 때까지 중 우선순위가 높은 시점까지 설문조사를 실행하도록 선택할 수 있습니다. 데이터를 수집하고 분석하기 위해 어떤 도구를 사용할 것인가?

설문조사를 온라인으로 진행하는 경우 데이터 수집에 사용하는 도구에 결과를 보고 분석하는 옵션이 있을 수 있습니다. 그렇지 않은 경우 선택한 도구에 데이터를 입력하는 방법이 필요합니다. 종이 기반 설문조사의 경우 이것은 많은 데이터 입력을 의미하므로 해당 시간을 계획하고 있는지 확인하십시오.

포커스 그룹 포커스 그룹은 대상 청중 내에서 다양한 사람들을 모으고 그들과의 토론을 촉진하는 것을 포함합니다. 공통 목표는 과거 경험, 관련 요구 사항, 감정, 태도 및 개선 아이디어와 같이 조직 또는 브랜드와 관련된 주제에 대한 의견을 이끌어내는 것입니다. 포커스 그룹은 다음과 같은 여러 목적을 위한 좋은 기술입니다. 다양한 사용자 스토리 듣기. 열린 토론은

우리 모두의 이야기꾼을 밖으로. 포커스 그룹이 잘 진행되면 개인은 서로의 이야기와 아이디어를 구축하고 보다 구조화된 일대일 인터뷰에서는 기억하지 못할 상황을 기억합니다. 그룹 형식과 에너지는 사람들이 이러한 이야기를 기억하고 공유하는 데 필요한 시간을 제공할 수 있습니다. 경험의 관련 차이점 이해. 대부분의 사람들은 자연

ural 정보 공유자이며 좋아하는 도구를 관심 그룹의 다른 사람들과 비교하려고 합니다. 종종 경쟁 사이트나 서비스에 대해 알아보거나 해결 방법, 리소스 및 지원에 대한 팁을 들을 수 있습니다. 아이디어 생성. 그룹 자체를

디자이너는 종종 그룹에서 직접 또는 그들의 작업 프로세스나 좌절에 대해 듣고 새로운 기능이나 디자인에 대한 훌륭한 아이디어를 얻습니다. 이해관계자 아이디어와 마찬가지로 이를 핵심 요구 사항으로 역추적하여(4장 참조) 문제가 해결되고 있는지 확인할 수 있습니다. 협업 프로세스의 여러 지점을 이해합니다. 당신이

여러 관련 역할 및 공동 작업을 포함하는 프로세스를 설계할 때 그룹은 이해의 격차를 메울 수 있는 좋은 방법이 될 수 있습니다.

104

6장: 사용자 조사

사람들이 어떻게 상호 작용하는지. 예를 들어 인트라넷과 같은 콘텐츠 소스로 작업하는 경우 콘텐츠 생성, 콘텐츠 편집 및 콘텐츠 소비를 혼합하여 프로세스를 개선할 수 있는 지점을 식별하는 것이 도움이 될 수 있습니다. UX 연구에서 포커스 그룹의 사용에 대해 많은 논쟁이 있습니다. 사용성을 테스트하기에는 좋은 기술이 아니며(사용자는 대부분 그룹이 아닌 개별적으로 작업하기 때문에) 때로는 그룹 설정이 참가자의 진술에 과도한 영향을 미칠 수 있습니다. 그러나 잘 계획되고 촉진된다면 포커스 그룹은 디자인할 때 가치 있는 많은 통찰력을 이끌어낼 수 있습니다. 13장에서는 개념 테스트의 맥락에서 이에 대해 자세히 설명합니다. 기본 프로세스 포커스 그룹을 위한 질문을 작성할 때 사용자 인터뷰 질문을 작성할 때 사용하는 것과 동일한 요령을 고려하십시오(앞에서 다뤘음). “PseudoCorporation.com을 마지막으로 방문한 것에 대해 말해주세요. 왜 거기에 갔어?” 아이디어 생성에 초점을 맞춘 질문은 참가자가 귀하, 서로 및 주제에 대해 편안하게 느낄 때 그룹의 중간 부분에 저장하십시오. 각 주제에 시간 블록을 할당하고 유지하십시오. 토론이 실제로 진행되고 시간이 지나기 쉽습니다! 시간이 걱정된다면 가장 중요한 질문을 주제 목록의 중간에 두십시오. 사람들이 활동에 관심을 갖게 된 후 활동이 끝날 무렵 발생할 수 있는 잠재적인 시간 위기가 발생하기 전에 말입니다. 포커스 그룹을 위한 물류의 대부분은 사용성 테스트와 동일합니다. (13장은 심사, 모집 및 일정에 대한 제안을 제공합니다.) 포커스 그룹과의 주요 차이점은 참가자들이 서로 쉽게 상호 작용할 수 있는 테이블이 있는 더 큰 방이 필요하다는 것입니다. 1~2시간 그룹 세션당 6~8명을 촬영합니다. 모든 사람이 서로의 이름을 부를 수 있도록 각 사람의 좌석에 이름표나 장소 카드를 제공합니다. 토론 자체의 형식에는 소개가 포함되어야 하며, 종종 다음과 같은 핵심 사항에 도달합니다.

(예를 들어, 위의 몇 가지 사항).

연구 기법 선택

105

참석자가 참여하도록 선택된 이유(예: "여러분은 모두

Pseudo Corporation 사이트의 현재 사용자이며 귀하의 경험에 대해 알아보기 위해 귀하를 모았습니다."). 이 정보가 디자인과

기밀의 입장. 중재자로서 귀하는 그들의 의견에 대해 듣고

경험담. 그들이 정직하게 공유할 수 있다고 느끼기를 원하므로 개인에게 직설적이면서도 그룹의 다른 사람들을 존중하도록 요청하십시오. 다루어야 할 주제가 많기 때문에 언젠가는 디스-

모든 주제를 다룰 수 있는지 확인하기 위해 하나의 주제에 대해 토론하십시오. 그런 다음 종종 일종의 쇄빙선 질문을 포함하여 그룹 구성원을 위한 소개 라운드로 들어갈 수 있습니다. 귀하의 목표는 모든 사람이 짧은 이야기를 하더라도 첫 번째 질문에 대해 이야기하도록 하는 것입니다. 한 사람부터 시작하여 테이블 주위에서 작업하거나 사람들이 자연스럽게 대답하게 한 다음 아직 대답하지 않은 사람들의 이름을 부를 수 있습니다. 종종 처음 몇 가지 질문을 하기 위해 테이블을 돌아다니다가 그룹이 준비되었다고 느끼면 몸짓으로 모든 사람에게 질문을 공개할 수 있습니다.

스노클링: 바디 랭귀지 바디 랭귀지를 잘 이해하면 포커스 그룹을 조정하거나 직접 수행하는 사용자 조사를 할 때 놀라운 도구가 될 수 있습니다. 누군가가 좌절하거나, 흥분하거나, 화를 내거나, 위협을 느끼는 때를 이해하는 데 도움이 될 수 있으므로 언제 누군가를 더 편안하게 하려고 노력해야 하는지 또는 특정 댓글에 대해 조사해야 하는지 식별할 수 있습니다. 이 주제에 관한 다음 책은 완전히 읽는 데 주말 이상이 걸릴 수 있지만 쉽게 넘기도록 설계되었습니다. The Definitive Book of Body Language, by Allan Pease and Barbara Pease (Bantam, 2006).

아직 대답하지 않은 사람을 부를 때, 그들이 이해하지 못했거나 마지막 말을 듣지 않은 경우에 대비하여 질문을 반복하십시오.

106

6장: 사용자 조사

토론에서 몇 가지 진술. 또한 의견의 차이가 두 사람 사이의 의견 차이처럼 보이지 않게 하십시오. “밥, 아직 소식이 없어요. Chris가 방금 한 말에 대해 어떻게 생각하세요?” 오히려 (밥을 바라보며) “어때, 밥? Pseudo Corporation의 고객 서비스에 대해 어떤 경험을 하셨습니까?” 중재자는 토론의 흐름을 제어하고 가상 마이크를 전달합니다. 눈 맞춤, 말하는 양, 팔 움직임, 몸의 방향을 사용하여 통제력을 유지합니다. 대부분의 사람들은 당신의 바디 랭귀지를 매우 잘 알고 있을 것이며, 누군가가 대화를 주도하고 있다면 이러한 단서가 유용한 신호가 될 수 있습니다. 지나치게 목소리가 큰 참여자가 그러한 힌트를 얻지 못한 경우 “좋아요. 다른 사람에게 그 생각을 공개하고 싶습니다. Theresa와 같은 문제를 겪은 사람이 있습니까?” 새로운 더 큰 주제로 넘어갈 때 이전 토론이 끝났고 새로운 토론이 시작되었음을 구두로 알려 사람들이 다음 주제에 대해 마음을 비울 수 있도록 합니다. 마지막으로, 활동이 거의 끝나갈 때 시계를 바라보고 몸의 방향을 바꾸는 것만으로도 대화를 마무리해야 한다는 신호가 될 수 있습니다. 다른 활동과 마찬가지로 그룹에게 시간을 내어 주셔서 감사합니다. 팀과 결과를 공유하는 것은 일반적으로 두 가지 형식 중 하나를 취합니다. 즉, 다루는 주요 주제에 따라 결과를 공유하거나 상황에 맞는 조사를 위해 관련 범주로 그룹화합니다. 친화도 다이어그램은 일러스트레이션에 대한 다양한 트렌드와 태도를 프로젝트 팀에 한데 모으는 또 다른 효과적인 방법이 될 수 있습니다.

카드 분류 카드 분류 활동에서 참여자(개별적으로 또는 소그룹으로 작업)에게 카드에 인쇄된 항목을 제공하고 이해하기 쉬운 그룹으로 분류하도록 요청합니다. 사전에 제공되는 범주로 그룹화하거나(폐쇄형 정렬이라고 함) 자체 그룹을 만들고 각 그룹에 자체 제목을 지정합니다(개방형 정렬이라고 함). 카드 정렬 라운드가 끝나면 사람들이 항목을 정렬하는 방식에서 일반적인 패턴과 혼란 또는 불일치의 공통 영역이 나타나는 것을 보기 시작해야 합니다.

연구 기법 선택

107

이렇게 하는 일반적인 이유는 웹 사이트에 대한 사이트 맵을 만들거나 기사, 문서, 비디오 또는 사진과 같은 항목을 포함하는 콘텐츠, 범주 및 하위 범주의 계층 구조를 만들기 위해서입니다. 따라서 콘텐츠 소스에서 작업하는 경우 카드 정렬이 탁월한 기술이 됩니다. 참고 콘텐츠 소스에 대한 자세한 내용은 2장을 참조하십시오.

일반적인 유형의 콘텐츠 소스인 회사 인트라넷에서 작업 중이라고 가정해 보겠습니다. 많은 인트라넷은 인적 자원, 운영, 법무, 마케팅 등으로 탐색하여 정보를 소유한 부서별로 정보를 분류하는 경향이 있습니다. 장기 근속 직원의 경우 이는 명백한 문제가 아닐 수 있습니다. 왜냐하면 그들은 아마도 각 부서의 책임 라인을 배우고 정보를 찾을 수 있는 위치에 대한 이해를 구축했기 때문입니다. 그러나 신입 직원이나 일반적으로 참조하지 않는 정보가 필요한 직원의 경우 둘 이상의 부서에 속할 수 있는(또는 어느 곳에도 속하지 않는 것 같은) 정보를 찾기가 어려울 수 있습니다. 예를 들어, 신입 사원과의 계약 체결에 관한 정책을 어디에서 찾을 수 있습니까? 법률에 해당할 수도 있고 인적 자원에 해당할 수도 있습니다. 카드 정렬을 사용하면 부서에 관계없이 잠재 사용자가 정보를 분류하는 일반적인 패턴을 찾을 수 있습니다. 기본 프로세스 카드 정렬에 포함할 항목을 수집합니다. 40에서 60은 일반적으로 좋은 범위입니다. 잠재적으로 많은 수의 카드 그룹을 생성할 수 있을 만큼 충분히 필요하지만 옵션으로 참가자를 압도할 만큼(또는 결과를 분석해야 할 때 압도당할 정도로) 많지 않아야 합니다. 이해하기 쉽고 불필요한 전문 용어가 없는 항목을 선택하십시오. 사용자 그룹이 알 것 같은 일부 주제 용어를 포함할 수 있지만 너무 많은 "내부자" 용어를 포함하지 마십시오. 회사 고유의 용어나 약어(예: 매출 증대를 위한 "SUCCEED 캠페인")를 너무 많이 포함하면 공통 정보 계층 구조를 구축하는 대신 회사의 마케팅 및 커뮤니케이션의 효과를 테스트하게 됩니다. 인트라넷 예의 경우 휴가 정책, 401(k) 계획 정보, 신규 고용 계약, 공급업체 계약, 비공개 계약,

108

6장: 사용자 조사

신입 사원 오리엔테이션, 건강 보험 정보 및 컴퓨터 보안 정책. 이 목록은 여러 방법으로 분류할 수 있는 명확하게 표현된 항목의 혼합을 나타냅니다. 신입 사원 오리엔테이션과 휴가 정책을 인적 자원으로 그룹화하는 참가자가 있을 수 있고, 신입 사원 오리엔테이션과 신규 고용 계약을 그룹화하고 이름을 "직원 온보딩"으로 지정하는 다른 참가자가 있을 수 있습니다. 항목 목록이 있으면 쉽게 그룹화 및 그룹 해제할 수 있는 카드에 항목을 넣습니다. 라벨을 인쇄하여 색인 카드에 붙이거나 구멍이 뚫린 카드 용지에 직접 인쇄하여 개별 카드로 분리할 수 있습니다. 누군가에게 카드를 그룹으로 분류하고 그룹 이름을 지정하도록 요청하여 테스트 실행을 수행합니다. 예를 들어 스택에 포스트잇을 놓고 그 위에 펜으로 이름을 씁니다. 이상적으로 테스트 참가자는 항목 및 활동에 익숙하지 않은 사람입니다. 이렇게 하면 활동에 소요되는 시간을 대략적으로 파악할 수 있습니다. 테스트 실행이 한 시간 이상 걸리면 일부 카드를 잘라야 할 수도 있습니다! 완성된 덱이 있으면 실제 참가자를 초대하고 다음과 같은 기본 지침을 제공할 수 있습니다. 1. 이 카드를 원하는 그룹으로 배열합니다. 2. 한 그룹에 적어도 두 장의 카드가 있도록 하십시오. 카드가 그룹에 속하지 않는 것 같으면 옆에 놓을 수 있습니다. 3. 정렬하는 동안 언제든지 그룹 이름을 지정할 수 있습니다. 활동이 끝날 때까지 가능한 한 많은 그룹의 이름을 지정하십시오. 일부 추세는 세션을 관찰하는 것만으로도 분명해집니다. 다른 사람들은 꺼내기 위해 조금 더 분석을 할 수 있습니다. 카드 정렬 결과를 입력하고 분석하기 위한 몇 가지 도구가 있습니다. 그들 중 다수는 카드 정렬을 원격으로 실행할 수 있는 도구와 함께 제공됩니다(자세한 내용은 아래의 "카드 정렬의 변형" 섹션 참조). 특히 OptimalSort(www.optimalsort.com/pages/default.html) 및 WebSort(http://websort.net)는 원격 정렬 기능과 유용한 분석 도구를 모두 제공합니다. 또는 보다 수동적인 방식으로 직접 정렬하려면 Donna Spencer의 탁월한 스프레드시트를 살펴보십시오.

연구 기법 선택

109

지침은 www.rosenfeldmedia.com/books/cardsorting/blog/card_sort_analysis_spreadsheet에서 확인할 수 있습니다. 카드 정렬의 변형 지금까지 토론은 참가자가 자신이 만든 범주의 이름을 지정하도록 요청받은 개인과 직접 수행하는 카드 정렬에 중점을 두었습니다. 이것은 개방형 정렬입니다. 즉, 주요 범주가 참가자에게 제공되지 않고 이름을 지정할 수 있습니다. 이는 새로운 탐색 구조를 결정하거나 기존 탐색 구조를 크게 변경할 때 좋은 접근 방식입니다. 다른 상황에서는 다음과 같은 일반적인 카드 정렬 변형을 고려할 수 있습니다. 폐쇄형 정렬. 닫힌 정렬에서는 상위 수준 범주를 제공합니다.

참가자가 추가합니다. 가능한 작은 범주 세트가 있고 어떤 항목이 어떤 범주에 가장 자주 속하는지 이해하는 데 집중할 수 있기 때문에 결과를 분석하기가 상대적으로 쉽습니다. 기존 정보 아키텍처에 많은 양의 콘텐츠를 추가하거나 기존 사이트 맵의 유효성을 검사하는 경우 폐쇄형 정렬은 분류 결정에 도움이 되는 신속하고 실행 가능한 정보를 제공할 수 있습니다. 그룹 정렬. 개별 항목을 그룹으로 정렬하는 대신 다음을 수행할 수 있습니다.

참가자들이 항목을 분류하기 위해 함께 일하는 포커스 그룹 활동의 일부로 카드 분류를 하십시오. 결과가 반드시 한 개인이 항목을 그룹화하는 방법을 반영하지는 않지만 사람들이 함께 활동을 통해 작업하고 각 배치의 근거에 대해 토론하는 것을 들으면 사람들이 항목과 해당 구성에 대해 어떻게 생각하는지에 대한 많은 통찰력을 얻을 수 있습니다. 원격 정렬. 실물 카드로 분류하는 것은 재미있는 활동이 될 수 있습니다.

그룹 정렬의 경우. 그러나 개인과 온라인으로 정렬을 수행할 수 있는 훌륭한 도구가 많이 있습니다. 또한 물리적으로 만나기 어려울 수 있는 더 많은 수의 참가자 또는 특정 참가자에게 다가갈 수 있습니다. 위에서 언급한 OptimalSort 및 WebSort는 이러한 유형의 온라인 정렬을 쉽게 만드는 두 가지 도구입니다.

사용성 테스트 사용성 테스트는 잠재적인 사용성 문제를 발견하고 이를 해결하기 위한 아이디어를 수집하기 위해 참가자에게 사이트 또는 응용 프로그램(또는 프로토타입)에 대한 특정 테스트를 수행하도록 요청하는 것입니다.

110

6장: 사용자 조사

현재 사이트를 개선할 수 있는 방법에 대한 정보를 수집하려는 경우 정의 단계에서 사용성 테스트를 수행할 수 있습니다. 또는 유사한 사이트(예: 경쟁 사이트)에서 수행하여 보다 사용자 친화적인 솔루션의 잠재적 기회를 이해할 수 있습니다. 대부분의 경우 사용성 테스트는 디자인 단계의 일부로, 이상적으로는 반복 라운드(디자인이 생성, 테스트, 수정 및 다시 테스트되는 단계)에서 수행됩니다. 사용성 테스트에 대해서는 13장 "사용자와 디자인 테스트"에서 다시 자세히 논의할 것입니다. 이 장에는 이 장의 앞부분에서 논의한 활동을 수행하는 데 도움이 되는 모집 및 계획에 대한 정보가 포함되어 있습니다.

조사 후 이러한 사용자 조사 활동 중 하나 이상을 완료한 후에는 사용자 그룹에 대해 원래 설정한 가정을 다시 검토해야 합니다. 이러한 가정을 잠시 접어두고 더 많은 정보를 얻었으므로 이제 어떤 사용자 그룹을 만들 것인지 자문해 보십시오. 이전 가정 중 일부가 유효하지 않은 경우 주요 그룹이 포함되지 않았기 때문에 사용자 조사에 있을 수 있는 공백을 고려하십시오. 연구 활동 초기에 이 격차가 확인되면 전체 그림을 얻을 수 있도록 진행 중인 연구에 다른 참가자 세트를 조정하고 추가할 시간이 있을 수 있습니다. 새로운 지식으로 사용자 정의를 수정하여 초점을 맞춰야 하는 그룹을 보다 정확하게 반영할 수 있습니다. 이렇게 하면 페르소나(7장에서 설명)와 같은 더 자세한 도구를 만드는 데 도움이 되고 5장에서 시작한 목록에 대한 사용자 요구 사항을 만드는 데 도움이 됩니다. 요구 사항. 사용자와 유사한 프로세스를 따르게 됩니다. 아이디어나 요청을 캡처해도 작업이 중단되지 않습니다. 근본 요구 사항과 목표를 파헤쳐 이해했는지 확인하십시오. 이는 궁극적으로 모든 관련 사용자 그룹의 요구 사항을 가장 잘 충족하는 솔루션을 설계하는 데 도움이 됩니다. 다음 장에서는 사용자 연구를 수행하면서 얻은 통찰력을 사용하여 디자인 및 개발 전반에 걸쳐 사용자 그룹에 집중할 수 있는 도구인 페르소나를 만드는 방법을 배웁니다.

연구 후

111

페르소나는 사용자 입장에서 팀 또는 클라이언트를 배치하는 가장 좋은 방법을 찾습니다. 페르소나는 종종 사용자 경험 실무자들 사이에서 논쟁의 대상이 됩니다. 의견은 얼마나 많은 콘텐츠가 필요한지부터 얼마나 많은 연구가 필요한지, 프로젝트에 가치를 제공하는지 여부에 이르기까지 다양합니다. 어떤 사람들은 자신이 그 과정에 전혀 속하지 않는지 의문을 갖습니다. 위치에 관계없이 페르소나는 프로젝트 팀과 클라이언트가 사용자와 공감하는 데 도움이 될 수 있습니다. 페르소나는 청중이 누구이며 그들의 기대와 행동이 무엇인지에 대한 통찰력을 제공함으로써 프로젝트의 많은 부분(비즈니스 요구 사항, 시각적 디자인 또는 품질 보증)에 대한 직감 검사를 제공할 수 있습니다. 러스 웅거

페르소나는 무엇입니까? 페르소나는 일반적인 대상 사용자를 설명하는 문서입니다. 프로젝트 팀, 이해 관계자 및 고객에게 유용할 수 있습니다. 적절한 연구와 설명을 통해 페르소나는 누가 사이트나 애플리케이션을 사용하고 있는지, 잠재적으로 어떻게 사용하는지에 대한 매우 명확한 그림을 그릴 수 있습니다. 사용자 경험 디자이너는 종종 페르소나 만들기를 공감의 훌륭한 연습으로 봅니다. 잘 만들어진 페르소나는 프로젝트의 측면을 어떻게 설계해야 하는지에 대한 질문이나 우려가 발생할 때마다 접점으로 자주 사용됩니다. 당신은 당신의 페르소나를 꺼내서 물어볼 수 있습니다. 어떻게 수행할까요? 또는 에서 무엇을 찾을 것입니까? 이 프로세스는 실제 사용자와 함께 기능 및 디자인을 테스트하는 것만큼 정확하지 않을 수 있지만 보다 광범위한 테스트를 수행할 수 있을 때까지 프로젝트를 진행하는 데 도움이 될 수 있습니다. Josh Seiden(www.joshuaseiden.com)은 두 가지 유형의 페르소나가 있다고 지적합니다. 구매 동기를 모델링하는 마케팅 대상 페르소나 사용 행동을 모델링하는 인터랙티브 페르소나

이 장에서는 대화형 페르소나에 중점을 둡니다.

페르소나를 만드는 이유는 무엇입니까? 사용자 경험 디자인 프로세스에서 페르소나는 대표 사용자에 집중하는 데 도움이 됩니다. "실제" 사용자의 "실제" 행동에 대한 통찰력을 제공함으로써 페르소나는 디자인 및 개발 결정을 내릴 때 발생하는 충돌을 해결하는 데 도움이 될 수 있으므로 귀하와 귀하의 팀은 계속 발전할 수 있습니다. 페르소나는 얼마나 현실적이어야 합니까? 대답은 매우 다양합니다. 단일 페르소나 문서는 한 팀에 충분할 수 있는 반면, 다른 팀은 사용자 페르소나가 "생활"하는 방식을 깊이 이해할 수 있도록 완전한 "생활 공간"을 만들 수 있습니다. 온라인 행동에 대한 통찰력을 제공하기 위해 상호 작용할 수 있는 개별 온라인 존재를 극단으로 만들 수도 있습니다. 그러나 페르소나를 확장하도록 선택하는 것은 귀하에게 달려 있습니다. 페르소나는 사용자를 지속적으로 상기시켜 줄 수 있습니다. 유용한 기술은 팀 구성원이 작업 공간에 페르소나를 유지하는 것입니다. 이렇게 그들은

페르소나를 만드는 이유는 무엇입니까?

113

사용자가 누구인지 지속적으로 상기시킵니다. 일리노이주 웨스트시카고에서 온 34세의 공인 손 치료사 "니콜"과 한동안 큐브를 공유하면 그녀에게 잘 맞는 경험을 제공해야 한다는 강박감을 느끼기 시작합니다. 도움이 된다면 잠자는 동안 인쇄된 사본을 가지고 다니고 삼투의 요정이 페이지에서 베개를 통해 잠든 잠재의식에 공감을 전달하도록 하세요. 페르소나의 목적은 귀하, 귀하의 팀 및/또는 귀하의 고객이 의사 결정의 갈림길에 도달했을 때 발생할 수 있는 혼란을 제거하는 데 도움을 주는 것입니다.

페르소나에 대한 정보 찾기 효과적인 페르소나는 제품 또는 웹 사이트의 특정 사용자 수를 정확하게 묘사해야 합니다. 그 목표를 달성하기 위해 페르소나는 연구를 통해 뒷받침되어야 합니다. 6장에서는 페르소나의 확고한 기반을 제공하기 위해 잠재 사용자를 조사하고 모델링하는 기술을 제시합니다. 그러나 답이 될 한 가지 방법을 찾지 마십시오. 가능한 한 많은 데이터를 찾아 관찰 및 인터뷰 데이터와 혼합하는 것이 가장 좋습니다. 여기에는 온라인 설문 조사 활용 및 소셜 네트워크에서의 행동 분석도 포함될 수 있습니다. 페르소나 생성의 공통 주제는 실제 데이터를 가져오지만 페르소나를 페이지의 실제 사람으로 만드는 것입니다. 한 회사가 이를 달성하는 방법을 알아보려면 사이드바 "사례 연구: Messagefirst Personas"를 참조하십시오.

페르소나 만들기 청중을 식별하고 페르소나를 지원하기 위한 데이터를 축적했다면 다음 단계는 종이에 연필을 놓고 그들에게 생명을 불어넣기 시작하는 것입니다. 생성해야 하는 페르소나의 수는 다양합니다. 일반적으로 최소값은 3개이지만 7개 이상도 드물지 않습니다. 특정 개수를 목표로 하기보다는 가지고 있는 대상 세그먼트의 수를 고려하고 이를 공정하게 표현하는 가장 좋은 방법이라고 생각합니다.

114

7장: 페르소나

사례 연구: Messagefirst 페르소나 효과적인 데이터 기반 페르소나를 생성하기 위해 Messagefirst(www.messagefirst.com)는 다음과 같은 세 가지 이상의 서로 다른 데이터 입력 소스를 사용합니다. 우리는 그들이 생각하는 페르소나가 누구인지, 그리고 그들의 행동이 무엇이라고 생각하는지 알아보기 위해 그들을 인터뷰합니다. 이것은 항상 포함됩니다. 고객 옹호자. 우리는 일반적으로 판매/마케팅 및 고객 서비스를 의미하는 고객과 직접 대화하는 회사의 사람들을 인터뷰합니다. 이들 각각에는 편향이 있으며, 발견한 내용을 문서화할 때 염두에 두어야 합니다. 예를 들어, 고객 서비스에 가장 일반적으로 연락하는 사람은 시간이 너무 많은 사람(종종 은퇴했거나 실직한 사람)이거나 제품이나 서비스에 대해 너무 화가 나서 실제로 연락하는 데 시간이 걸리는 사람입니다. 고객. 우리는 제품이나 서비스를 사용할 예정이거나 현재 사용하고 있는 실제 사람들과 직접 대화합니다. 이것은 가능할 때마다 포함됩니다. 고객 데이터 소스. 사용 가능한 모든 Weblog 트래픽, 설문 조사 및 이메일을 검토합니다. 우리가 아는 사람. 페르소나의 초기 프로필에 맞는 사람을 선택합니다. 이것은 우리가 기반을 유지하는 데 도움이 되고 페르소나가 믿을만하고 사실적임을 보장하며 추가 질문이 있는 경우 연락할 실제 사람을 제공합니다. 이는 유효성 검사에 매우 중요하며 항상 포함됩니다. 우리가 사용하는 각 데이터 입력 소스에는 특정 편향이 있기 때문에 여러 소스를 사용하여 데이터를 정규화합니다. 데이터 기반 페르소나에서 중요한 것은 얼마나 많은 페르소나를 갖게 될지 예상하는 것이 아니라 데이터를 통해 얼마나 많은 페르소나가 있어야 하는지를 밝히는 것입니다. 데이터를 분석할 때 행동과 활동의 차이를 찾습니다. 이러한 간격은 개인의 페르소나를 드러냅니다. 토드 자키 워펠(Todd Zaki Warfel) 메시지퍼스트 회장

이 장의 예시 페르소나는 일리노이주 웨스트시카고에 사는 34세의 공인 손 치료사 Nicolle입니다. 그녀는 직장을 오가는 데 하루에 2~3시간을 보내는 비운전자 통근자입니다. 가상의 클라이언트는 Apple의 가상이 아닌 iPhone용 Bluetooth 헤드셋 제조업체인 ACMEblue라는 회사입니다.

페르소나 만들기

115

이 짧은 단락은 Nicolle에 대해 많은 것을 알려 주지만 그림 7.1에서 볼 수 있듯이 실제 페르소나는 Nicolle에 대한 훨씬 더 철저한 이야기를 담고 있습니다. 콘텐츠는 Nicolle에 의해 "by"가 아니라 Nicolle에 대해 작성되었습니다. 제3자의 관점에서 페르소나를 작성하는 것이 가장 좋습니다. 특히 막 시작하는 경우에는 제3자의 고유한 목소리로 작성하는 것과 씨름하지 마세요. 경험을 넓히다 보면 자신에게 가장 잘 맞고 최고의 가치를 제공하는 스타일을 자연스럽게 탐색하고 찾아야 합니다.

그림 7.1 가상 클라이언트 ACMEblue의 페르소나

페르소나에는 어떤 정보가 들어가나요? 청중이 관련성이 있고 믿을만하다고 생각하는 정보의 종류가 바로 그 종류입니다. 수집한 연구 데이터를 기반으로 클라이언트, 브랜드 및 프로젝트에 중요한 것이 무엇인지 확인할 수 있어야 합니다. 생성한 대부분의 페르소나는 선택 사항으로 간주될 수 있는 임의의 양의 데이터, 통계 및 기타 관련 정보와 혼합된 필수 콘텐츠의 공통 세트를 공유합니다.

116

7장: 페르소나

최소 콘텐츠 요구 사항 페르소나를 만들 때 사람들을 끌어들이고 페이지에서 읽고 있는 사람과 관련되도록 충분한 정보를 제공해야 합니다. 청중이 페르소나가 어떻게 행동하고 생각하는지 이해하는 데 도움이 되도록 사진, 이름, 나이, 위치, 직업, 전기 등 6가지 주요 정보를 포함해야 합니다. 다음 섹션에서는 각 항목에 대한 세부 정보를 채우는 방법을 자세히 살펴봅니다. 사진 사진은 페르소나에 얼굴을 입히는 첫 번째(그리고 실제적인) 단계입니다. 페르소나 사진을 선택할 때 사진이 너무 자세를 취하거나 세련되게 보이지 않는지 확인하세요. 포즈를 취한 것처럼 보이는 사진은 보다 자연스러운 설정에 있는 사진과 동일한 효과를 나타내지 않습니다. 페르소나는 그림 7.2의 오른쪽 사진과 같이 보다 자연스러운 환경에서 촬영한 사진에 더 효과적인 것으로 보입니다. 피사체는 통근 중에 겨울 코트를 입고 밖에 서 있습니다. 사진이 페르소나의 라이프스타일에 맞는지 확인하세요! 제기

자연스러운 그림 7.2 자연스러운 사진이 더 효과적입니다.

다양한 온라인 사진 리소스가 있습니다. 더 나은 옵션으로는 iStockphoto(www.istockphoto.com), Getty Images(www.gettyimages.com) 및 Stock.XCHNG(www.sxc.hu)가 있습니다.

페르소나 만들기

117

조심하지 않으면 올바른 사진을 찾는 것이 시간을 낭비할 수 있습니다. 다른 모든 방법이 실패하면(또는 시간과 예산이 있는 경우) 직접 가져가십시오! 이름 간단히 말해서 얼굴에 이름을 붙여야 합니다. 당신이 사용하는 사진은 연구 데이터와 성격 특성의 혼합을 인간화할 것이며, 이름은 토론 중에 모든 사람이 당신의 페르소나를 언급하는 방법이 될 것입니다. Nicolle은 "30대 중반의 금발 전문직 엄마"보다 더 좋게 들릴 뿐만 아니라 특정 인물을 기억하고 연관시키기가 훨씬 더 쉽습니다. 프로젝트에서 다른 페르소나에 사용하는 이름이 너무 비슷하게 들리지 않도록 하세요. 예를 들어 Nicolle과 Noelle은 쉽게 혼동될 수 있으므로 서로 다른 이름을 찾습니다. 동료나 고객의 이름을 사용하고 싶을 수도 있지만 그렇게 하지 마십시오. 프로젝트에 관련된 사람들의 이름과 같거나 같은 이름을 사용하면 그들이 당신의 페르소나에서 자신을 식별하려고 하기 쉽습니다. 다른 이름을 선택하면 불편한 상황이나 상처받는 감정을 피할 수 있습니다. 이름을 선택하는 데 어려움이 있는 경우 다음과 같은 일부 온라인 리소스가 도움이 될 수 있습니다. 아기 이름 지정 웹 사이트! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com 사회 보장국의 인기 아기 이름: www.ssa.gov/

OACT/babynames 임의 이름 생성기: www.kleimo.com/random/name.cfm

이름에 대한 마지막 사항: 페르소나가 믿을 수 있는 이름인지 확인하세요. Nicolle은 중서부 어머니에게 적합하지만 Nicola 또는 Natalia는 이탈리아 어머니에게 훨씬 더 나은 이름일 수 있습니다. 또한 Bob the Builder와 같이 좀 더 재미있거나 생동감 있어 보이는 이름은 그렇지 않습니다. 그들은 당신의 페르소나를 어리석게 보이게 하는 경향이 있고 그들의 가치를 떨어뜨릴 수 있습니다. 연령 연구에서 소비자의 연령대를 식별해야 하지만 페르소나에 대한 특정 연령을 제공하면 작성하는 전기에 진정성을 추가하는 데 도움이 됩니다. 21세 대학생과 34세 전문직 엄마의 행동은 확연히 다릅니다!

118

7장: 페르소나

위치 처음에는 위치가 중요한 정보가 아닌 것처럼 보일 수 있습니다. 그러나 문화적, 행동적 변화가 위치에 따라 발생할 수 있음을 기억하는 것이 중요합니다. 예를 들어 이탈리아에서는 지역마다 다른 방언을 사용합니다. 미국에서 시카고에 사는 사람은 조지아주 사바나에 사는 사람과 생활비가 다를 가능성이 높습니다. 직업 당신의 페르소나가 어떤 일을 하는지 아는 것은 일상 생활의 패턴과 관련하여 그들과 동일시하는 데 도움이 됩니다. 치료에 종사하는 페르소나는 매일 많은 사람들을 만나는 반면, 도개교 운영자는 다른 사람들과 많이 교류하지 않을 수 있습니다. 전기 전기는 페르소나를 현실로 만드는 매력적인 이야기입니다. 여기에서 연구 데이터에서 파생된 세부 정보를 제공하고 약간의 "실제 인물"을 주입합니다. 즉, 데이터는 페르소나에 매우 중요하지만 고르지 못한 문장으로 해당 정보를 단순히 인용하고 싶지는 않습니다. 대신 데이터, 일화, 관찰 내용을 청중이 공감할 수 있는 이야기로 엮고 싶습니다. 조금 이상하게 들릴 수도 있지만 전기는 믿을 수 있어야 하며 실제 사람의 측면을 페르소나에 가져오는 것은 확실히 부정 행위가 아닙니다. 예를 들어 Nicolle은 통계 데이터와 유사한 활동, 신념 및 욕구를 공유하는 사람의 실제 행동을 모두 기반으로 합니다. 프로젝트에 따라 약력을 상당히 깊이 파고들어야 할 수도 있습니다. 때로는 세부 정보가 많을수록 좋습니다. 페르소나를 종이 한 장에 짜내야 하는 것처럼 느끼지 마세요. 당신의 페르소나를 삶에 충실하고 당신이 작업하고 있는 프로젝트에 가능한 한 의미 있게 만들기 위해 가장 잘 작동하는 것을 선택하세요.

선택적 콘텐츠 페르소나로 작업할 때 페르소나를 더 적합하게 만들기 위해 프로젝트마다 다른 정보 세트가 필요하다는 것을 알게 될 것입니다. 최소 콘텐츠 요구 사항은 가장 흔하지 않은 것으로 간주될 수도 있습니다.

페르소나 만들기

119

당신이 만들 대부분의 페르소나의 분모. 대부분의 경우 이러한 선택적 콘텐츠 요소 중 일부를 페르소나의 핵심과 혼합합니다. 페르소나에 가치를 더할 수 있는 선택적 콘텐츠에는 교육 수준이 포함됩니다. 사람이 얼마나 교육을 받았는지 아는 것은 약간의 정보를 제공할 수 있습니다.

그들의 습관 중 일부에 대한 더 많은 통찰력. 고등학교 졸업장을 가진 사람은 석사 학위를 가진 사람보다 구매 습관과 브랜드 인식이 상당히 다를 수 있으며, 이 정보는 페르소나가 인식되는 방식에 영향을 미칠 수 있습니다. 급여 또는 급여 범위. 돈이 말을 하고 많은 경우에

사람이 가진 소득은 생활 수준과 가처분 소득에 상당한 영향을 미칩니다. 이 정보는 특정 수준의 풍요를 목표로 삼을 때 중요한 통찰력을 제공할 수 있습니다. 개인 견적. 당신의 페르소나가 주장할 모토는 무엇입니까

그들 자신으로? 때때로 이것은 페르소나의 사고 방식의 핵심에 대한 빠른 개요를 제공할 수 있습니다. 온라인 활동. 까다로울 수 있습니다. 사람들이 소비하는 방법은 많다

(Video) 나만 모르고 있는 UI 디자인을 위한 10가지 원칙

그들의 온라인 시간. 어떤 사람들은 청구서를 지불하고, 어떤 사람들은 블로그와 소셜 네트워킹 활동에 몰두하며, 어떤 사람들은 단순히 컴퓨터를 작업을 수행해야 할 때 켜지는 기기로 사용합니다. 너무 많은 프로젝트에 일부 온라인 구성 요소가 있다는 점을 감안할 때 이 요소는 약간의 판단 요청입니다. 그림을 그리는 데 도움이 되는 연구에 의존해야 합니다. 오프라인 활동. 당신의 페르소나는 취미가 있습니까? 추가 사항이 있습니까

온라인 상태가 아닐 때 페르소나의 삶이 어떤지에 대한 정보가 있습니까? 이 요소는 온라인 활동만큼 까다로울 수 있으며 페르소나에 영향을 미치는 데 있어 매우 중요할 수 있습니다. 클라이언트, 브랜드 또는 프로젝트에 대한 핵심 진입점 또는 트리거 포인트. 종종 중요하다

페르소나가 클라이언트, 브랜드 또는 프로젝트와 상호 작용하는 방식을 이해합니다. 페르소나는 입소문, 온라인 리뷰, 광고판, 텔레비전 또는 라디오 또는 온라인 팝업 광고를 통해 그것에 대해 듣습니까? 페르소나는 클라이언트, 브랜드 또는 프로젝트를 통해 해결할 수 있는 문제를 해결하려고 합니까? 통계 데이터를 사용하여 이 점을 이해하고 페르소나에 작성하면 사용자 참여에 대한 접근 방식을 기반으로 할 수 있습니다.

120

7장: 페르소나

기술적 편안함 수준. 당신의 페르소나는 PC나 Mac을 사용합니까? 그녀를 않습니다

컴퓨터를 소유하고 계십니까? 그녀는 인스턴트 메시징, Flickr를 사용하거나 블로그를 작성합니까? 그녀는 그 활동에 매우 편안합니까, 아니면 혼란스러워합니까? 초보자를 위한 아주 간단한 해결책이 그녀에게 도움이 될까요? 그녀는 MP3 플레이어 또는 기타 휴대용 장치를 가지고 있습니까? 그녀는 TV를 시청하기 위해 DVR이나 AppleTV 또는 주문형 프로그래밍을 사용합니까? 목록은 계속 될 수 있습니다. 그리고. 클라이언트, 브랜드 또는 프로젝트에 따라 이러한 개념과 기타 다양한 개념을 식별하는 것이 중요할 수 있습니다. 사회적 편안함 수준. 소셜 미디어 및 소셜 네트워크의 성장을 감안할 때

당신의 페르소나가 특정 공간에 어떻게 관여하는지를 매우 구체적으로 식별하는 것이 중요할 수 있습니다. 그녀는 트위터 계정이 있습니까? 그렇다면 그녀의 팔로워는 몇 명입니까? 그녀는 얼마나 활동적입니까? 그녀는 리더입니까? 그녀는 MySpace, Facebook, LinkedIn 또는 기타 애그리게이터나 온라인 커뮤니티를 사용합니까? 모바일 편안함 수준. 모바일 기기 사용이 많아지면서

퍼소나가 모바일 공간에서 자신을 찾는 방법을 포함하는 것을 고려하는 것이 중요합니다. 클라이언트, 브랜드 또는 프로젝트를 사용하는 동기. 경우에 따라 원할 수 있습니다.

페르소나가 클라이언트, 브랜드 또는 프로젝트를 사용하려는 이유를 포함합니다. 계속해서 헤드폰용 전선이 코트에 엉켜 머리에서 잡아당긴다면 새 헤드폰을 고려해야 할 충분한 이유가 될 수 있습니다. 연구 데이터를 기반으로 한 실제 시나리오는 페르소나에 포함할 주요 동기를 찾는 데 도움이 될 수 있습니다. 사용자 목표. 페르소나가 무엇을 원하는지 식별할 수도 있습니다.

클라이언트, 브랜드 또는 프로젝트를 사용하여 달성합니다. 이는 페르소나를 사용하는 동인에 대한 통찰력을 제공하는 데 도움이 될 수 있습니다. 시작하기 위한 데이터 포인트일 뿐입니다. 페르소나를 구성하고 무한히 다양한 방식으로 제시할 수 있습니다. 페르소나의 세계에 대해 자세히 알아보고 싶다면 시작하기 좋은 곳은 The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web, by Steve Mulder with Ziv Yaar(New Riders, 2006)입니다. ).

페르소나 만들기

121

고급 페르소나 페르소나 생성의 기본 사항을 이해하고 나면 문서를 확장할 수 있는 방법이 무궁무진합니다. 간단한 페르소나는 종종 대부분의 요구 사항을 충족할 수 있습니다. 특히 프로젝트 팀이 사용자에 대해 공감하는 이해를 얻으려고 할 때 그렇습니다. 고객에게 페르소나를 제시할 때 상황이 더 흥미로워지는 경향이 있습니다. 이러한 경우 기본 페르소나에 대해 모은 정보보다 훨씬 더 많은 정보를 제공해야 하는 경우가 종종 있습니다. 그림 7.3에서 7.7은 페르소나를 확장할 수 있는 몇 가지 방법을 보여줍니다. 이 예제에서 자유롭게 차용하고 리믹스하고 매시업하여 프로젝트에 더 나은 것을 만드십시오!

상표명

브랜드 소비자를 만나다

페르소나 및 시나리오(민족지학 연구 기반) 페르소나는 대상 소비자에 대한 데이터(이 경우 민족지학, 기존 세분화 및 고객 데이터베이스 데이터)를 기반으로 하는 복합 문자입니다.

시나리오는 이러한 페르소나가 왜 브랜드 웹 사이트를 방문하고 그곳에서 무엇을 하는지 설명하는 가상적이지만 현실적인 내러티브입니다.

Joan, 32세 소비자 통찰력은 사용자의 동기, 목표 및 욕구를 이해하는 데 도움이 됩니다. 이러한 통찰력을 웹 사이트 디자인에 적용하기 위해 실제 상황에 기반한 사용자 페르소나 및 시나리오를 개발합니다. 이 설계 접근 방식은 고객, 동기, 원하는 결과 및 행동에 대한 이해를 기반으로 포괄적인 경험을 만드는 데 도움이 됩니다. 시나리오는 사이트를 적절하게 구성하기 전에 해결해야 하는 세 가지 기본 질문에 구체적으로 대답합니다.

즐거움을 찾는 마니아들 "이거 진짜 좋아" "젊은 세련미"

시작

탐색 시작

경험 쌓기

“초보자 지망생”

"$)*&7&-&7&- 편안함

"적극적 대응자"

느낌 5)&365

다시 탐색

“확립된 탐험가”

합리화 및 단순화

“그루브에서 성장”

실용적인 작업 완료 "작동해야 합니다"

앨리스, 26세

레이첼, 42세

에리카, 47세

그레타, 59세

그림 7.3 페르소나 개요 마스터 시트(가로 방향). 높은 수준의 조직 전략의 맥락에서 여러 페르소나와 이들이 나타내는 세그먼트에 대한 집계 보기를 제공합니다. 윌 에반스의 의례.

122

7장: 페르소나

상표명

페르소나 및 시나리오(민족지학 연구 기반) Alice는 음식의 세계를 탐험하고자 하는 초보 요리사입니다.

목표

특히 아이들에게 친숙한 음식, 친구와 함께 온라인 및 잡지에서 새로운 요리법을 찾아보십시오. 그녀의 탐구는

많은 생각이나 노력 없이 그녀의 가족을 먹여 살리다

그래도 현실보다 환상. 그녀는 여전히 겁먹고 그러지 않는다.

기본 재료를 사용하여 빠르고 쉬운 레시피 찾기

너무 많은 새로운 요리법을 시도하십시오. 그녀의 엄마는 그녀에게 요리 기술을 너무 많이 전수하지 않았고 그녀의 친구들은 경험이 많지 않습니다.

(자주) 두 가지 유형의 식사를 만듭니다: 성인용, 어린이용

요리도 한다. Alice는 시카고에 사는 한 딸의 바쁜 엄마입니다. 그녀와 그녀의 남편은 모두 집 밖에서 일합니다. 그녀는 작은 보험 회사의 사무실을 관리합니다.

앨리스, 26세 "초보자 지망생" x세대 결혼

딸 1명, 지치고 열망하는 5명

소득

교육

그녀는 바쁘고 실용적이며 요리에 많은 시간을 할애하지 않습니다. Alice는 단지 빠르고 쉽게 끝내기를 원할 뿐입니다. 2년 전 Sophie와 함께 운동을 시작한 이후로 자신과 남편을 위해 다른 식사를 준비해야 하는 경우가 많긴 하지만, 마라톤 몸매로 돌아가려고 노력하고 있습니다. 그녀는 자신이 편안하다고 느끼는 작은 성공 레시피로 작업하며, 그녀가 준비하는 많은 식사는 포장 및 준비된 음식을 기반으로 합니다.

시나리오 Alice는 아침 식사 중에 Sophie와 함께 Cartoon Network를 시청하고 있습니다. 브랜드 광고가 여기에서 브랜드 이름을 보여줍니다. Alice는 브랜드를 사용하고 Sophie가 그 요리에 갈 것이라고 생각합니다. 그녀는 직장에서 사이트를 확인하기로 결정합니다. Alice는 회의 전 무료 30분 동안 사이트를 방문합니다. 홈페이지는 명확하고 체계적입니다. 그녀는 메인 사이트 섹션을 보고 오늘의 레시피와 같은 흥미로운 항목에 대한 링크를 확인합니다.

인터넷 사용

건강의식

비용 민감성

그녀는 오늘의 레시피를 클릭합니다. 그녀는 그것과 함께 제공되는 팁을 좋아합니다. 그들은 그녀가 이 레시피를 다룰 수 있다고 느끼게 합니다. 그녀는 길을 잃기 쉬운 다른 사이트와 달리 명확한 탐색에 만족합니다. 그녀는 식료품 저장실에 있는 재료를 기반으로 레시피를 찾는 기능과 제품 사용 방법에 대한 팁과 같이 요리책에서 보는 것 이상의 유용한 기능을 좋아합니다. Alice는 레시피 뉴스레터를 받을 수 있다는 사실을 알고 "가입"을 클릭합니다. 등록은 매우 쉽습니다! 그녀는 몇 가지 기본 정보를 입력하고 "Food Your Kids Will Love" 뉴스레터를 선택합니다.

그녀는 자신의 손길을 더 추가하고 그녀가 가장 좋아하는 저크 치킨과 같이 식당에서 즐기는 요리를 다시 만들고 싶어합니다. 그녀는 또한 더 건강에 좋다는 것을 알고 있기 때문에 식사에 더 많은 신선한 야채를 추가하고 싶어합니다. 그녀는 자신이 철저한 계획가이며 빠듯한 예산으로 집안을 운영할 수 있다는 사실에 자부심을 가지고 있습니다. 그녀의 냉장고와 식료품 저장실은 항상 비축되어 있습니다. 그녀는 할인과 쿠폰을 활용하여 쇼핑을 계획합니다.

아이들에게 친숙한 요리법 및 음식 활동 찾기 그녀가 좋아하는 즉석 식품을 "꾸미는" 방법 찾기 프로젝트 및 이니셔티브 개선된 탐색 및 정보 아키텍처 개선된 가입

일주일 후 점심 시간에 Alice는 첫 번째 브랜드 e-뉴스레터인 "Pizza, easy as 1, 2, 3"을 발견합니다. 완벽합니다. 그녀의 아이들은 피자를 좋아하고 그녀는 보통 아이들을 위해 냉동 피자를 구입합니다. 그녀가 스스로 피자를 만들 수 있는지 알아보도록 영감을 주는 "초보자를 위한 피자" 링크가 있습니다. 링크는 그녀를 "피자 마법사"라는 페퍼로니 피자 레시피로 안내합니다. 그녀는 조리법을 스캔하고 그것이 매우 간단하다는 것을 알았습니다. 단 25분, 4가지 재료. 그녀는 자신이 가지고 있는 것이 무엇인지 확인하기 위해 부엌을 확인합니다. 그녀는 페퍼로니나 피자 소스가 없지만 "피자 마법사"는 잘 갖춰져 있는 부엌에 있는 소시지와 토마토 소스로 대체할 것을 제안합니다. 그리고 완벽합니다! 쿠폰 링크가 있습니다. Neena는 레시피의 장보기 목록을 인쇄하고 필요한 몇 가지 항목을 추가한 다음 매장으로 향합니다. 상점에서 돌아온 Alice는 시작합니다. 그녀는 반죽을 펴고 재료를 추가하는 방법에 대한 단계별 지침을 봅니다. 각 단계 옆에는 이미지가 있습니다. 이해하고 따라하기 쉽습니다. 그녀는 토핑을 먼저 요리해야 할지 고민하지만 피자 FAQ에서 그에 대한 답을 찾을 수 있습니다.

맥락화된 주변 정보 더 표적화된 뉴스레터 레시피 마법사 더 나은 쿠폰 통합 식사 계획 "일단 완료" 태도는 상대적으로 적은 수의 신선한 과일과 야채가 첨가된 즉석 식품에 크게 의존 실제로 요리하는 것보다 레시피를 탐색하는 데 더 많은 시간을 보냅니다.

그림 7.4 대상 청중 페르소나(가로 방향). 페르소나에 대한 이 상세한 보기는 더 넓은 범위의 데이터를 통합하고 사용자의 목표, 요구 및 행동에 대한 보다 포괄적인 관점을 제공합니다. 모두 더 큰 생태계 내에서 설정됩니다. 윌 에반스의 의례.

그림 7.5 대상 개요 및 대상 청중 페르소나(세로 방향). 왼쪽의 대상 개요는 높은 수준의 요약 정보를 제공하고 세 명의 페르소나가 상호 작용하고 관련된 브랜드를 보여줍니다. 오른쪽의 자세한 설명은 그녀의 행동 및 동기에 대한 정보와 함께 단일 페르소나의 개요 및 전기를 제공합니다.

고급 페르소나

123

폴과 헬렌 “무엇이든 넣을 수 있을 것 같아요. 얼마나 적합할지 모르겠습니다.”

5 4

Helen의 어머니는 몇 주 전에 돌아가셨고 그들은 이제 막 집을 비우기 시작했습니다. 그들은 집을 팔 계획이지만 먼저 청소해야 할 것이 꽤 있습니다. 집은 또한 마스터 욕실에서 약간의 개조 작업이 필요합니다.

삼

- of de 지하실은 Helen의 어머니가 지난 몇 년간 수집한 물건들로 가득 차 있습니다. 그녀는 아무것도 버리지 않았습니다. 그녀는 지난 20년 간의 신문과 타임지를 가지고 있습니다. Helen이 지키고 싶은 몇 가지가 있습니다. 대부분의 의류 - “콜과 가구는 Goodwill에 기부됩니다. 불행하게도, 그녀의 어머니의 대부분의 렉서블”은 물과 곰팡이로 망가졌습니다. 그녀는 또한 페인트 통을 가지고 있지만 Paul과 Helen은 페인트에 납이 포함되어 있는지 여부를 모릅니다.

2 1

디

~에 대한

아인

Ex led pe gerie nc e C on Pric ve e Senior tunc pe sp Re e Mpu ed ult type Timtion C on eline t Main ss ajo er r L Siz ife es D E ecven lu tte t Year Re rding Waste Buars dsine Price 및 O Rec am nlin ycli ne ac g count의 요율

폴과 헬렌이 이런 일을 겪은 것은 이번이 처음입니다. 그들은 어디서부터 시작해야 할지조차 모릅니다. 그들은 이것이 가능한 한 쉽기를 원합니다. 그들은 쓰레기 수거통이 필요하다는 것을 알지만 얼마나 담을 수 있을지 확신하지 못합니다. 그리고 그들은 누군가가 달리 말하지 않는 한 거의 모든 것이 쓰레기통에 들어갈 수 있다고 가정합니다. 그들의 유일한 다른 관심사는 쓰레기통이보기 흉한 경향이 있다는 것입니다. 배달이나 수거할 때 앞마당을 공사장처럼 만들거나 마당을 망치지 않는 업체를 찾겠다는 것이다.

나이: 24-65세

라이프사이클 1월

7월

12월

월

1.0 라이프 이벤트

주요 특징 Ŕ Ŕ

가족 소유지 취득 또는 소규모 리모델링 작업(예: 욕실)과 같은 단일 이벤트. 쓰레기 수거통을 구입한 경험이 거의 없습니다.

목표 Ŕ Ŕ Ŕ Ŕ Ŕ

빨리 쓰레기 수거통을 구하세요. 그들이 보관하거나 기부하지 않는 모든 물건을 제거하십시오. 이 과정에서 재산이 파괴되지 않도록 하십시오. 보기 흉한 쓰레기 수거통을 피하십시오. 쓰레기 수거통이 가득 차면 빨리 치우십시오.

불만 및 불만 사항 Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

질문 Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Ŕ ŕ

필요할 때 이용 가능 가격 공급업체가 찾은 방식으로 숙소를 떠남 필요한 용기 크기 이용 가능 연락 후 설정 및 픽업 속도 예약 및 지불을 위한 온라인 계정 액세스 장비의 품질 및 청결 친숙한 브랜드

Ŕ ŕ ŕ ŕ

초기 스티커 충격 프로세스에 익숙하지 않음 무엇을 모르는지 모름 벤더 간의 사과 대 사과 비교

들어갈 수 없는 것이 있습니까? 얼마나 빨리 배달하고 픽업할 수 있습니까? 그들은 원래 상태로 재산을 떠날 것인가? 어떻게 작동합니까? 허가가 필요합니까? 비용은 얼마입니까? 필요한 경우 얼마나 쉽게 누군가를 잡을 수 있습니까?

그림 7.6 대상 청중 그룹 페르소나. 이 페르소나는 연구 데이터에서 추출한 연령대 대상을 나타냅니다. 포함된 정보는 광범위하며 특정 개인이 아닌 청중 그룹에 대해 설명합니다. 이 접근 방식은 사업 홍보를 할 때나 클라이언트의 예산이 페르소나에 대한 자세한 탐색을 허용할 때 유용할 수 있습니다. 토드 자키 워펠의 의례.

모든 거래의 질

아만다 스톤

"고객을 위해 여러 프로그램을 관리해야 합니다."

삼

AMANDA는 몇몇 다른 동료들과 인센티브 프로그램 책임을 공유합니다. 클라이언트를 위해 액세스를 공유하고 여러 프로그램을 관리합니다. 올바른 프로그램에서 올바른 사람들에게 급여를 지불하고 있는지 확인하는 것이 특히 어려울 수 있습니다. 그녀는 다른 프로그램 사이를 전환할 수 있어야 하고 항상 자신이 어디에 있는지 알아야 합니다.

라이프사이클

주요 특징 Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

여러 프로그램 관리 중대형 기업 보통 규모(한 번에 50-2000+ 주문) 단일 역할을 공유하는 여러 사람 70/30 빠른 지불 및 관리자 확인 주간에서 격월 사용량 연중 보고에 매우 관심이 있음 프로그램 Heavy Excel은 사용자 정의 내부 시스템을 사용하여 인터페이스합니다.

목표 Ŕ Ŕ Ŕ Ŕ

현재 시스템과의 통합. 빠르고 쉽게 직원에게 지불하는 능력. 비용(주로 시간). 가이드 도움말.

기타 응용 프로그램 Ŕ Excel Ŕ PowerPoint 모든 프로그램에서 보고서를 실행하려면 어떻게 해야 합니까? Ŕ Internet Explorer 이카운트를 호출하지 않고 로그인 정보를 알 수 있는 방법이 있나요? 서로 다른 애플리케이션 사이를 너무 많이 오갈 필요가 없도록 어떤 식으로든 ClientZone과 통합할 수 있습니까? 내가 제대로하고 있습니까?

Ac FT N c ew ou P n Car t Zod Renequest E Ad asy s m Pain y C he c R Cu ep ks o rring tBal Pe ance Cu ople s t om Soft Sy 줄기 엑셀

엔씨

1월

인플루언서

빠르고 쉽게 직원에게 급여를 지급합니다. Ŕ 중복 작업을 방지합니다. Ŕ 송금이 필요한지 확인하려면 현재 잔액을 확인하세요. Ŕ 거래를 매주, 격월, 월, 분기 및 연도로 추적합니다.

리에

예에

아야

그만큼

dg 및 ow Kn

나이

등

~에 대한

훈

디

그녀는 꽤 정기적으로(일주일에 며칠) Account Zone을 사용합니다. 그리고 그녀는 여러 프로그램을 관리하고 있기 때문에 일년 내내 꽤 활동적입니다.

활동 및 관심

텍

나이: 28-55세

이자형

지식

아인

Account Zone은 그녀가 새 카드를 발급하고 프로그램 참가자가 신속하게 대금을 받을 수 있도록 도와줍니다. 그녀가 놓치고 있는 한 가지는 상황이 어떻게 진행되고 있는지 확인하기 위해 실행 중인 모든 프로그램뿐만 아니라 각 개별 프로그램을 볼 수 있는 능력입니다. 그녀의 고객은 프로그램이 어떻게 수행되고 있는지 확인하기를 좋아합니다. 바로 지금 그녀는 Excel에서 그것을 추적합니다. 그녀는 결국 고객에게 Excel 파일을 보내거나 때로는 파일을 내보내고 멋진 차트가 포함된 PowerPoint를 보냅니다. Account Zone에 개별 프로그램 및 여러 프로그램에 대한 보고서를 실행할 수 있는 방법이 있다면 정말 멋질 것입니다.

7월

Ŕ ŕ ŕ ŕ ŕ ŕ

아르 자형

월

좌절감과 고충

질문 -

12월

한 번에 여러 프로그램을 볼 수 없습니다. 한 번에 여러 프로그램에서 보고서를 실행할 수 없습니다. eception 파일 "stinks"의 오류를 수정합니다. 정확한 문제가 무엇인지, 해결 방법을 아는 것은 명확하지 않습니다. 여러 응용 프로그램을 사용하는 여러 단계는 효율적이지 않으며 그녀가 있는 곳에서 "길을 잃기" 쉽습니다. 여러 확인 화면. 기억해야 할 또 다른 사용자 이름과 비밀번호입니다. 로그인 정보가 포함된 이메일을 찾습니다.

그림 7.7 대상 고객 개인 페르소나. 이 페르소나는 데이터 기반 모델입니다. 일상적인 이야기는 내러티브이지만 나머지는 디자인 체크리스트 역할을 하는 글머리 기호로 제공됩니다. 다이어그램은 작은 공간에서 상당한 양의 정보를 전달하는 데 사용됩니다. 토드 자키 워펠의 의례.

124

7장: 페르소나

보시다시피 다양한 방법으로 데이터를 결합하여 페르소나를 제시하고 다양한 상황에 맞게 조정할 수 있습니다. 기본 페르소나로 시작하여 필요에 맞게 확장하십시오.

페르소나에 대한 최종 생각 사용자 경험 디자인 세계의 많은 실무자들은 페르소나가 사용자의 요구, 목표 및 태도를 잘 표현한다고 믿지 않습니다. 그들은 다양한 이유로 페르소나가 창의성, 혁신 또는 좋은 디자인을 방해할 수 있다고 믿습니다. 다른 실무자들은 페르소나가 견고한 연구 데이터를 기반으로 하고 개인화된 현실과 혼합될 때 매우 긍정적인 방식으로 디자인 프로세스에 영향을 미치는 특정 요구 사항을 충족한다고 믿습니다. 동전의 어느 쪽에 착지하느냐는 전적으로 귀하에게 달려 있습니다. 이 장은 당신의 결정에 어떤 식으로든 영향을 미치기 위한 것이 아닙니다. 이 주제에 대한 많은 기사가 온라인에서 제공되며 많은 전문가가 자신의 견해를 제시할 준비가 되어 있습니다. 이러한 모든 리소스는 페르소나가 프로젝트에 가장 적합한 방법을 파악하는 데 도움이 될 수 있으므로 찾아보십시오. User Interface Engineering(www.uie.com)의 CEO이자 창립 책임자인 Jared Spool도 다음과 같은 주제에 대한 통찰력을 제공합니다. 그 가치는 팀이 대상 고객을 방문하여 관찰하고 관찰 내용을 흡수 및 논의하며 혼돈을 줄일 때 발생합니다. 그런 다음 페르소나가 되는 패턴으로. 디자인할 때 팀의 머릿속에 있는 것은 최종 디자인에서 차이를 만들 것입니다. 페르소나 설명은 모든 사람에게 일어난 일을 상기시키기 위해 존재합니다.

Jared의 요점은 간단합니다. 대상 고객을 관찰하고, 연구 데이터로 학습한 내용을 주입하고, 이 모든 것을 세그먼트로 통합함으로써 팀을 계속 추적하고 최고의 팀을 구축하는 일종의 공감을 유발하는 페르소나를 생성할 수 있어야 합니다. 가능한 응용 프로그램, 웹 사이트 또는 제품. 그러나 궁극적으로 당신의 페르소나는 산타클로스처럼 될 것입니다. 사람들이 믿는 한 가치가 있을 것입니다.

페르소나에 대한 최종 생각

125

사용자 경험 디자인 및 검색 엔진 최적화 성공적인 SEO에서 사용자 경험 디자인의 근본적인 역할 검색 엔진은 대화형 경제의 초석입니다. "상호작용가"로서 우리가 하는 모든 일은 궁극적으로 Google, Yahoo, MSN, Ask 및 온라인에서 물건을 찾기 위한 인프라를 구성하는 무수한 마이너 엔진을 통해 전 세계와 연결됩니다. 정보 아키텍처는 웹 사이트가 검색 엔진에 의해 해석되는 방식의 중요한 구성 요소입니다. 이 장은 왜 UX 디자인이 검색 엔진 최적화에 중요한지, 그리고 당신이 만든 환경이 Google에서 싸울 기회를 갖기 위해 무엇을 고려해야 하는지에 대한 기본적인 이해를 제공하도록 설계되었습니다. 조나단 애쉬튼

SEO 소개 간단히 말해서 검색 엔진 최적화는 특정 대상 키워드 구문에 대해 공개 검색 엔진에서 최상위 위치를 획득하고 유지하려는 의도로 웹 자산을 개발하고 유지 관리하는 프로세스입니다. 검색 엔진 최적화(SEO)는 무술과 같으며 결코 완료되지 않는 학습 및 실행 과정입니다. 마스터라도 관찰된 행동이나 학습된 방법을 사용하여 더 발전할 수 있습니다. 검색하는 사람들에게 무언가를 판매하는 데 관심이 있는 검색 엔진과 웹 사이트가 있는 한 검색 엔진 최적화의 역할이 있을 것입니다. SEO는 개선과 영향을 위한 세 가지 기본 영역에 의존합니다.

영향을 줄 수 있는 사이트 인프라, 기술 및 조직 원칙 콘텐츠 및 최적화된 단어와 관련된 모든 키워드 문제

검색 엔진은 링크 또는 링크 인기도(귀하를 가리키는 링크의 양과 품질)를 볼 수 있습니다.

다른 사이트의 사이트, 사이트 내부 링크의 조직 구조 우리는 이 세 영역을 각각 분해하고 UX 디자이너의 관점에서 검토하여 앞에 놓여 있는 최적화 문제에 더 잘 대처할 수 있도록 합니다.

SEO가 중요한 이유는 무엇입니까? 오늘날에도 검색 엔진 최적화의 관련성을 설명해야 한다는 점이 흥미롭습니다. 클라이언트는 웹 사이트가 주요 검색 엔진의 자연 검색 결과에서 대상 방문자를 끌어들이는 것이 중요하다는 것을 어느 정도 이해하는 경향이 있지만, 그 이상으로 대부분의 대화식 마케터는 SEO가 미칠 수 있는 영향을 이해하기 어렵습니다. 전 세계 검색량에 대한 데이터는 다양한 출처에서 얻을 수 있지만 이해해야 할 가장 중요한 점은 출처가 무엇이든 그 수치가 엄청나고 매년 증가율이 항상 두 자릿수라는 점입니다. 대부분 분기마다 전 세계적으로 검색량이 증가합니다. 1998년 Google이 처음 출시되었을 때 하루 10,000건의 검색은 막대한 양이었고 시스템의 베타 버전에 엄청난 부담을 주었습니다.

SEO 소개

127

Hitwise(www.hitwise.com)는 Google과 그 계열사(AOL 및 YouTube 포함)가 2008년 11월에 수행된 미국 검색의 거의 72%로 전 세계적으로 가장 많은 검색 점유율을 보유하고 있다고 보고했습니다. Yahoo는 거의 18%로 거의 2위를 차지했습니다. , MSN과 Ask.com은 각각 4%와 3%를 기록했습니다. 국제적으로는 Google이 더욱 지배적입니다. 많은 시장에서 Google의 시장 점유율이 80% 이상에 이릅니다. 참고 Google 초기에 대한 자세한 배경 정보는 David A. Vise 및 Mark Malseed의 The Google Story(Delta, 2008)를 참조하십시오. comScore(www.comscore.com)에 따르면 2008년에는 전 세계적으로 7억 5천만 명이 매월 600억 회 이상의 검색을 수행했으며 미국에서만 180억 회 이상의 검색이 수행되었습니다. 달리 표현하면 인터넷 사용자의 95%가 한 달에 한 번 이상 검색 엔진을 사용하며 전 세계적으로 한 달에 평균 80회 이상 검색합니다.

이러한 놀라운 볼륨 수치를 제외하고 이것이 인터랙티브 마케터에게 실질적으로 의미하는 바는 무엇입니까? 간단히 말해, 타겟 고객이 귀하의 제품이나 서비스를 검색할 때 도달하지 못한다면 경쟁업체가 그들에게 판매할 기회를 얻고 있는 것입니다. 사이트 분석을 보고 문제를 다음과 같이 생각해 보십시오. 전략적으로 타겟팅된 트래픽이 10% 증가하면 사이트에서 얼마나 많은 수익을 창출할 수 있습니까? 100% 증가는 어떻습니까? 아니면 1000퍼센트? 귀하의 사이트가 자연 검색을 통해 의미 있는 트래픽을 생성하지 않는 경우 SEO가 필수입니다. SEO에 대한 약간의 투자는 특히 지금까지의 대화형 마케팅 노력이 스폰서 목록을 통한 구매 클릭에 초점을 맞추었다면 매우 먼 길을 갈 수 있습니다. 우리는 사이트가 월별 SEO 지출에 대해 35:1의 투자 수익을 달성하는 것을 보았습니다. 스폰서 목록의 트래픽에 대해 검색 엔진 회사에 비용을 지불하고 있지만 자연스러운 트래픽에 투자하지 않는다면 기회의 약 10%로 자신을 제한하고 있는 것입니다. 자신의 검색 행동을 생각해 보십시오. 검색 결과에서 하나 또는 두 개 이상의 유료 스폰서 목록을 마지막으로 클릭한 때는 언제입니까? SEO가 중요한 이유와 SEO가 유지되는 이유에 대한 논의는 여러 장에 걸쳐 계속될 수 있습니다. Google은 아무데도 가지 않고 올라가고 있으며 효과적인 양방향 마케팅에는 유능한 실행의 핵심 구성 요소로 검색 엔진 최적화가 포함되어야 한다고 말하는 것으로 충분합니다.

128

8장: 사용자 경험 설계 및 검색 엔진 최적화

중요한 기본 리소스 전문 지식은 균형 잡힌 교육에서 나옵니다. 단순히 자신의 전문 분야에 집중하는 전문가는 주변의 다른 모든 것에 대한 관점을 잃습니다. 그렇기 때문에 모든 대화형 활동가는 최소한 몇 분 동안 SEO에 대해 배우는 것이 중요합니다. 공식적인 가이드라인은 없지만 Google은 친절하게도 매우 중요한 리소스를 제공했습니다. 노력을 통해 더 나은 검색 엔진 성능을 얻는 데 관심이 있다면 다음 링크를 확인하십시오. 웹마스터/사이트 소유자 도움말: 검색 엔진 최적화:

www.google.com/support/webmasters/bin/ answer.py?hl=ko&answer=35291 웹마스터/사이트 소유자 도움말: 웹마스터 가이드라인: 품질 가이드라인:

www.google.com/support/webmasters/bin/ answer.py?hl=ko&answer=35769 검색 엔진 최적화 시작 가이드:

www.google.com/webmasters/docs/ search-engine-optimization-starter-guide.pdf 그것으로 충분하지 않다면 뉴스레터와 블로그에 빠져 보십시오. SEOmoz.org에서 시작하여 파헤쳐 보세요. 인생의 다른 모든 일에서와 마찬가지로 그것이 사실이 되기에는 너무 좋게 들리면 아마도 그럴 것입니다.

사이트 기술, 디자인 및 인프라 검색 엔진은 본질적으로 Web 2.0+ 세상에 확고하게 이식된 Web 1.0.5 기술입니다. 웹을 크롤링하고 최초의 웹 검색 엔진을 구축하기 위해 1993년에 World Wide Web Wanderer가 출시된 이후 검색 엔진의 기본 전제는 거의 변하지 않았습니다. 기본적으로 모든 검색 엔진에는 크롤러, 스파이더 또는 링크를 찾아 따라가는 봇이라고 하는 응용 프로그램이 있어 볼 수 있는 자산의 복사본을 데이터베이스로 다시 보냅니다. 그런 다음 데이터베이스는 검색 엔진의 독점 알고리즘에 따라 분석됩니다. 이러한 규칙을 사용하여 웹 자산을 인덱싱한 다음 해당 검색 엔진의 특정 점수 카드에서 얼마나 잘 점수를 매겼는지에 따라 순위를 매깁니다. 이 간단한 프로세스에는 UX 디자이너에게 무수히 많은 함정이 있습니다.

현장 기술, 설계 및 인프라

129

이러한 핵심 관계를 이해하면 검색 엔진의 눈으로 사이트를 볼 수 있습니다. 최적화된 웹 사이트는 검색 엔진 스파이더의 이동을 용이하게 하는 구조와 기술에 의존합니다. 마찬가지로 콘텐츠 처리에 대한 많은 결정은 검색 엔진이 결과적인 노력의 순위를 매기는 정도를 결정합니다. 결과적으로 이 중 많은 부분이 와이어프레임에서 이루어지는 결정과 콘텐츠의 스타일 지정 및 관리 방법에 대한 토론에서 미리 결정됩니다.

Flash, Ajax, JavaScript 및 기타 스크립팅된 콘텐츠 오늘날의 동적 및 대화형 웹 디자인은 검색 엔진의 요구에 전혀 부적합한 기술에 의존합니다. 검색 엔진이 볼 수 있는 것과 디자이너가 할 수 있는 것 사이에는 큰 격차가 있습니다. 검색 엔진과 사용자 모두가 최상의 경험을 얻을 수 있도록 역동적이고 디자인 집약적인 사이트에 대한 전략 계획을 배치하는 것은 UX 디자이너의 몫입니다. 검색 엔진이 이러한 종류의 콘텐츠와 상호 작용하는 방식을 근본적으로 이해하면 콘텐츠를 배포할 시기와 약점을 보완할 위치를 결정하는 데 도움이 됩니다. 프로세스 초기에 적절한 보상이 있는 경우 스크립팅된 콘텐츠에 크게 의존하는 최적화된 사이트를 구축하는 것은 전적으로 가능합니다. 일단 사이트가 구축되고 가동되면 정적 콘텐츠 또는 색인 생성 가능한 콘텐츠를 구축하는 것이 훨씬 더 어렵습니다. 따라서 유용성과 검색 엔진의 크롤러를 위해 정적 콘텐츠에 대한 강력한 주장을 하십시오. 사전에 추가 작업처럼 보일 수 있지만 투자 수익은 기하급수적입니다. Flash Flash 콘텐츠는 기술적으로 "인덱싱 가능"합니다. 이러한 자산에 내장된 텍스트와 링크를 찾기 위해 Flash 파일을 볼 수 있는 검색 엔진의 기능에 최근 몇 가지 발전이 있었습니다. 이 콘텐츠는 인덱싱되지만 전체 플래시 자산이 검색 결과에서 최상위 위치를 차지하는 것을 본 적이 있습니까? 검색 엔진이 Flash와의 완전한 호환성을 위해 스스로를 개방하는 것은 위험하기 때문에 아마도 그렇게 하지 않았을 것입니다. 검색 엔진이 SWF 객체 내에 포함된 모든 링크와 텍스트 콘텐츠를 완전히 볼 수 있다고 가정해 보겠습니다. 비윤리적(또는 "검은 모자") 옵티마이저가 표시하는 동안 개체의 텍스트 레이어에 사과를 넣는 것을 방지하는 것은 무엇입니까?

130

8장: 사용자 경험 설계 및 검색 엔진 최적화

브라우저를 통해 완전히 컴파일된 자산을 보는 인간 사용자에게 오렌지? 완전히 컴파일되지 않은 상태에서 어떻게 Flash 자산에 딥 링크를 걸 수 있습니까? 이러한 근본적인 취약점은 검색 엔진이 "이것은 말의 그림입니다."라는 관련 텍스트 없이 이미지가 말의 그림임을 알 수 있는 일정 수준의 인공 지능에 도달할 수 있을 때까지 남아 있습니다. 검색 엔진과 호환되는 Flash 웹 사이트를 설계하려면 Flash 콘텐츠를 복제하는 정적 콘텐츠 계층을 추가해야 합니다. 검색 엔진의 요구 사항은 잠시 제쳐두고 정적인 콘텐츠 계층은 사용성 요구 사항을 준수하기 위한 핵심입니다. 검색 엔진을 전화 접속 연결을 통해 웹 콘텐츠를 보거나 화면 판독기 브라우저를 사용하는 사람으로 생각하십시오. 이 사람들은 가장 낮은 공통 분모일 수 있으며 웹 개발 전략이 이 극소수의 인간 사용자를 무시할 가능성이 있습니다. 그러나이 소수의 사람들을 할인하면 사이트의 가장 중요한 두 방문자 인 GoogleBot과 Yahoo Slurp도 할인됩니다. 주요 검색 엔진이 귀하의 사이트를 색인화 할 수있게 해주는 크롤러이기 때문입니다. 텍스트 단어나 스파이더블 링크가 검색 엔진에 표시되지 않으면 의미 있는 검색 결과를 통해 콘텐츠를 찾을 수 없습니다. 정적 계층은 여러 가지 방법으로 수행할 수 있습니다. 검색 엔진 요구 사항을 준수하려면 콘텐츠의 정적 레이어가 Flash 콘텐츠를 미러링해야 합니다. 이것은 Flash에 배포된 것과 다른 것을 검색 엔진에 보여줄 기회가 아닙니다. 그렇게 하면 게임의 정신을 위반하고 어두운 면에 정면으로 서게 됩니다. Flash 콘텐츠를 정적 레이어에 포함하는 이상적인 방법은 Flash와 정적 콘텐츠가 모두 동일한 URL에 있을 수 있도록 SWFobject를 사용하는 것입니다. 이렇게 하면 검색 엔진이 정적 콘텐츠를 찾고 Flash 지원 브라우저가 정적 콘텐츠 대신 애니메이션을 표시할 수 있습니다. 가능하면 리디렉션을 사용하지 마십시오. 그러면 Flash 콘텐츠를 가리키는 링크의 인기도를 유지할 수 있습니다. Google 코드는 http://code.google.com/p/swfobject에서 이 간단한 JavaScript를 구현하기 위한 간단한 지침을 제공합니다. SEO의 회색 측면에서 실행되는 또 다른 옵션이 있습니다. 클로킹은 SEO 순수주의자들에게 더러운 단어일 수 있지만 오른쪽에서 다음 도전에 접근하면 케이크를 먹고 먹을 수도 있습니다.

현장 기술, 설계 및 인프라

131

클로킹은 사용자 에이전트 감지를 활용하여 웹 사이트를 방문할 때 검색 엔진 크롤러를 감지하고 색인을 생성할 정적 페이지로 라우팅합니다. 그러나 인간 방문자가 검색 결과에서 동일한 페이지를 보고 링크를 클릭하면 웹 사이트는 사용자 에이전트가 Flash 지원 브라우저를 사용하는 인간임을 감지하고 완전히 별도의 URL에서 그 사람에게 동적 경험을 보여줍니다. 문제의 핵심은 SWFobject 방법과 동일하게 유지됩니다. Flash 콘텐츠에서와 마찬가지로 클로킹된 콘텐츠에서도 검색 엔진에 정확히 동일한 항목을 표시해야 합니다. Ajax, JavaScript 및 기타 스크립팅된 컨텐츠 Web 2.0 컨텐츠의 강력한 드라이버인 Ajax는 웹 개발자에게 페이지 없는 컨텐츠를 구축할 수 있는 기능을 제공합니다. 그러나 검색 엔진이 Ajax와 관련하여 갖는 문제는 여러 가지이며 큰 실수를 피하기 위해서는 좋은 계획이 필요합니다. Ajax는 Asynchronous JavaScript And XML의 약자로, 검색 엔진이 이 기술을 사용하는 데 어려움이 있음을 암시합니다. 검색 엔진은 기본적으로 JavaScript를 처리할 수 없습니다. JavaScript가 개발자에게 제공하는 효율성은 검색 엔진이 동적 콘텐츠에 대해 가지고 있는 문제입니다. 검색 엔진이 Ajax와 관련하여 갖는 또 다른 문제는 기술의 비동기적 특성입니다. 검색 엔진은 초기 페이지 로드의 콘텐츠만 볼 수 있으며 초기 셸 로드 이후에 발생하는 스크립트를 통해 로드된 콘텐츠는 인덱싱을 위해 표시되지 않습니다. Google은 초기 페이지 로드 이상으로 세션을 확장할 수 없으며 스크립트를 활성화할 마우스나 외부 에이전트가 없기 때문에 사용자가 활성화한 페이지 없는 콘텐츠는 미리 로드된 셸에 텍스트 콘텐츠가 포함되지 않는 한 표시되지 않습니다. . 페이지 없는 디자인을 구성하는 데 필요한 3차원 모델링에는 텍스트와 링크가 모두 페이지 셸에 미리 로드되어야 한다는 요구 사항도 포함되는지 확인하는 것은 UX 디자이너에게 달려 있습니다. 다른 것은 당신의 멋진 디자인이 보이지 않습니다. 스크립팅된 탐색 최적화를 방해하는 가장 일반적인 문제 중 하나는 사이트 탐색의 핵심에 JavaScript를 사용하는 것입니다. 이것은 매우 일반적인 상태이며 많은 사이트 개발 및 콘텐츠 관리 도구가 작동하는 방식의 결과입니다. 스크립팅된 내비게이션이 멋져 보여서 사람들이 관심을 가지고 사용하는 경향이 있습니다. 그러나 JavaScript가 사이트 탐색을 구동하는 기술인 경우 결과는 검색 엔진이 링크 모델을 제대로 구축할 수 없다는 것입니다.

132

8장: 사용자 경험 설계 및 검색 엔진 최적화

사이트 내 관계: 단순히 사이트의 링크 구조를 볼 수 없습니다. 그리고 검색 엔진이 사이트의 링크 관계를 모델링할 수 없으면 딥 콘텐츠가 보이지 않거나 적절한 링크 인기도가 할당되지 않습니다.

콘텐츠 관리 시스템 콘텐츠 관리 시스템은 인간의 편의를 위해 구축되었지만 이러한 시스템 중 상당수는 검색 엔진이 출력을 처리하기 어렵게 만듭니다. 다음은 해결 방법을 사용하거나 보다 검색 친화적인 콘텐츠 관리 시스템을 선택하여 피해야 하는 몇 가지 일반적인 문제입니다. 동적 URL. 검색 엔진은 콘텐츠의 "페이지"를 이해하지 못합니다. 그것

해당 콘텐츠의 경로를 이해합니다. 해당 콘텐츠로 연결되는 경로 또는 URL이 변경되면 검색 엔진이 실수로 콘텐츠를 여러 번 복제하게 됩니다. 이 상태는 사이트의 성능을 크게 저하시킵니다. 콘텐츠 관리 시스템에 URL에 세션 ID를 생성하는 시스템이 있다면 정말 문제가 될 수 있습니다. 세션 ID가 아닌 성숙한 분석으로 추적하십시오. 여러 URL 경로. 전자 상거래 콘텐츠 관리의 일반적인 문제-

제품 수명 주기가 진행됨에 따라 여러 URL이 발생합니다. 다시 말하지만, 검색 엔진은 콘텐츠를 찾은 URL을 기반으로 콘텐츠 페이지만 이해할 수 있기 때문에 제품이 카테고리에 표시되고 선물 바구니의 일부이며 주간 특별 행사일 때(계속해서), 곧 검색 크롤러는 동일한 콘텐츠를 찾기 위해 다양한 링크를 따라갔습니다. 링크가 배포된 위치에 관계없이 각 콘텐츠가 하나의 URL에만 존재하고 여러 경로가 실제로 하나의 URL에 의존하도록 할 수 있는 모든 작업을 수행하십시오. 성숙한 분석 시스템을 사용하여 채널을 구문 분석합니다. 의도하지 않은 복제. 한 조각이라는 사실을 깨달았을 때

콘텐츠는 단일 URL 경로를 통해서만 액세스할 수 있어야 하므로 콘텐츠 관리 시스템에서 의도하지 않게 콘텐츠가 복제되는 다른 조건을 쉽게 볼 수 있습니다. 아키텍처에는 단일 콘텐츠에 대한 단일 URL 경로만 있어야 한다고 말하는 것으로 충분합니다. 무한 루프. 의도하지 않은 복제 문제의 결과는 다음과 같습니다.

나이트 루프. 검색 엔진 스파이더를 넣지 않았는지 확인하십시오.

현장 기술, 설계 및 인프라

133

캘린더 또는 유사한 상황에서 "다음" 링크를 따라가는 잠재적으로 끝없는 작업. 검색 엔진 스파이더가 다른 다음 링크를 찾을 수 있는 캘린더의 다음 날로 다음 링크를 통과할 수 있으면 해당 링크를 따라 다음 페이지로 계속 이동합니다. 크롤러가 인덱싱하려는 콘텐츠에 시간을 할애할 수 있도록 검색 엔진이 따라갈 수 없는 스크립팅된 링크를 사용하여 이러한 상황을 방지합니다. 이전 URL 구조. 많은 사이트 재개발 프로젝트에서 가장 먼저

ects는 이전 URL 구조를 대체하는 것입니다. 문제는 검색 엔진이 이러한 이전 URL의 콘텐츠를 이미 인덱싱했을 가능성이 있으며 모든 URL을 변경하는 즉시 인덱싱을 원점으로 다시 보내는 것입니다. 또한 시간이 지남에 따라 사이트에 누적된 모든 딥 링크는 이전 URL 구조를 가리키고 있습니다. 어떤 대가를 치르더라도 가능한 한 많은 이전 URL을 보존하십시오. 콘텐츠 관리 시스템을 교체할 때 모든 URL을 변경해야 할 가능성이 높으므로 불가피한 경우 이전 URL에 "301 영구적으로 이동됨" 상태 코드를 부여하고 oneto에서 리디렉션하도록 권장합니다. -기존 URL에서 새 URL로의 기본. 301 리디렉션은 검색 엔진용으로 허용되는 유일한 리디렉션입니다.

도메인, 디렉토리 및 URL 구조 모든 것이 중요 처음부터 시작하고 브랜딩 문제의 제한이 허용하는 경우 키워드가 한두 개 포함된 도메인을 선택하십시오. 요즘에는 양질의 키워드가 있는 .com 도메인을 얻기가 어렵지만, 그럴 경우 해당 키워드를 하이픈으로 구분하십시오. UX가 SEO에 미치는 영향의 중요한 부분은 사이트의 디렉토리 구조에 있습니다. 링크 인기도가 사이트 전체에 분산되는 방식에 중요한 영향을 미칩니다. 단순한 것이 더 좋습니다. 어떤 대가를 치르더라도 디렉토리 구조에 관련 없는 파일이 없도록 하십시오. 일부 콘텐츠 관리 시스템은 하위 디렉터리를 자동으로 삽입합니다. 가능하면 이것을 방지하십시오. 이 조건은 전체 사이트의 관련성을 희석시킵니다. 검색 엔진은 사이트 디렉토리가 구성되는 방식을 기반으로 사이트의 계층 구조를 이해하므로 가장 중요한 디렉토리가 아키텍처의 맨 위에 있는지 확인하십시오. 환경이 허용하는 경우 URL 구조에서 사이트 섹션과 관련된 키워드를 사용하십시오. 하이픈으로 키워드를 구분하고

134

8장: 사용자 경험 설계 및 검색 엔진 최적화

하나의 파일 이름에 너무 많은 키워드를 사용하지 마십시오. 다음과 같이 이동하십시오: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. 또한 http://site-in-question에 대한 리디렉션이 설정되어 있는지 확인하십시오. com에서 301로 이동하여 영구적으로 http://www.site-in-question.com으로 리디렉션합니다. 사이트가 www 유무에 관계없이 확인되면 검색 엔진(특히 Yahoo)은 두 URL의 콘텐츠를 색인화하여 실수로 복제할 수 있도록 전체 사이트를 엽니다. 이 조건은 제3자가 www 없이 사이트에 링크하고 사이트에 동적 링크 구조가 포함되어 있을 때 전파되는 경향이 있습니다.

콘텐츠: 한때(그리고 현재)와 미래의 왕 콘텐츠를 생성하는 것은 다른 사람의 문제이지만, 사이트 아키텍처에 놓인 토대는 검색 엔진에서 사용할 수 있는 올바른 콘텐츠를 만드는 것과 많은 관련이 있습니다. 모든 형태의 키워드 기반 검색과 마찬가지로 자산을 보려는 사람들의 실제 검색 행동을 이해해야 합니다. 검색 엔진은 키워드를 입력하는 사용자에 의존하여 이러한 단어와 다소 관련이 있는 자산과 연결한다는 점에서 여전히 매우 "원시적"입니다. 올바른 문구를 선택하는 것은 귀하의 사이트가 올바른 맥락에서 관련이 있는지 여부와 관련이 있습니다. 완벽한 세상에서 귀하의 SEO 파트너는 귀하가 시작하기 전에 일련의 키워드 문구 타겟을 제공하고 와이어프레임 프로세스 전반에 걸쳐 귀하와 협력할 것입니다. 귀하의 프로세스와 관련된 유능한 파트너가 없는 경우 Google 애드워즈 키워드 조사 도구(https://adwords.google.com/select/KeywordToolExternal)를 읽고 탐색하는 사람들의 실제 검색 행동에 대해 약간의 조사를 수행하십시오. 당신의 카테고리. 그런 다음 이 입력에 시간을 투자하여 잠재 고객이 검색하는 문구를 파악하고 해당 문구를 사이트 전체에서 적절하게 사용하십시오. 검색 엔진은 사이트 분석을 통해 여러 위치에서 키워드를 찾습니다. 최적화는 올바른 단어가 올바른 위치에 있는지 확인하는 데 달려 있습니다. UX 디자인 프로세스에서 키워드의 역할을 이해함으로써 미래의 성공을 가능하게 하는 데 필요한 프레임워크를 구축하게 됩니다.

콘텐츠: 한때(및 현재)와 미래의 왕

135

그렇다면 콘텐츠가 왕인 이유는 무엇입니까? 이는 웹 사이트가 제공하도록 설계된 것의 핵심입니다. 검색 엔진은 보고 색인을 생성할 수 있는 텍스트 콘텐츠가 필요합니다. 사이트 방문자는 주의를 끌 가치가 있는 매력적인 콘텐츠가 필요합니다. 블로거와 웹마스터는 링크할 수 있는 콘텐츠가 필요합니다. 올바른 위치에 올바른 콘텐츠가 없으면 검색 엔진이 올바른 방문자를 사이트와 연결할 수 없습니다.

이름 지정 규칙 및 전문 용어와의 전쟁 사이트에 대해 개발된 분류 체계에 키워드 대상이 반영되는 것이 중요합니다. 기본 사이트 구조에서 키워드 구문을 사용하면 전체 사이트가 판매하는 항목과 더 관련성이 높아집니다. 위젯을 판매하는 경우 온라인 제품 목록을 카탈로그라고 부르지 말고 위젯 카탈로그라고 부르십시오. 마찬가지로 키워드 연구를 사용하여 전문 용어에 대한 결정을 내립니다. 예를 들어 사람들이 노트북을 검색하는 것보다 10,000% 이상 더 자주 노트북을 검색하기 때문에 구조에서 노트북이 아닌 노트북이라는 단어를 사용하세요.

메타데이터, 헤더 및 키워드 메타데이터의 기본 문제를 다시 파고들기 전에 이 장까지 여기까지 왔다는 것은 매우 놀라운 일입니다. 무수히 많은 메타 태그를 사용할 수 있지만 다른 태그는 모두 스팸에 취약하기 때문에 실제로 큰 영향을 미치는 것은 소수에 불과합니다. 관련 태그는 다음과 같습니다. 페이지 제목. 이것은 태그가 아니라

페이지 헤더의 실제 태그. 이 태그는 페이지의 실제 제목을 포함하며 페이지에서 가장 중요한 65자입니다. 제목을 "Clements, Samuel"이라고 적힌 구식 도서관 카드 카탈로그에 튀어나온 작은 탭으로 생각하면 해당 탭 뒤에 있는 모든 카드는 Mark Twain의 책임을 나타냅니다. 사이트의 각 페이지에는 고유한 페이지 제목이 있어야 합니다. 제목에 키워드를 넣지 말고 가장 중요한 단어로 제목을 맨 앞에 로드해야 합니다. 메타 키워드. 이 태그는 검색에 거의 영향을 미치지 않습니다.

스팸에 매우 취약하기 때문입니다. 예외는 Google 애드센스 신디케이션이 메타 키워드 태그를 살펴보고 Yahoo가 그것에 의해 매우 3차적인 방식으로 영향을 받는다는 것입니다. 메타 키워드

136

8장: 사용자 경험 설계 및 검색 엔진 최적화

페이지의 콘텐츠와 일치해야 하며 이 태그는 실제로 잠재적인 맞춤법 오류를 삽입하기에 좋은 위치입니다. 페이지마다 달라야 합니다. 메타 설명. 페이지 제목 및 메타 키워드와 마찬가지로

메타 설명은 각 페이지마다 고유합니다. 이 설명은 바로 해당 페이지에 포함된 내용의 요약입니다. 판매하지 말고 150~160자로 작성하십시오. 이 콘텐츠는 검색 엔진이 귀하의 페이지에 대한 링크 아래에 표시할 것이기 때문에 중요합니다. 페이지에 메타 설명이 포함되어 있지 않으면 검색 엔진은 검색된 키워드가 포함된 텍스트 또는 기타 콘텐츠의 스니펫을 찾아 결과에 표시합니다. 메타 설명은 SEO보다 유용성에 관한 것이므로 각 페이지에 태그가 제대로 지정되었는지 확인하세요. "NOINDEX" 메타 태그. 포함하지 않으려는 페이지가 있는 경우

검색 엔진 결과에서 noindex 메타 태그를 사용하십시오. 색인을 생성하려는 페이지에 실수로 이 태그가 포함되어 있지 않은지 확인하십시오. 헤더. 검색 엔진은 헤더, 등을 인식합니다.

스팸 메일을 보내지 않는 한 영향을 미치는 요인으로 간주합니다. 해당 페이지를 설명하고 관련 키워드를 포함하는 섹션 헤더를 허용하도록 주의하십시오. 앵커 텍스트를 연결합니다. 링크 앵커 텍스트는 무엇에 중요한 영향을 미치는지

검색 엔진은 링크 반대편에 있는 페이지에 대해 생각합니다. 이것이 바로 "GoogleBomb"을 만드는 요소입니다. 충분한 링크가 동일한 링크 앵커 텍스트가 있는 페이지를 가리키는 경우 Google은 목적지를 앵커 텍스트의 문구와 관련이 있는 것으로 해석합니다. 예를 들어 Google에서 "여기를 클릭하십시오"를 검색하면 Adobe 사이트가 최상위 결과에 표시됩니다. Adobe를 가리키는 수십만 개의 링크가 있으며 "Adobe Reader를 다운로드하려면 여기를 클릭하십시오" 또는 이와 유사한 것을 읽습니다. 이것을 유리하게 사용하십시오. 앵커 텍스트는 "자세히" 또는 "여기를 클릭하세요"가 아니어야 합니다. 대신 대상 페이지와 관련된 키워드를 포함해야 합니다.

머리카락 나누기 왼손잡이 골판지 위젯과 오른손잡이 골판지 위젯 모두에 대해 별도로 인덱싱된 페이지를 갖는 것이 유리합니다. 이 수준의 세분성은 페이지가 전설적인 롱테일 검색과 정확히 일치할 수 있는 더 나은 기회를 제공합니다. 한 가지에 관한 모든 페이지에는

콘텐츠: 한때(및 현재)와 미래의 왕

137

여러 가지에 관한 페이지보다 그 한 가지가 당첨될 확률이 더 높습니다(물론 다른 모든 요소는 동일함). 어쨌든 수백 단어 길이의 페이지를 읽는 데 관심이 있는 사람이 누구입니까?

사이트 맵 사용 최근 몇 년 동안 클래식 사이트 맵 페이지를 생략하는 것이 인기를 얻었습니다. 이것은 유용성에 대한 실수이자 SEO에 대한 실수입니다. 모든 사이트에 사이트 맵이 필요하다는 사실을 확인하십시오. 멋지지 않을 수도 있지만 필요합니다. 또한 /sitemap.xml 및 /sitemap.txt에 사이트 맵 파일을 포함합니다. 이 구조가 사이트 순위를 높이는 데 도움이 되지는 않지만 검색 엔진이 디렉토리 구조를 이해하고 새롭고 업데이트된 콘텐츠를 찾는 데 도움이 됩니다.

콘텐츠를 최신 상태로 유지 검색 결과에서 상위 게재위치를 얻고 유지하기 위한 핵심 구성 요소는 사이트 콘텐츠를 지속적으로 새로 고치는 것입니다. 이는 사이트의 모든 콘텐츠를 항상 편집한다는 의미는 아닙니다. 이는 사이트가 지속적으로 성장해야 함을 의미합니다. 컨텐츠 추가가 쉽고 직관적이도록 디렉토리 구조를 구축하고 시간이 지남에 따라 사이트가 성장할 것으로 예상하십시오.

기타 콘텐츠 문제 콘텐츠가 풍부한 사이트의 UX를 처리하는 데 있어 기본적인 과제는 콘텐츠 복제 또는 복제를 방지하는 것입니다. PDF 또는 유사한 문서 유형의 페이지를 정확하게 복제하는 "프린터 친화적" 콘텐츠와 같이 무해해 보이는 편리함을 사용하여 중복 페이지를 생성하지 않도록 주의하십시오. 스크립팅된 링크로 이러한 종류의 페이지를 보호하거나 rel=”nofollow” 링크 속성을 사용하십시오. 검색 엔진이 인덱싱할 수 있는 다양한 디지털 자산에 대한 최적화를 할인하지 마십시오. 이 항목은 그 자체로 거의 또 다른 챕터를 만들지 만 PDF, 비디오, 이미지 및 기타 웹 페이지가 아닌 자산은 분명히 자연 검색 결과의 일부라고 말하는 것으로 충분합니다. 검색 엔진에는 이러한 종류의 콘텐츠에 대한 포인터가 필요하기 때문에 이러한 자산 주위에 래퍼를 구성하는 것이 중요합니다. 예를 들어 페이지의 경마 동영상에 대한 텍스트 근처에 '경마 동영상'이라는 앵커 텍스트가 있는 동영상을 가리키는 링크가 없으면 검색 엔진이 저작물이 경마 동영상임을 알 수 없습니다. 암호.

138

8장: 사용자 경험 설계 및 검색 엔진 최적화

alt 속성을 사용하는 것은 검색 엔진에서 비텍스트 자산을 식별하는 데 도움이 되는 또 다른 방법이며 유용성을 위해 항상 좋은 생각입니다. 막다른 콘텐츠 페이지를 만들지 마세요. 검색 엔진 스파이더가 막다른 골목에 갇히지 않도록 구조의 맨 아래에도 기본 사이트로 다시 연결되는 링크가 있는지 확인하십시오. 이동 경로 링크는 페이지 유형에 기본 사이트 탐색이 포함되지 않은 경우 이를 수행하는 간단한 방법입니다.

링크 인기도 설명 SEO의 성배가 있다면 링크 인기도입니다. Google이 등장했을 때 다른 검색 엔진보다 훨씬 더 잘 작동하는 이유의 초석입니다. 링크 인기도는 다른 웹 페이지에서 웹 자산을 가리키는 링크의 품질과 양을 결정합니다. Google은 PageRank라는 용어를 사용하며 다른 많은 결함을 극복할 수 있는 매우 중요한 요소입니다. 링크는 본질적으로 웹 자산에 대한 투표이며, 일반적으로 다른 사람에게 흥미롭거나 가치 있는 무언가가 다른 신뢰할 수 있는 웹 자산에서 가리키는 링크를 가질 것이라고 가정합니다. 시간이 지남에 따라 이 개념은 스팸 노력을 극복하는 데 매우 중요한 것으로 입증되었으며 품질 검색 결과의 핵심 원칙입니다. 이 원칙은 링크 인기도가 웹 사이트 구조로 분산되는 방식 때문에 UX 디자이너가 이해하는 데 매우 중요합니다.

일반적인 링크 인기도 분포 지진 활동의 강도를 측정하는 데 사용되는 리히터 척도와 유사한 Google의 PageRank 시스템(Larry Page가 직접 명명)은 0에서 10까지 범위의 로그 척도입니다. 한 페이지는 PR이 4이고 다른 페이지는 PR이 5이며, PR 5 페이지는 4인 페이지보다 링크 인기도가 10배 높습니다. PageRank는 링크 계층 구조를 기반으로 사이트를 통해 배포하기 때문에 이를 이해하는 것이 중요합니다. 그리고 디렉토리의 구조. 일반적으로 말해서, 홈페이지의 페이지 순위가 5인 경우 기본 섹션 페이지의 PR은 4, 보조 페이지는 PR 3, 3차 페이지는 PR 2 등이어야 합니다.

링크 인기도 설명

139

내부 링크가 가장 많은 페이지가 링크 인기도가 가장 높은 경향이 있습니다. 성공하기 위해 가장 중요한 페이지는 해당 페이지를 가리키는 가장 많은 내부 링크가 있어야 합니다. 여기에는 기본 사이트 탐색, 사이트 맵, 바닥글 및 텍스트에 포함된 인라인 링크의 링크가 포함됩니다. 링크 인기도는 검색 결과에서 좋은 순위를 매기는 데 매우 중요하기 때문에 "구매 제안"이 포함된 페이지에 링크 인기도를 최대한 많이 가져오려면 가능한 한 신중해야 합니다. 각 페이지에는 사이트의 다른 페이지에 기여할 수 있는 링크 인기도가 한정되어 있습니다. 다른 페이지를 가리키는 하나의 링크가 있는 페이지는 사용 가능한 값의 100%를 수신자에게 보내는 것입니다. 100개의 다른 페이지에 대한 100개의 링크가 있는 페이지는 해당 100개의 페이지 각각에 해당 가치의 1%를 전송합니다. 홈페이지는 링크 인기도가 가장 높은 경향이 있는데, 그 이유는 사이트의 홈 페이지가 제3자 웹 사이트에서 가리키는 링크가 가장 많은 경향이 있기 때문입니다. 이것은 홈 페이지가 사이트의 다른 페이지에 기여할 수 있는 가장 큰 가치가 있음을 의미합니다. "판매 제안"의 일부인 중요한 페이지가 있는 경우 검색 엔진이 사이트의 나머지 부분과 비교하여 이 특정 페이지가 얼마나 중요한지 이해할 수 있도록 홈 페이지에서 해당 페이지에 대한 직접 링크를 입력하십시오. 가능하면 홈 페이지에서 딥 콘텐츠에 대한 링크를 회전할 수 있는 기능을 구축하십시오.

바닥글 링크 사이트 전체에서 링크 인기도의 분포를 관리하고 제어하는 방법을 찾을 때 각 페이지의 바닥글에 있는 텍스트 링크는 축복이자 저주이며 링크 인기도 분포와 어느 정도 관련이 있음을 기억하십시오. 사이트 전체에. 일반적인 바닥글 링크는 개인 정보 보호 정책 및 기타 비트랜잭션 페이지를 가리키므로 이러한 링크가 바닥글에 있어야 하는 경우 일종의 스크립팅 뒤에 숨기거나 더 나은 방법은 rel=”nofollow”를 사용하여 이러한 링크를 “nofollow”하는 것입니다. 링크 속성. 이렇게 하면 각 페이지의 링크 인기도가 실제로 검색 결과에서 순위를 매길 필요가 없는 페이지로 유출되는 것을 방지할 수 있습니다. 또한 robots.txt를 사용하여 페이지를 완전히 제외하는 것보다 링크 인기도의 전달을 방지하는 것이 좋습니다.

140

8장: 사용자 경험 설계 및 검색 엔진 최적화

In-Content Cross-Linking 검색 엔진은 텍스트에 포함된 링크를 먹어치웁니다. 과용하지 마십시오. 일부 학파는 텍스트 블록의 처음 몇 개의 링크 이후에는 검색 엔진이 유리한 가중치를 제공하지 않는다고 주장합니다. 텍스트 시작 부분에 가장 중요한 링크를 넣고 대상 페이지와 관련된 키워드가 포함된 링크 앵커 텍스트를 사용합니다.

시스템 게임 검색 엔진 최적화가 모두 일만 하고 재미가 없다고 누가 말합니까? 검색 엔진은 웹 사이트 소유자에게 실질적인 비용을 제공할 수 있으며 특정 환경에서는 어떤 대가를 치르더라도 최상위 순위를 획득할 수 있는 실질적인 접근 방식이 있습니다. 적지 않은 검색 엔진 최적화 프로그램이 클라이언트를 이용하여 단기적으로는 긍정적인 결과를 가져올 수 있지만 시간이 지남에 따라 파괴적인 영향을 미칠 수 있는 가짜 기술에 대해 큰 비용을 청구했습니다. 수년에 걸쳐 최고의 결과를 찾는 웹마스터들은 다양한 최적화 기술을 사용해 왔습니다. 검색 엔진 기술의 핵심 발전 중 하나는 시스템을 조작하기 위해 발견된 영리한 방법을 엔지니어링하는 작업이었습니다. 검색 엔진의 관점에서 볼 때 사용자의 최선의 이익은 모든 쿼리의 맨 위에 있는 깨끗하고 관련성이 높은 결과에 의해 제공됩니다. 많은 검색 엔진 옵티마이저의 관점에서 볼 때 모두 사랑과 SEO에 공평합니다.

흰 모자 대 검은 모자 SEO 방법을 "하얀 모자" 또는 "검은 모자"로 특징짓는 것은 쉽고 재미있지만, 어느 것이 무엇인지 식별하는 것은 훨씬 더 어렵습니다. 많은 화이트 햇 옵티마이저는 특정 기술 관리, 콘텐츠 및 링크 조작 및 기타 접근 방식이 단순히 금지되어 있다고 강력하고 선언적인 용어로 말하는 순수주의자입니다. Black Hats는 이 문제를 부정 행위와 무관한 경연으로 보고 있습니다. 구체적으로 작성된 규정집이나 법원이 없다면 어떻게 부정 행위가 될 수 있습니까? 그들의 접근 방식은 고양이가 모든 카드를 쥐고 쥐가 상당한 돈을 벌기 위해 서 있을 수 있는 고양이와 쥐 게임의 라인에 더 가깝습니다. 위험을 감수하고 승리하면 보상이 커집니다. 그러나 일단 검색 엔진이 당신을 따라잡으면(그리고 그들은 거의

시스템 게임

141

항상 하십시오) 귀하의 사이트가 금지되거나 적어도 방법이 취소되었을 때 수행할 수 없게 될 수 있도록 준비하십시오.

메타 키워드로 스팸 보내기 많은 "속임수" 기술은 UX 원칙에 기반을 두고 있습니다. 시스템을 조작하는 초기 방법은 사이트 콘텐츠가 모두 오렌지에 관한 것일 때 메타 키워드 스터핑(meta keywords stuffing)이었습니다. 본질적으로 수백 번의 사과 발생으로 메타 키워드 태그를 채웁니다. 기본적으로 메타 키워드 접근 방식은 초기 웹의 분류 체계를 돕기 위해 만들어졌습니다. 오늘날 모든 키워드 스팸으로 인해 웹 페이지의 이 부분은 검색 배치에 거의 영향을 미치지 않습니다. 검색 엔진은 이 기술을 쉽게 감지하고 신속하게 이를 처리할 수 있었습니다. 차세대 스팸은 해명하기가 조금 더 어려웠으며 UX 문제에 뿌리를 두고 있습니다.

복제 및 도어웨이 페이지 복제 및 도어웨이 페이지는 모두 검색 엔진에서 웹 사이트를 더 크게 보이거나 다르게 보이게 만드는 데 사용되는 방법입니다. 페이지를 반복해서 복제함으로써 웹마스터는 본질적으로 특정 검색 구에 대해 신속하게 지배할 수 있는 미세한 대상 콘텐츠를 제조할 수 있습니다. 이러한 관행으로 인해 검색 엔진은 의도적이든 아니든 복제에 민감하므로 아키텍처가 부주의한 복제를 방지하는지 확인하는 것이 중요합니다. 도어웨이 페이지는 흰 모자와 검은 모자 방법 사이의 회색 공간에 걸쳐 검색 결과에 영향을 미치는 또 다른 방법입니다. 한편으로 웹마스터에 대한 Google의 품질 가이드라인에는 "도어웨이 페이지가...웹마스터 가이드라인을 위반했습니다"(www.google.com/support/webmasters/bin/answer.py?answer=66355)라고 명시되어 있습니다. 지침에서는 도어웨이 페이지를 실제 사이트와 관련이 없거나 스팸인 키워드 세트에 대해 특별히 최적화된 품질이 낮은 페이지로 식별합니다. 반면에 검색 엔진이 스파이더블할 수 없는 데이터베이스에 갇혀 있거나 검색 엔진이 좋아하지 않는 기술로 인해 가려진 콘텐츠에 액세스할 수 있도록 검색 엔진을 어떻게 도울 수 있습니까? 긍정적인 정의에서 도어웨이 페이지는 검색 엔진이 보고 이해할 수 있는 동시에 방문자에게 동적 콘텐츠에 대한 입구를 제공하는 고품질 정적 콘텐츠입니다. 오늘날의 콘텐츠 관리 시스템은 다음과 같은 핵심 문제에 대해 개선되고 있습니다.

142

8장: 사용자 경험 설계 및 검색 엔진 최적화

이 접근 방식이 필요했지만 검색 엔진이 그렇지 않으면 처리할 수 없는 콘텐츠의 정적인 표현을 검색 엔진에 표시하려는 명시적인 목적을 위해 추가 페이지를 만드는 것이 여전히 매우 유용할 수 있습니다.

링크 스패밍 게임 시스템을 위한 최근 방법은 최신 웹 검색 엔진이 작동하는 방식의 핵심 개념인 링크 인기도 조작에 중점을 두었습니다. 위에서 설명한 것처럼 검색 엔진은 다른 위치에서 해당 페이지를 가리키는 링크의 양과 품질을 분석하여 특정 웹 자산의 관련성을 결정합니다. 검색 엔진 최적화 프로그램은 교묘한 리디렉션, 하위 도메인의 남용, 사이트의 모든 페이지를 "/index.html"로 만드는 등 다양한 기타 교묘한 기계 조작을 통해 퍼즐의 이 부분을 조작하기 위해 노력했습니다.

몇 가지 최종 생각 이것이 검색 엔진 최적화 문제에 대한 첫 번째 탐구인지 의심스럽습니다. 이제 사이트의 아키텍처 및 관련 문제가 검색 엔진 성능에 얼마나 영향을 미치는지 분명해졌습니다. 현재의 검색 환경은 단순한 분류나 구조보다 비약적인 발전입니다. 사려 깊은 검색 엔진 최적화는 양질의 UX에서 시작됩니다. 웹 사이트의 설계는 검색 엔진의 성공 또는 임박한 실패에 대비할 수 있는 수명 주기의 중요한 지점입니다. 검색 엔진 최적화는 결코 끝나지 않는 전략이지만 품질 SEO는 UX 디자이너의 주의 깊은 관심 없이는 결코 시작되지 않습니다. Jonathan Ashton은 Agency.com의 SEO 및 웹 분석 부사장이며 SEO를 위한 Center of Excellence를 운영하고 있습니다. 그의 팀은 회사 전체에 SEO 서비스를 제공하여 풍부한 대화형 경험을 디자인하고 구축하는 과정에서 검색 엔진에서 찾을 수 있는 사이트를 만들도록 합니다. 그의 월간 칼럼 "Industrial Strength SEO"는 http://searchengineland.com/lands/columns/industrial-strength.php에서 볼 수 있습니다.

몇 가지 최종 생각

143

전환: 정의에서 설계로 시각화, 우선 순위 지정 및 계획에 걸리는 시간 이제 비즈니스 요구 사항 및 사용자 요구 사항에 대한 멋진 목록이 생겼습니다. 그리고 토론에 집중할 수 있도록 사용자로부터 정보를 얻었습니다. 그래서 지금 무엇? 당신이 프로젝트의 샹그릴라에 속하지 않는 한, 당신은 어떻게든 그 목록에 집중하고 관리해야 할 필요가 있음을 알려주는 예산(빡빡함), 타임라인(긴급) 또는 둘 다를 갖게 될 것입니다. 이 장에서는 정의에서 설계로 전환할 수 있는 몇 가지 방법에 대해 설명합니다. 여기에는 팀이 설계해야 하는 솔루션을 시각화하는 데 도움이 되는 전술, 통합된 요구 사항 집합을 생성하기 위해 기능의 우선 순위를 지정하고 다음 단계에서 수행할 설계 활동을 계획하는 데 도움이 되는 전술이 포함됩니다. 프로젝트의 다음 단계. 캐롤린 챈들러

씨

4장에서는 다양한 프로젝트 접근 방식 또는 방법론과 이들이 프로젝트 팀 및 비즈니스 이해 관계자와 협업하는 방식에 어떤 영향을 미치는지에 대해 다뤘습니다. 승인 단계로 분리된 정의 및 설계 단계가 있는 폭포수 접근 방식과 일부 단계가 겹치는 수정된 폭포수 접근 방식을 비교했습니다. 이 장에서는 정의 단계와 설계 단계 사이의 중첩에서 발생할 수 있는 활동에 대해 설명합니다.

디자인 정의 개발

프로세스의 이 시점은 이해관계자 중에 나타나지 않은 기능을 아이디어화하고 시각화할 적기입니다.

인터뷰 또는 사용자 조사. 우선순위를 정하기 전에 프로젝트 팀과 함께 이 작업을 수행하면 비즈니스 및 사용자 요구를 모두 충족하는 혁신적인 기능을 고려하고 계획할 수 있습니다. 프로젝트 요구 사항의 우선 순위를 지정합니다. 여기에는 통합 목록을 가져오는 것이 포함됩니다.

비즈니스 요구 사항, 사용자 요구 사항 및 프로젝트 팀 아이디어를 분석하고 프로젝트 목표를 충족하는 데 있어 상대적 중요성을 결정합니다. 이 시점에서 각 요구 사항을 충족하는 데 필요한 일반적인 노력 수준을 이해하기 위해 개발 팀과 협력하게 됩니다. 디자인 중에 사용할 활동과 문서를 계획합니다. 이것

계획은 다른 팀 구성원과 작업하는 방법과 사이트 맵 및 와이어프레임(10장 및 11장에서 설명)과 같은 귀하로부터 받을 도구 또는 문서의 유형을 결정합니다. 이 장에서는 UX 디자이너가 프로젝트 팀 구성원과 공동으로 사용하기 쉬운 아이디어화 및 시각화 방법부터 시작하여 이 세 가지 영역을 각각 다룹니다.

전환: 정의에서 설계로

145

일반적인 시나리오 요구 사항이 정의되고 승인되었으며 계획에서 사이트 기능을 디자인하는 중입니다. 디자인 프로세스 중간에 특정 도구를 제공하는 것이 사용자에게 정말 도움이 될 것임을 깨닫게 됩니다. 흥미로운 아이디어이지만 새 도구를 설명하는 요구 사항이 없으므로 이제 포함하려면 우선 순위가 지정된 요구 사항을 변경해야 합니다. 요구 사항 목록을 변경하려면 강력한 사례를 만들어야 합니다. 특히 그렇게 하면 목록에서 다른 것이 필요하거나(그것이 무엇인지 결정하는 데 시간이 걸립니다) 프로젝트 일정이 지연될 수 있습니다. 게임에서 너무 늦게 나왔기 때문에 단순히 아이디어가 포함되지 않을 가능성이 있습니다. 프로젝트의 어느 시점에서든 새로운 아이디어가 나올 수 있지만, 요구 사항 수집이 완료된 후 우선 순위를 정하기 전에 기능을 아이디어화할 시간을 따로 마련하면 이러한 아이디어를 더 일찍 생성하고 포함될 가능성을 높일 수 있습니다. 또한 비즈니스 이해 관계자나 사용자에게 발생하지 않았을 수 있는 혁신적인 기능을 고려하는 데 시간을 할애할 수 있습니다.

아이디어 구상 및 시각화 기능 UX 디자이너는 단어(예: 요구 사항)와 이미지(예: 사이트 맵 및 와이어프레임) 사이의 정신적 격차를 해소하는 데 도움이 되는 고유한 기술 세트를 가지고 있습니다. 사람들이 요구 사항에 대해 이야기하고 언어에 대해 논쟁을 벌일 수 있지만 시각적으로 표현된 개념을 볼 수 있을 때까지 실제로 동일한 페이지에 도달하지 못하는 경우가 많습니다. 반면에 특정 시각적 세부 정보로 너무 빨리 이동하면 큰 질문을 해결하기 전에 더 작은 세부 정보(예: 양식의 선택 항목이 라디오 버튼이어야 하는지 아니면 드롭다운 옵션이어야 하는지 여부)에 대화가 집중될 위험이 있습니다. (예: 사용자가 처음에 해당 특정 양식을 작성해야 하는지 여부). 세부 설계가 본격적으로 시작되기 전에 다른 사람들이 참여하는 방식으로 컨텍스트, 흐름 및 스토리를 시각화하는 데 도움이 되는 프로세스 전반에 걸쳐 사용할 수 있는 많은 개념적 설계 기법이 있습니다. 이러한 기술은 또한

146

9장: 전환: 정의에서 설계로

우선 순위가 지정되기 전에 요구 사항 문서에 추가할 수 있는 기능에 대한 필요성을 불러일으킵니다. 그러한 기술 중 하나는 브레인스토밍 회의 중에 종이나 화이트보드에 스케치한 특정 사용자 시나리오의 시각화인 스토리보드의 공동 생성입니다. 그런 다음 UX 디자이너는 이러한 스케치에서 작업하여 세부 정보를 추가합니다.

스토리보드의 기본 프로세스 탐색하고 싶은 시나리오 목록을 작성하여 스토리보드 세션을 준비합니다. 시나리오를 구축하려면 다음 질문을 고려하고 세션에 대한 답변을 가져오십시오. 이 시나리오의 주요 사용자는 누구입니까? 그는 어떤 역할을 하고 있습니까? 이것은

사용자 모델이나 페르소나가 유용한 곳입니다. 그들이 있다면 회의에 데려오십시오. 그들은 대화에 집중하고 프로젝트 팀이 디자인 단계 전체에서 사용자 모델링 도구를 사용할 수 있는 방법을 더 잘 이해할 수 있도록 합니다. 선택한 사용자는 사이트의 처음 사용자입니까? 그렇지 않다면 그는 산발적입니까?

사용자입니까, 아니면 자주 사용합니까? 이는 논의할 기능의 수준에 영향을 미칩니다. 처음 사용하는 사용자는 자주 사용하는 사용자가 좋아할 수 있는 선택 항목의 수에 압도될 수 있습니다. 새 사용자를 위한 상황별 도움말 또는 자주 사용하는 사용자를 위한 사용자 지정 기능과 같이 각 그룹에 필요할 수 있는 다양한 기능을 나타내기 위해 시나리오를 두 번 설명할 수 있습니다. 어떤 즉각적인 요구가 이 사용자를 사이트로 이끈 것입니까? 그는 무엇을 하려고 하는가

성취하고, 왜? "제품 권장 사항 찾기"와 같이 비즈니스 또는 사용자 요구 사항에서 다루는 높은 수준의 작업을 살펴봄으로써 이에 대한 생각을 생성할 수 있습니다. 아마도 사용자는 스노우 부츠가 필요하고 신발이 새지 않고 발이 젖지 않도록 하기 위해 제품 권장 사항을 찾고자 할 것입니다. 세션을 위해 브레인스토밍 팀을 모으십시오. 이 팀은 귀하와 다른 한 사람일 수도 있고 다른 서너 명으로 구성된 소규모 그룹일 수도 있습니다. (더 많은 것이 가능하지만 모든 사람을 화이트보드 주위에 효과적으로 모아 당면한 작업에 집중하도록 하는 것은 어려울 수 있습니다.)

기능 아이디어 및 시각화

147

이상적으로는 그룹에서 적어도 한 사람이 사용자 관점을 나타내는 책임이 있습니다. 다른 사람은 비즈니스 관점을 나타내야 합니다(예: 해당 역할이 프로젝트에서 대표되는 경우 비즈니스 이해 관계자 또는 비즈니스 분석가). 관점을 전환할 수 없다는 의미는 아닙니다. 토론 중에 가능한 한 사용자와 비즈니스 요구 사항을 모두 고려할 수 있고 고려해야 합니다. 사용자와 비즈니스 요구의 균형에 대한 자세한 내용은 "좋은 긴장 유지" 섹션을 참조하십시오. 팀을 구성한 후에는 비즈니스 및 사용자 요구 사항을 충족하고 향후 디자인 노력에 집중하는 데 필요할 수 있는 일부 기능을 이해하는 활동의 목적을 그들에게 알려주십시오. 위에 나열된 질문에 대한 답변과 논의할 시나리오 목록을 제시하십시오. 그런 다음 화이트보드로 올라가서(또는 종이에 연필을 대고) 시나리오에 대해 그룹 질문을 합니다. 온라인 검색, 배너 고려

광고, 입소문 및 기타 수단. 온라인 검색이 떠오를 경우 요구 사항을 정확하게 반영합니까?

이 검색을 지원하기 위한 기능 또는 활동의 유형(예: SEO 요구 사항에 대한 태깅)은 무엇입니까? 사이트에 도착하면 사용자는 자신의 필요와 관련이 있는 것을 보게 됩니까? 작업을 완료하기 위해 사용자는 어떤 경로를 선택합니까? 이것을 스케치하십시오

높은 수준의 세부 사항. 다른 사람들이 작업에 참여하고 있습니까? 그렇다면 어떻게 관련될 수 있습니까?

(전화, 이메일, 협업 사이트 기능) 주요 사용자의 결정이나 행동에 어떤 영향을 미칠 수 있습니까? 도중에 사용자가 도움을 필요로 하는 곳은 어디입니까? 그는 그것을 어떻게 얻을 것인가? 사용자가 작업을 완료하면 어떻게 됩니까? 일반적인 디자인 오류

사용자의 작업이 완료되면 작업이 끝났다고 생각하지만 사용자가 사이트의 다른 영역을 탐색하거나 관련 제품 구매를 고려하도록 권장할 수 있는 좋은 시간입니다. 일반적인 비즈니스 시나리오의 예를 고려하십시오. 회사의 .com 사이트에 새 작업을 게시해야 하는 필요성입니다. 이 시나리오를 위해 이해관계자 인터뷰를 실시했으며 고용 프로세스가 주로 채용이 필요한 사람과 함께 일하는 인사 부서의 Jeff라는 한 사람에 의해 관리된다는 사실을 발견했다고 가정해 보겠습니다. 148

9장: 전환: 정의에서 설계로

Jeff는 현재 존재하는 직업 설명에 꽤 익숙합니다. 새 직책이 필요할 때 그는 일반적으로 새 직책의 잠재적 관리자가 그에게 일자리를 게시하도록 요청하는 시기를 알아냅니다. 그런 다음 작업 설명을 작성하고 게시하기 위해 Jeff와 관리자(Emily라고 부름) 간의 공동 작업 프로세스입니다. 그림 9.1은 이 시나리오의 스토리보드가 어떻게 보이는지 보여줍니다. 이 그림은 여기에서 만들 수 있는 스토리보드의 한 부분만 보여줍니다. Emily가 거쳐야 하는 승인 프로세스를 보여주기 위해 시나리오의 초기부터 시작하거나 구직자가 일자리를 찾고 지원하는 것을 보여주기 위해 스토리보드를 계속할 수 있습니다. 여기서 주목해야 할 중요한 점은 이와 같은 스토리보드를 통해 귀하와 귀하의 프로젝트 팀이 워크플로를 일련의 페이지 이상으로 볼 수 있다는 것입니다. 그것은 인간적 요소와 맥락을 가져옵니다. 그리고 페르소나(Jeff)라는 인간적 요소가 없었다면 팀에서 기존 작업 설명을 가져오는 기능을 시작에 포함할 생각을 못했을 것입니다. 비록 우리 모두가 시간을 절약하고 우리가 필요한 모든 것을 포함하고 있습니다.

그림 9.1 처음에 화이트보드에서 생성된 스토리보드는 Wacom 태블릿을 사용하여 Microsoft Visio에서 스케치 및 상세화되었습니다.

기능 아이디어 및 시각화

149

스토리보드와 다른 유형의 스케치(예: 사용자 흐름 및 개념적 와이어프레임)를 사용할 때 염두에 두어야 할 한 가지는 기본적으로 브레인스토밍 도구라는 것입니다. 몇 가지 훌륭한 아이디어가 연습에서 나오지만 이러한 스케치는 세부적인 디자인을 의미하지 않습니다. 이 사실은 스케치 형식(프로토타입 형식과 반대)에서 명백할 수 있지만 스케치에서도 시각화된 기능을 보는 것은 때때로 해당 기능이 해당 기능에 존재할 것이라는 기대로 이어질 수 있기 때문에 여전히 비즈니스 이해 관계자에게 확인해야 할 중요한 사항입니다. 최종 제품. 여기에서 또 다른 위험은 참가자가 무언가가 페이지에 있어야 하는지 아니면 팝업에 있어야 하는지와 같은 사용자 인터페이스 요소에 대한 논쟁에서 곁길로 빠질 수 있다는 것입니다. 이러한 종류의 문제는 종종 시나리오에서 해결해야 하는 더 큰 문제보다 해결하기 더 쉽거나 더 친숙하기 때문에 이러한 세부적인 논의에 들어가기가 매우 쉽습니다. 작업을 간소화하고 시간을 효율적으로 사용하려면 참가자들에게 우선 순위가 지정된 요구 사항 목록에 따라 설계하는 지점에 대해 이러한 종류의 토론을 저장하도록 요청하십시오. 그리고 그것은 우리를 그 과정의 다음 단계로 이끕니다. 수집하는 데 너무 많은 시간을 소비한 아름다운 요구 사항의 우선 순위를 정하는 종종 활기차고 때로는 고통스러운 과정입니다!

우선 순위 지정 프로세스 촉진 사용자 요구 사항 및 아이디어 작업을 기반으로 하는 기능으로 구체화된 일련의 비즈니스 요구 사항이 있습니다. 이제 가장 어려운 부분 중 하나가 나옵니다. 가치가 높은 요구 사항의 우선 순위 목록으로 모든 것을 깎아 내리는 것입니다. 우선 순위를 지정해야 하는 요구 사항을 검토할 때 대상 그룹에 대한 토론에 집중할 수 있도록 프로젝트 목표와 사용자 모델을 준비하십시오. 귀하 외에도 사용자 옹호자로서의 역할에서 우선 순위 지정 프로세스에는 다음도 포함되어야 합니다. 비즈니스 관점을 대표하는 사람(비즈니스

지지하다). 개발팀의 관점을 대변하는 사람(

개발 옹호자).

150

9장: 전환: 정의에서 설계로

프로젝트의 요구 사항을 대표하는 사람(예: 프로젝트

관리자). 이 사람은 우선순위 결정 회의에 참석할 필요가 없을 수도 있지만 우선순위 결정에 영향을 미치는 모든 제약 조건(예: 기한 또는 예산)을 설정하고 최종 목록이 해당 회의에 맞는지 확인합니다.

우선순위 지정에서 UX 디자이너의 역할 우선순위 지정을 UX 디자이너의 문제가 아니라 프로젝트 스폰서, 프로젝트 관리자 및 개발 팀 리더 간의 공동 책임으로 간주하고 싶을 수 있습니다. 진실에서 더 이상은 없습니다. 우선순위 논의는 성공적인 솔루션이 만들어지거나 깨지는 곳입니다. 사용자 경험 디자이너는 이러한 중요한 대화를 위해 자신의 기술을 발휘할 책임이 있습니다. 이미 우선 순위 지정 프로세스에 참여하고 있는 경우 이 섹션에서 참여에 대한 팁을 제공합니다. 그렇지 않다면 참여하기 위해 할 수 있는 일을 하십시오. 이것은 프로젝트 팀에게 촉진과 같은 기술과 가져올 수 있는 균형 잡힌 관점을 알려야 한다는 것을 의미합니다. 서로 다른 팀원의 관점을 이해하고 통합된 이해를 위해 협력할 수 있음을 입증하는 것이 중요합니다. 이 균형을 이루는 방법에 대한 자세한 내용은 "좋은 긴장 유지" 섹션을 참조하십시오.

우선 순위 지정 팀은 다음 질문에 답하기 위해 각 요구 사항을 살펴봅니다. 비즈니스에 대한 중요성 수준은 무엇입니까? 얼마나 중요한가

하나 이상의 프로젝트 목표를 달성하기 위한 요구 사항은 무엇입니까? 이 요구 사항을 생략하면 영향이 얼마나 큽니까? 사용자에게 중요한 수준은 무엇입니까? 요구 사항이 충족됩니까?

일반적인 사용자 요구 사항(또는 우선 순위 사용자 그룹에 대한 강력한 요구 사항)? 이것이 생략되면 사용자 경험에 어떤 영향을 미칩니까? 매우 유사하고 경쟁할 수 있는 다른 요구 사항이 있습니까? 이 마지막 질문의 경우, 동일한 문제에 대한 여러 솔루션이 서로 경쟁할 수 있고 사용자 혼란을 유발할 수 있음을 명심하십시오(또한 지원하는 데 더 많은 노력이 필요함). 예를 들어 New York Times에는 모든 공유 기능을 지원할 수 있을 만큼 충분히 많은 개발 직원이 있을 수 있습니다.

우선 순위 지정 프로세스 촉진

151

nytimes.com(그림 9.2에서 파란색으로 표시됨)에서 일부 사용자는 기사를 친구에게 보내기 위해 추천, 이메일 또는 공유를 클릭해야 하는지 혼란스러울 수 있습니다. 사용자가 지난 몇 년 동안 폭발적으로 증가한 모든 공유 옵션에 익숙하지 않을 수 있다면 아마도 더 작은 기능 세트로 시작해야 할 것입니다. 요구 사항 개발의 기술적 타당성은 무엇입니까? 무엇

그것을 개발하는 데 시간이 필요합니까? 상대적으로 새로운 기술로 작업하는 경우 여기에서 예상 시간이 더 높아집니다. 개발의 자원 타당성은 무엇입니까? 프로젝트를 수행합니까?

팀에 기능을 개발하는 데 필요한 인력, 기술 및 자금이 있습니까? (신기술 도구 구입 및 학습 비용을 고려하십시오.)

그림 9.2 온라인 신문이 제공하는 많은 공유 기능을 강조하는 www.nytimes.com의 장면

152

9장: 전환: 정의에서 설계로

각 요구 사항에 대한 결정을 캡처하는 워크시트를 만듭니다. 여기에는 위의 질문에 기반한 낮음, 중간 또는 높음 등급이 포함될 수 있습니다. 또는 정렬 목적으로 숫자를 더할 수 있도록 숫자 척도를 사용할 수 있습니다. 목록을 따라가다 보면 유사한 요구 사항을 통합하거나 큰 요구 사항을 잠재적으로 독립적인 작업 단위를 나타내는 여러 개의 작은 요구 사항으로 나누어야 할 수도 있습니다. 이 시스템은 단순히 정렬 및 우선 순위 지정을 돕기 위한 것입니다. 요구 사항의 실행 가능성에 대한 과학적 분석을 기반으로 하지 않습니다. 그러나 큰 목록을 관리하고, 토론을 고무하고, 상대적 중요성을 파악하는 데 매우 유용합니다. 그림 9.3은 중요도 및 타당성(낮음, 중간 및 높음)의 높은 수준 범주를 사용하여 각 요구 사항에 상대 값을 할당하는 우선 순위 지정 워크시트의 예를 보여줍니다. 우선순위 워크시트

요구 사항

설명

비즈니스 중요성

사용자 중요성

&%**%&

&($

)()$+)*'(&,! &%**!%&($*!&% &()!%#!)*& !)*(!+*&()

)()%#&!%*& )##')*&(() $!%* #)* /)

(( ("!%

(()% *("/%*(!% *("!%&!,% &%%&(( ) ) !''

("!%

)()%*("* !( '"/ #&-!%*(+")&( !('#%)

$!# &%2($*!&%

((!)*&(/

%$!#!))%**& &%2($%&(( ) %$

((

+#2##$%* ,!-)

)()%( &* (+)*&$()1 (,!-)&* &$'%/0)+#2##$%* '(&))

((

+#2##$%* *

)()% *-!* &* (+)()&+* * !(&((+#2##$%* .'(!%

기술적 타당성

자원 타당성

!+$

그림 9.3 요구사항 우선순위 지정을 위한 워크시트의 예

우선 순위 지정 프로세스 촉진

153

각 범주에 값을 할당하면 우선 순위 지정 팀 간에 많은 대화를 나눌 수 있습니다. 토론과 의사 결정을 촉진하는 데 어떻게 도움을 줄 수 있습니까? 당신이 할 수 있는 가장 중요한 두 가지는 균형 잡힌 솔루션을 정의하는 데 핵심이 되는 다양한 관점을 이해하고(때로는 표현하는 것) 프로젝트 팀 내에서 갈등 영역을 해결하는 데 도움을 주는 것입니다. 먼저 우선순위를 정하는 동안 올바른 관점 집합을 나타내는 것에 대해 이야기해 봅시다. 여기에는 사용자 옹호, 비즈니스 옹호 및 개발 옹호 사이의 긴장을 만들고 유지하는 것이 포함됩니다. 이는 좋은 사용자 경험을 제공하고 프로젝트 제약을 충족하며 비즈니스 목표에 부합하는 균형 잡힌 솔루션을 보장하기 때문에 좋은 종류의 긴장입니다.

좋은 긴장 유지 요구 사항을 수집하고 나머지 프로젝트 전반에 걸쳐 팀 토론 중에 세 가지 역할이 서로 대립하는 것을 볼 수 있습니다.

154

비즈니스 옹호자: 비즈니스 요구 사항과 요구 사항을 대표하고 가능한 한 충실하게 파악하고 충족하도록 하는 팀원입니다. 비즈니스 옹호자의 주요 관심사는 회사 및 부서의 전략적 목표 충족, 프로젝트 중에 비즈니스 비전이 손실되지 않도록 보장, 프로젝트 목표에 대한 초점 설정 및 유지 등입니다. 사용자 옹호자: 사이트를 경험하게 될 기본 사용자의 요구와 관점을 대표하는 팀원입니다. 사용자 옹호자의 주요 관심사는 사이트가 유용성에 대한 기대치를 충족하는지 확인하고, 만족스럽고 매력적인 경험을 제공하고, 프로젝트 목표를 지원하는 행동을 장려하는 것입니다. 개발 지지자: 기술 및 품질 보증 팀의 요구와 제약을 대표하는 팀원입니다. 주요 관심사는 개발 팀이 범위 내에서 효율적으로 작업하고 사용자 및 비즈니스 이해 관계자가 기대하는 품질 표준을 충족하는 제품을 제공하는지 확인하는 것입니다.

9장: 전환: 정의에서 설계로

옹호자들 사이의 삼자 줄다리기로 이것을 상상해보십시오. 셋 사이에 긴장이 정중하게 잘 유지되면(아무도 지지자가 지배하지 않는다는 의미) 셋이 프로젝트 목표를 충족하는 균형 잡힌 솔루션을 향해 노력할 수 있습니다. 각 팀원은 프로젝트 전반에 걸쳐 균형을 유지하는 데 관심이 있음을 알고 있어야 합니다. 한 쪽이 우세하면 다른 역할이 자리를 잃고 프로젝트가 목표를 놓치거나 예상보다 훨씬 높은 비용으로 목표를 달성할 위험이 있습니다. 장력이 균형을 이루지 못할 때 발생할 수 있는 일의 예는 그림 9.4를 참조하십시오.

그림 9.4 적절한 장력이 유지되지 않을 때의 결과

좋은 긴장을 유지하십시오

155

프로젝트에서 이러한 역할 중 하나 이상을 수행할 수 있습니까? 전적으로! 이상적으로는 서로 다른 팀 구성원이 각 역할에 대한 주요 책임을 지지만 그렇다고 해서 때때로 위치를 바꿀 수 없다는 의미는 아닙니다. 실제로 토론에서 토론으로 또는 주제에서 주제로 역할을 전환할 수 있습니다. UX 디자이너로서 당신은 가장 자주 사용자 옹호자 역할을 하겠지만 성공적인 디자인을 만들기 위해서는 세 가지 역할 모두의 관점을 이해하고 일관되게 표현되도록 해야 합니다. 때때로 역할을 전환하는 것이 바람직하지만 자신을 이러한 역할 중 하나 이상을 담당하는 기본 담당자로 지정하지 않도록 주의하십시오. 불편하지만 중요한 질문을 할 "악마의 옹호자"가 지속적으로 존재하지 않기 때문에 프로젝트가 진행됨에 따라 도전받지 않는 타협을 시작할 수 있습니다. 한 가지 이상의 역할을 맡아야 하는 경우, 좋은 긴장 상태를 유지하는 데 도움이 되도록 가끔 다른 역할을 맡아줄 시간제 자원을 찾으십시오. 지금까지 비즈니스 옹호자(특히 4장과 5장)와 사용자 옹호자(특히 1장과 6장)의 역할에 중점을 두었습니다. 우선순위 논의에서 세 번째 주요 역할인 개발 지지자에 대해 잠시 논의해 봅시다.

개발 지지자 당신이 UX 디자이너라면 다른 사람의 입장에서 그들의 요구와 목표를 이해할 때 성공할 것입니다. 이 기술은 사용자 옹호자로서의 역할을 수행하고 조직 내 사람들과 효과적인 커뮤니케이션 및 협업을 보장하는 데 매우 중요합니다. 잠시 시간을 내어 이 기술을 사용하여 개발 지지자의 목표를 설명하겠습니다. 중요한 설계 논쟁 중 하나는 개발 옹호자가 요구 사항 수집 프로세스에 참여하고 영향을 미치는 범위와 그 과정에서 자신의 역할에 관한 것입니다. 개발 지지자가 기술적 가능성과 한계를 너무 일찍 제시하면 매우 혁신적인 솔루션으로 이어질 수 있는 브레인스토밍을 일부 줄일 수 있습니다. 결국, 오늘날의 파란 하늘 아이디어는 몇 가지 추가 기술 탐색으로 가능할 수 있습니다. 아이디어가 실현 가능하지 않더라도 논의를 통해 해결할 수 있는 근본적인 요구 사항이 나올 수 있습니다. (요구 사항에 대한 기능 요청 매핑은 이 장의 뒷부분에서 다룹니다.)

156

9장: 전환: 정의에서 설계로

다음은 개발 옹호자의 목표 및 관련 책임입니다. 시간과 예산 내에서 요구 사항 충족 팀 효율성 보장(중복 작업 방지,

가용한 도구 및 플랫폼을 최대한 활용 비용 효율적인 추가 도구 선택 향후 변경 시 많은 추가 작업이 필요하지 않도록 함 성장을 수용할 수 있도록 솔루션을 확장 가능하게 함 솔루션을 모듈식으로 만들어 개별 부분을 쉽게 수정할 수 있도록 함 가능한 한 표준화된 솔루션 만들기: 수정 사항이 적을수록

구매한 시스템으로 만들면 나중에 재개발 작업이 덜 필요합니다. 개발 팀이 잘 작동하는지 확인합니다. 상대적으로 흥미롭고 보람 있는 작업을 제공하여 이직을 제한합니다.

상속된 요구 사항으로 작업 q단계 4

1 단계

요구 사항을 검토하고 요구 사항이 불분명하거나 사용자 가치가 의심스러운 요구 사항을 표시합니다.

파일 o' 요구 사항을 상속하고 초기 검토를 수행합니다.

유

2단계 가능한 사용자에 대한 컨텍스트를 제공하는 정보를 수집합니다.

"사용자는..."

5단계 팀과 함께 표시된 요구 사항을 검토하여 요구 사항과 충돌을 조사합니다. "이유가 여기에 있습니다."

B U

비

디

3단계 임시 사용자 모델을 만듭니다.

6단계 수행해야 할 필요가 있다고 생각하는 변경 사항의 우선 순위를 정하십시오. 그들에 대한 귀하의 사례를 만들고 프로젝트 팀에 제시하십시오. 간단하고 실용적이어야 합니다.

ㅏ

유

"좋은 지적!"

유

"흠..."

비

디

좋은 긴장을 유지하십시오

157

그러나 개발 지지자가 충분히 초기에 참여하지 않으면 팀이 특정 옵션의 경로를 훨씬 더 아래로 이동하여 포함하기에는 비용이 너무 많이 들거나 개발 지지자가 자신의 목표 중 하나 이상을 놓치게 될 수 있습니다. 그리고 마지막으로 중요한 점은 개발 지지자는 새로운 기술이나 활용도가 낮은 기능과 같이 솔루션을 진정으로 돋보이게 할 수 있는 기술의 일부 기능을 끌어낼 수 있는 훌륭한 소스입니다. 효과적인 접근 방식은 브레인스토밍이 완료되고 높은 수준의 요구 사항이 캡처되고 우선 순위 지정 프로세스가 시작되려고 하면 개발 옹호자와 함께 주요 검토를 계획하는 것입니다. 이를 통해 개발 옹호자는 선택한 도구를 탐색하는 프로세스의 초기 부분을 사용하여 가능하거나 불가능할 수 있는 항목에 대한 자세한 정보를 얻은 다음 특정 주제와 아이디어가 더 중요해지면 요구 사항 프로세스 자체에 더 많이 참여할 수 있습니다. 일부 요구 사항 수집 세션이 개발 옹호자가 참석해야 하는 핵심이라고 생각하는 경우 회의에서 자신의 역할과 옹호자가 가질 수 있는 잠재적인 우려 사항을 포착하는 방법에 대해 사전에 두 사람이 동일한 페이지에 있는지 확인하십시오. 나중에 개발 옹호자와 검토하기 위해 이러한 종류의 세션을 녹음할 수도 있습니다. 디자인 작업에 몰두할 때 직접 필요할 수도 있습니다! 정보 수집 중 이러한 종류의 명확한 의사 소통 및 후속 조치는 팀 구성원 간의 강력한 관계를 구축하는 데 필수적이며, 이는 나중에 프로세스에서 우선 순위 지정 단계가 얼마나 원활하게 진행되는지에 큰 차이를 만들 수 있습니다. 그러나 때로는 최선의 노력에도 불구하고 요구 사항의 우선 순위를 지정하려고 할 때 충돌이 발생합니다. 프로젝트 팀이 이 갈등을 관리하도록 도울 수 있는 방법에 대해 이야기해 봅시다.

우선순위 지정 중 갈등 관리 의견이 일치하지 않는 영역이 큰 경우 우선순위 지정은 긴 프로세스가 될 수 있습니다. 이러한 불일치가 해결되지 않으면 설계 및 개발 중에 계속해서 표면화될 것입니다. 이러한 충돌에는 다양한 근본 원인이 있을 수 있습니다. 다음은 가장 일반적인 것 중 일부입니다.

158

9장: 전환: 정의에서 설계로

팀이 프로젝트 목표에 대해 의견이 일치하지 않거나

거짓 비즈니스 전략(오해, 잊음 또는 동의하지 않음). 상대 팀 구성원은 특정 기능 세트와 밀접하게 연결되어 있습니다.

(기능이 그들을 흥분시키거나 영향력 있는 고객 또는 이해 관계자에게 약속했을 수도 있습니다.) 비즈니스 요구사항과 사용자 요구사항 사이에 충돌이 있습니다.

쉽게 해결. 사용되는 기술은 개발 팀에 비교적 새로운 것입니다.

그래서 그들은 추정하기가 불편합니다. 위의 몇 가지 상황을 살펴보고 사용자 경험 디자이너로서 이러한 문제를 해결하는 데 참여할 수 있는 방법에 대해 논의해 보겠습니다.

전투 선택 우선 순위를 지정하는 동안 좋아하는 기능 중 일부가 도마 위에 있을 수 있습니다. 특히 사용자 요구 사항이 목록에서 가장 자주 삭제되는 것처럼 보이는 경우 이에 대해 불만을 느끼기 쉽습니다. 모든 요구 사항을 동등하게 열정적으로 옹호하면 우선 순위 결정을 내릴 위험이 있습니다. 다음은 특정 요구 사항을 추진할 시기와 타협할 시기를 결정할 때 스스로에게 물어봐야 할 몇 가지 질문입니다. 요구 사항이 프로젝트 목표를 어떻게 지원합니까? 특정 위험을 현저하게 감소시키는가? 예를 들어 사용자의 스팸 노출을 줄여 사이트에 대한 부정적인 의견을 줄입니까? 다른 제안된 사이트 요구 사항이 제대로 작동하려면 이 요구 사항에 의존합니까? 기능이 포함되지 않으면 어떤 영향이 있습니까? 기능의 가치가 그것을 개발하는 데 필요한 노력의 가치가 있습니까(당신이 소중하게 여기는 다른 기능을 희생하더라도)? 이 모든 항목에 대한 강력한 답변이 있는 경우 우선 순위 테이블로 가져와 귀하의 입장을 밝히십시오. 그렇지 않다면 포기하는 것을 고려하되, 다른 사람들이 당신이 프로젝트의 전반적인 이익을 위해 타협하고 있음을 알 수 있도록 이유를 공유해야 합니다. 이를 통해 더 큰 비즈니스 컨텍스트를 고려하고 향후 토론 및 변경 요청의 우선 순위를 정하는 데 참여하는 능력을 입증할 수 있습니다.

좋은 긴장을 유지하십시오

159

프로젝트 방향에 대한 조정 부족 팀은 프로젝트 목표 또는 기본 비즈니스 전략에 대해 같은 페이지에 있지 않습니다. 이 갈등의 원인을 커뮤니케이션과 합의라는 두 영역으로 분리해 봅시다. 프로젝트 목표나 비즈니스 전략의 커뮤니케이션이 문제라면 개인적으로 어떻게 커뮤니케이션을 개선할 수 있는지 자문해 보십시오. 모든 팀 구성원이 볼 수 있는 목표 또는 전략을 게시하는 문제입니까(예: 상황실, 온라인 협업 영역 또는 모든 회의 안건의 맨 위)? 또는 필요한 것은 팀에 초점을 맞추고 팀 구성원이 작업 중인 비전에 대해 흥미를 갖도록 하는 데 도움이 되는 목표 또는 전략을 시각적으로 표현하는 것입니다. 이 장의 시작 부분에서 논의한 시각화 기술을 기억하십니까? 이를 사용하여 쉽게 인쇄 및 게시할 수 있는 이미지를 만들거나 대화에 집중할 수 있도록 화이트보드에 빠르게 스케치할 수 있습니다. 합의가 문제라면 모든 사람을 하나로 모으는 데 어떻게 도움이 될 수 있는지 스스로에게 물어보십시오. 사용자에게 매우 다른 기능 집합을 릴리스하는 것과 관련된 위험에 대한 불안으로 인해 충돌이 발생합니까? 설문 조사, 인터뷰 또는 상황에 따른 질문(6장 참조)과 같은 일부 의견 불일치를 해결하는 데 도움이 되도록 수행할 수 있는 조사가 있을 수 있습니다. 또는 불일치에 대한 구조화된 토론을 유지하고 문제가 해결될 때까지 문제를 하나씩 해결함으로써 촉진 기술을 발휘할 수 있습니다. 좋아하는 기능에 대한 충돌 상대 팀 구성원은 자신의 기능 집합에 연결됩니다. 교육 부서의 책임자가 통합된 주제 기반 자습서를 원하고 영업 책임자가 흥미로운 데모를 보내 관심을 불러일으키기를 원한다고 가정해 보십시오. 한편, 다양한 역할을 맡은 다른 10명의 비즈니스 이해 관계자가 있으며 모두 긴급한 요구 사항이 있습니다. 합의를 도출하는 데 어떻게 도움이 됩니까? 한 가지 방법은 6장: 친화도 다이어그램에서 읽은 방법의 변형을 적용하는 것입니다. 이 방법에서는 기존 요구 사항 집합에서 작업하거나 이해 관계자가 자체 요구 사항을 브레인스토밍하도록 할 수 있습니다(아직 요구 사항 수집 프로세스 초기인 경우 특히 유용함). 기존 요구 사항에서 작업하는 경우 다음에서 인쇄할 수 있습니다.

160

9장: 전환: 정의에서 설계로

개별 페이지를 모두 벽에 테이프로 붙입니다. 그렇지 않으면 이해 관계자에게 포스트잇에 가장 먼저 떠오르는 요구 사항을 작성하도록 요청하십시오. 필요한 것: 이해관계자 그룹이 이동할 수 있을 만큼 충분히 큰 방과

붙일 수 있는 하나 이상의 큰 빈 벽이 있는 포스트잇 메모 각 이해 관계자당 적어도 하나의 큰 포스트잇 메모지 스티커 도트(사무용품점에서 찾을 수 있으며 다양하게 제공됩니다.

다양한 색상), 이해관계자당 10개의 점 한 세트 주요 이해관계자를 한 방에 모아 각자에게 시간을 내어 주요 요구 사항을 메모에 하나씩 기록하도록 요청합니다. 15분에서 20분 정도 시간을 주십시오. (엿보기 금지!) 모든 사람에게 요구 사항을 벽에 붙이도록 요청하십시오. 그런 다음 각 사람에게 걸어가서 게시한 내용을 설명하도록 요청합니다. 방을 돌아다니면서 유사한 요구 사항을 함께 그룹화하기 시작합니다(이해 관계자가 유사하다고 동의하는 경우). 요구 사항을 설명하고 그룹화한 후 스티커 점을 나눠줍니다. 이해 관계자에게 포스트잇에 점을 할당하여 가장 우선 순위가 높은 요구 사항을 표시할 수 있다고 말합니다. 예를 들어 중요하다고 생각되는 경우 하나의 요구 사항에 10개의 점을 모두 표시하도록 선택하거나 10개의 다른 요구 사항에 점을 표시하도록 선택할 수 있습니다. 사람들이 점을 찍을 때 명확한 즐겨찾기가 표시되기 시작할 것입니다. 점 배치가 완료되면 결과를 함께 살펴봅니다. 이러한 방식을 선택해야 할 때 이해 관계자는 내부 우선 순위를 제시하고 대화가 훨씬 쉬워질 것입니다.

서핑 우선 순위 지정에 사용되는 이 기술의 변형에 대한 자세한 내용은 Jared M. Spool의 "The KJ-Technique: A Group Process for Establishing Priorities" 기사(www.uie.com/articles/kj_technique)를 참조하십시오.

좋은 긴장을 유지하십시오

161

이러한 종류의 기술은 우선 순위 지정 프로세스를 바로 시작하거나 불일치로 인해 중단된 프로세스를 재설정하는 데 도움이 될 수 있습니다. 모멘텀과 공통된 이해를 달성하면 우선 순위 문서(예: 그림 9.3에서 본 문서)를 완료하는 것이 훨씬 쉬워질 것입니다. 우선 순위 지정 활동과 병행하여 곧 뒤따를 전체 설계 작업을 준비해야 합니다. 작업 계획을 세우면 세부적인 디자인을 만드는 데 필요한 노력을 예측하고, 프로젝트 팀의 다른 사람들과 작업을 통합하고, 프로젝트 이정표에 맞추기 위한 노력을 조정하는 데 도움이 됩니다. 다음 섹션에서는 계획하는 데 도움이 되는 몇 가지 고려 사항을 다룹니다.

활동 및 문서화 계획 우선 순위가 지정된 요구 사항 목록이 있고 이상적으로는 일부 초기 개념 작업이 완료되면(예: 이 장 앞부분에서 설명한 스토리보드) 프로젝트 관리자가 진행 중인 작업에 대한 세부 정보를 묻기 시작할 것입니다. 당신이 디자인하는 대로 하기 위하여. 여러 유형의 디자인 활동이 있으며 각각 디자인 방법, 소요 시간 및 최종 문서 유형에 다른 영향을 미칩니다. 이것은 일반적인 의미에서 "문서"입니다. 화이트보드 스케치에서 와이어프레임, 프로토타입에 이르기까지 다양할 수 있습니다. 다음 세 장에서 몇 가지 인터랙션 디자인 활동을 다룰 것입니다. 사용할 활동을 계획할 때 다음 질문을 염두에 두십시오. 전체 프로세스가 얼마나 반복적입니까? 이상적으로는 다음과 같이 시작할 수 있습니다.

몇 가지 다른 개념을 빠르게 탐색(예: 스케치를 통해)한 다음 하나에 동의하여 더 자세히 개발합니다. 이 접근 방식에는 사용자에게 하나 이상의 설계 개념을 적용하는 것도 포함될 수 있습니다(설계 테스트에 대한 자세한 내용은 13장 참조). 디자인하는 동안 협업은 어떻게 이루어지나요? 밀접하게 작업하는 경우

같은 위치에 있는 팀과 함께 더 많은 협업 화이트보드 세션을 포함할 수 있습니다. 팀이 분산되어 있는 경우 거리에도 불구하고 높은 수준의 공동 작업이 가능한 도구를 사용하는 웹 회의 세션을 고려하십시오.

162

9장: 전환: 정의에서 설계로

더 큰 팀과 디자인 문서를 어떻게 공유할 예정입니까? ~이다

소규모 팀에 이메일로 보내거나 온라인 공동 작업 사이트에 게시합니까? 크기 제한 및 버전 추적 프로세스 측면에서 이는 무엇을 의미합니까? 나중에 개발 단계에서 설계에 얼마나 많은 세부 정보를 포함해야 합니까?

프로세스? 문서가 공식적인 품질 보증(QA) 프로세스의 일부인 경우 초기에 QA 팀의 누군가를 참여시켜 어떤 종류의 세부 정보를 받게 되는지 이해하도록 해야 합니다. 문서가 "활성화"되는 데 필요한 기간은 얼마입니까? 복잡한 프로젝트로,

와이어프레임 세트와 같은 문서 업데이트를 중지하는 순간 "죽기" 시작합니다. 세부 사항은 시간이 지남에 따라 더욱 부정확해집니다. (이러한 변경 사항에 대한 논의에 참여하는 한 이것이 항상 나쁜 것은 아닙니다.) 브랜드 가이드라인 문서 또는 인터랙션 디자인 패턴 라이브러리와 같이 일반적인 지침을 제공하는 데 중점을 둔 문서는 다음과 같은 경향이 있습니다. 더 오래 산다. 각 문서 유형의 주요 사용자는 누구입니까? 이 답변

프로젝트의 다른 지점에서 다를 수 있습니다. 개념 설계 문서의 기본 사용자는 일반적으로 아이디어를 전달하고 소셜화하는 데 사용하는 비즈니스 이해 관계자와 설계 팀입니다. 세부 설계 문서는 주로 설계를 구현해야 하는 개발자를 위한 것입니다. 이러한 문서는 구체적인 지침을 제공합니다. 어떤 다른 유형의 문서와 일치해야 합니까? 당신은

위에서 생성한 기능의 우선 순위 목록과 생성한 디자인 사이에 일종의 연결 고리를 제공해야 합니다. 모든 사람이 같은 페이지에 있는지 확인하기 위해 다른 여러 종류의 문서도 주시해야 할 수 있습니다. 이러한 문서에는 브랜드 가이드라인, 콘텐츠 개발 계획, 기능 사양 또는 사용 사례가 포함될 수 있습니다(다양한 역할에 대한 개요와 그들이 생성할 수 있는 문서 유형에 대해서는 2장 참조). 각 문서 유형에 필요한 노력을 어떻게 예측할 수 있습니까? 이것

프로젝트에는 시간에 영향을 줄 수 있는 변수가 많기 때문에 까다롭습니다. 그러나 대략적인 추정을 위한 기준선을 설정하면 시작할 위치가 생기고 더 많은 정보를 얻을 때 수치를 검증할 수 있습니다. 예를 들어 각 세부 와이어프레임을 만드는 데 약 6시간이 걸린다는 기준 추정치를 설정할 수 있습니다. 특정 기능을 추정하는 경우

활동 및 문서화 계획

163

예를 들어, 이 장의 앞부분에서 설명한 스토리보드 세션의 결과에 따라 약 5페이지가 필요하므로 해당 기능에 대한 초기 예상 시간은 30시간입니다. 와이어프레임당 8페이지를 차지하게 되면 그 이유를 알아내십시오. 계속될 것이라고 생각되는 경우 추정치를 수정하고 가능하면 우선순위를 다시 지정해야 합니다. 문서의 시기에 영향을 미치는 추가 요소는 무엇입니까? 총

시간에는 팀 및 이해 관계자와 함께 검토하는 시간과 필요하다고 생각되는 수정 횟수에 대한 시간이 포함됩니다. 세부 사이트의 경우 세부 기능 요구 사항(예: 사용 사례)과 같은 다른 문서와 디자인 문서를 조정하는 데 필요한 시간도 포함될 수 있습니다. 나중에 확인할 수 있도록 이러한 가정을 직접 적어 두십시오. 여러 디자이너와 함께 작업할 예정인가요? 있다면 어떻습니까?

일을 나눌 것인가? 병렬이지만 별개의 사이트 영역에서 작업하는 경우 생성한 문서에서 상당히 독립적으로 작업할 수 있습니다. 매우 상호 의존적인 방식으로 작업을 분할하는 경우 디자인을 조정할 시간을 계획해야 하며 문서에서 서로 다른 버전을 추적하고 병합할 방법이 필요할 수도 있습니다. 초기에 프로세스를 실행하여 나중에 큰 골칫거리를 피하고 탐색과 같은 핵심 요소에 대해 같은 페이지에 있도록 초기에 몇 가지 디자인 지침을 설정하십시오. 디자인 활동을 선택할 때 고려해야 할 몇 가지 사항에 대해 이야기했으므로 이제 해당 활동을 살펴보겠습니다. 다음 세 장에서는 사이트 맵, 작업 흐름, 스케치, 와이어프레임 및 프로토타입을 비롯한 다양한 문서에 대해 설명합니다.

164

9장: 전환: 정의에서 설계로

사이트 맵 및 작업 흐름 여기에서 저기로 그리고 다시 뒤로 프로젝트 구조화 사이트 맵은 웹 사이트 및 응용 프로그램의 구조를 식별하는 데 도움이 됩니다. 청중이 사용자가 콘텐츠를 찾을 수 있는 위치를 이해할 수 있도록 계층 구조와 연결을 표시할 수 있습니다. 작업 흐름은 사용자가 사이트 섹션 내에서 이동할 수 있는 다양한 작업 과정을 식별하여 사이트 맵을 한 단계 더 발전시킵니다. 작업 흐름은 또한 프로세스 전체의 결정 지점을 기반으로 오류 상태, 콘텐츠 또는 페이지 보기에 대한 연결을 그립니다. 사이트 맵과 작업 흐름을 함께 사용하면 콘텐츠 구조와 사용자가 탐색하는 방법에 대한 명확한 그림을 청중에게 제공할 수 있습니다. 러스 웅거

165

사이트 맵이란 무엇입니까? 1.0

1.0.1 이용약관

홈페이지

2.0 – 2.x

3.0

블로그

4.0

에 대한

5.0

일하다

연락하다

그림 10.1 블로그 기능이 있는 기본 웹 사이트의 사이트 맵

가장 기본적인 정의부터 시작하여 사이트 맵은 단순히 웹 사이트의 대표 페이지를 표시하는 시각적 방법입니다(그림 10.1). 간단한 사이트 맵은 일반적으로 종이 한 장에 맞으며 고용주의 조직도와 유사합니다. 그러나 사이트 맵은 웹 사이트만을 위한 것이 아닙니다. 페이지, 보기, 상태 및 표시되는 인스턴스를 식별하는 데 도움이 되는 모든 유형의 응용 프로그램에 사용할 수 있습니다. 대부분의 경우 사이트 맵을 사용하여 팀원과 고객에게 웹 사이트의 콘텐츠 구성 방법을 보여줍니다. 웹 사이트 탐색에 대한 개요를 제공하고 경우에 따라 각 페이지가 가질 수 있는 모든 연결을 표시합니다.

작업 흐름이란 무엇입니까? 그림 10.2 로그인 상태에 따른 사용자 경로를 보여주는 기본 작업 흐름

홈페이지

사용자가 로그인되어 있습니까? 로그인하지 않은 페이지

아니요

예

로그인 페이지

작업 흐름은 사용자(및 경우에 따라 시스템)가 웹 사이트 또는 응용 프로그램을 진행하면서 취하는 경로 또는 프로세스를 식별합니다(그림 10.2). 사이트 맵과 작업 흐름이 처음에는 비슷해 보일 수 있지만 두 가지 유형의 다이어그램은 다른 용도로 사용됩니다. 사이트 맵은 사이트 또는 응용 프로그램 레이아웃의 시각적 계층 구조를 알려주고 작업 흐름은 사용자 옵션 및 경로에 대한 세부 정보를 제공합니다. 그들은 취할 수 있을 것입니다. 166

10장: 사이트 맵 및 작업 흐름

거래 도구 사용자 경험 디자인 분야에서 이제 막 시작했고 작업 제품 생성을 시작하기 위한 도구가 필요한 경우 다음과 같은 다양한 옵션이 있습니다. Microsoft Visio(http://office.microsoft.com/visio) Axure RP Pro (www.axure.com) OmniGraffle(www.omnigroup.com/applications/OmniGraffle) Adobe InDesign(www.adobe.com/products/indesign) Adobe Illustrator(www.adobe.com/products/illustrator) Microsoft PowerPoint(http: //office.microsoft.com/powerpoint) OpenOffice Draw(www.openoffice.org) HTML Blueprint CSS(www.blueprintcss.org)

어떻게 선택합니까? 다른 디자이너에게 물어볼 수 있습니다. 모두가 좋아하는 것을 가지고 있으며 일반적으로 기꺼이 이름을 지정합니다. 그들이 당신의 저자처럼 "좋은 연필과 종이"라고 대답하더라도 놀라지 마십시오. 또한 무료 평가판을 온라인으로 테스트하거나 OpenOffice.org 도구 제품군의 일부이며 인기 있는 오피스 제품군과 동일한 형식을 출력하는 OpenOffice Draw와 같은 무료 솔루션을 선택할 수 있습니다. 연필과 종이 외에 우리는 무엇을 사용합니까? 이 책의 많은 예제는 Blue Flavor(www.blueflavor.com)의 사용자 경험 책임자이자 Digital Web Magazine(www.digital-web.com)의 발행인인 Nick Finck가 만든 스텐실을 사용하여 Microsoft Visio 2003에서 생성되었습니다. . www.nickfinck.com/stencils.html에서 Nick의 뛰어난 스텐실을 다운로드할 수 있습니다. 이러한 미리 만들어진 스텐실, 모양 및 샘플은 신규 및 숙련된 실무자 모두에게 매우 중요합니다. Nick's 외에도 Learning IA 페이지(http://iainstitute.org/en/learn/tools.php)에서 이러한 도구를 많이 제공하는 Information Architecture Institute의 제안을 확인하십시오. 참고 Microsoft는 현재 2007 버전의 Visio를 제공합니다. 그러나 많은 회사에서 아직 제품으로 업그레이드하지 않았으며 버전 차이를 처리하지 않기 위해 현재 Microsoft Visio 2003을 권장합니다.

거래 도구

167

사용하기로 결정한 도구가 무엇이든 기꺼이 공유하고 경력에 도움이 되는 다른 전문가의 온라인 사례가 무수히 많습니다. 이들은 대부분 무료이며 최소한 최소한으로 매우 전문적으로 보이는 문서를 작성하는 데 필요한 프레임워크를 제공할 수 있습니다. 불행히도 많은 사람들이 이러한 리소스를 활용하지 않습니다. 그런 사람들처럼 되지 마!

사이트 맵 및 작업 흐름의 기본 요소 드로잉 프로그램 내에서 가장 기본적인 요소는 사이트 맵 및 작업 흐름 만들기를 시작하기에 충분합니다. 그러나 많은 사람들이 창작물을 쉽게 해석할 수 있도록 하려면 표준 도형 세트를 사용하는 것이 가장 좋습니다. Visual Vocabulary for Information Architecture는 그러한 표준 중 하나이며 이 책에서 사용된 것입니다. Adaptive Path(www.adaptivepath.com)의 창립자 중 한 명인 Jesse James Garrett이 만들었으며 www.jjg.net/ia/visvocab에서 온라인으로 사용할 수 있습니다. 이 사이트는 사이트 맵과 작업 흐름을 명확하게 설명하는 데 도움이 되는 많은 요소를 제공하며, 이 모든 요소는 자세한 설명과 함께 사용할 수 있으며 널리 사용되는 드로잉 및 스케치 프로그램의 다운로드 가능한 스텐실로 제공됩니다(자세한 내용은 잠시 후). 시작하고 기본 사항에 익숙해지는 데 도움이 되도록 다음 섹션에서는 Visual Vocabulary의 핵심 요소 세트와 이들이 나타내는 내용을 살펴봅니다. 그림 10.3 Jesse James Garrett의 Visual Vocabulary의 페이지 요소

그림 10.4 Jesse James Garrett의 Visual Vocabulary의 Pagestack 요소

페이지 Jesse James Garrett에 따르면 페이지는 "웹 사용자 경험의 기본 단위"입니다. 콘텐츠의 "인스턴스" 또는 "보기"는 오늘날 더 현실적일 수 있지만 페이지는 여전히 매우 의미가 있습니다. 이러한 페이지를 그리는 방법에는 여러 가지가 있지만 가장 간단하고 가장 일반적으로 사용되는 형식은 일반

168

10장: 사이트 맵 및 작업 흐름

직사각형(그림 10.3). 사이트 맵 및 작업 흐름 생성을 진행하면서 페이지에 레이블을 지정하고 번호를 매기는 데 가장 적합한 스타일을 찾고 싶을 것입니다.

페이지 스택 페이지 스택은 유사한 콘텐츠의 여러 페이지를 나타냅니다(그림 10.4). 페이지 스택을 이해하는 쉬운 방법은 게시 시스템을 사용하여 만든 일반적인 블로그 페이지와 같은 동적 콘텐츠를 생각하는 것입니다. 이러한 페이지는 한 번 디자인되고 디자인 템플릿에 있지만 실제로 원본 템플릿 디자인을 떠나지 않고도 다양한 콘텐츠 페이지를 클릭할 수 있습니다.

결정 포인트 그림 10.5 Jesse James Garrett의 Visual Vocabulary의 결정 포인트 요소

로그인

(10a)

오류

멤버 홈

결정 지점은 질문에 대한 답변에 따라 사용자가 취할 수 있는 경로를 표시하는 데 사용됩니다(그림 10.5). 결정 지점(10a)은 "사용자의 로그인 자격 증명이 정확합니까?"일 수 있습니다. 해당 질문에 대한 답변에 따라 표시될 페이지(또는 컨텐츠 보기)가 결정됩니다. 로그인에 실패하면 오류 메시지가 표시되고 로그인에 성공하면 사이트 구성원의 홈 페이지로 이동합니다. 결정 지점에 적절하게 레이블을 지정하는 데 시간을 할애하십시오. 특히 팀원이나 클라이언트와 작업 제품을 공유할 때 기뻐할 것입니다.

사이트 맵 및 작업 흐름의 기본 요소

169

연결선과 화살표 그림 10.6 Jesse James Garrett의 Visual Vocabulary에 있는 연결선과 화살표 요소

커넥터와 화살표는 페이지, 페이지 스택, 결정 지점 등 사이의 이동이나 진행 상황을 표시하는 데 사용됩니다. 커넥터는 일반적으로 한 페이지에서 다른 페이지로의 클릭 유도문안이 있는 곳에 나타납니다. 예를 들어 홈 페이지의 About Us 페이지에 대한 링크는 두 페이지 사이의 커넥터가 될 수 있습니다. 화살표(그림 10.6 상단)는 작업 완료를 향한 "다운스트림" 이동을 나타냅니다. 크로스바가 있는 커넥터(그림 10.6의 하단)는 원래 페이지로 다시 이동("업스트림" 이동)할 수 없는 경우를 식별하는 데 사용할 수 있습니다. 예를 들어, 사용자가 웹 사이트에 로그인하면 홈 페이지 콘텐츠가 이제 사용자에 맞게 개인화될 수 있으며 일반 페이지 또는 로그인 페이지는 사용자가 방금 방문한 경로에서 더 이상 사용할 수 없습니다. 뒤따랐다.

조건 A

비

그림 10.7 Jesse James Garrett의 Visual Vocabulary의 조건 요소

파선은 조건을 표시하는 매우 일반적인 방법입니다. 사이트 맵, 작업 흐름 및 귀하가 만들거나 발명할 수 있는 기타 작업 제품에 나타날 수 있습니다. 점선을 연결선(그림 10.7 참조)으로 사용하거나 영역 주변의 상자로 사용하여 페이지 또는 전체 페이지 섹션에 대한 연결이 다른 작업이나 이벤트에 따라 조건부임을 강조할 수 있습니다.

(Video) 사용성 테스트 보고서 작성 방법 [무료 템플릿 받기]

170

10장: 사이트 맵 및 작업 흐름

흔한 실수 당신은 턱에 땅콩 버터 덩어리를 바르거나 커피로 얼룩진 셔츠를 입고 프레젠테이션에 들어가지 않을 것입니다. 그러한 실수는 당신의 모든 노력을 약화시킬 뿐만 아니라 좋은 프로젝트를 시작하지 못하게 할 수도 있습니다. 엉성한 사이트 맵이나 전문적이지 않아 보이는 작업 흐름도 피해를 줄 수 있습니다. 큰 결과를 초래하는 이러한 작은 실수를 인식하는 데 도움이 되도록 다음 섹션에서는 몇 가지 잘못된 설계를 자세히 살펴봅니다. 이러한 일반적인 실수를 발견하고 피하는 방법을 배우십시오.

엉성한 연결 그림 10.8 두 페이지 간의 누락된 연결

조잡한 연결은 바로 조잡합니다. 그들은 심하게 그려져 있습니다. 그것들은 매우 아마추어적으로 보이며, 적어도 작가인 당신의 작품의 세부 사항에 많은 주의를 기울이지 않는 것처럼 보입니다. 대부분의 도구에는 라인을 상자에 연결하는 데 도움이 되는 몇 가지 방법이 있습니다. 그것을 활용하십시오. 시간 제약과 압박감에 관계없이 게을러지지 마십시오. 대부분의 응용 프로그램에서 Shift 키와 기타 키를 함께 사용하면 시작점에서 45도씩 요소를 드래그할 수 있습니다. 이 내장 기능을 활용하고 연결이 잘 연결되어 있는지 확인하십시오. 연필 스케치를 보여주고 있다면 만일을 대비해 지우개를 준비해야 합니다. 그것을 규칙으로 삼으십시오: 항상 다른 물체에 닿는 선이 정확하게 연결되어 있는지 확인하십시오.

흔한 실수

171

잘못 정렬되고 고르지 않은 간격의 개체

그림 10.9 정렬되지 않고 간격이 고르지 않은 페이지

사용 중인 도구에 따라 개체가 사이트 맵 또는 작업 흐름에서 정확하게 정렬되거나 균등한 간격으로 떨어져 있는지 확인하기 어려울 수 있습니다. 이 기본 규칙을 확실하게 하는 몇 가지 매우 간단한 방법이 있습니다. 우선 사용 중인 애플리케이션에서 그리드를 켭니다. 이렇게 하면 도구가 개체를 고르게 배치하고 적절하게 정렬하는 옵션을 제공하는지 여부에 관계없이 항상 개체 사이의 격자 수를 셀 수 있습니다. 다행히도 연필과 종이를 사용할 때 모눈종이를 사용하여 동일한 기본 원리를 적용할 수 있습니다. 문서를 전문적으로 보이게 만드는 것은 매우 쉽습니다. 불행하게도 작업의 품질에 대해 정말로 신경 쓰지 않는 것처럼 문서를 보이게 만드는 것도 쉽습니다.

잘못 배치된 텍스트 그림 10.10 일관되지 않게 배치된 텍스트

1단계 2단계

부주의한 텍스트 배치(그림 10.10에서와 같이)는 피하는 것이 간단해 보이지만 또 다른 일반적인 실수입니다. 만든 모양에 텍스트를 잘 맞추는 방법을 찾고 요소 외부에 배치된 레이블이 적절하게 연결되어 있는지 확인하십시오(그림 10.11). 1.0 홈페이지

172

1.0.1 이용약관

10장: 사이트 맵 및 작업 흐름

그림 10.11 잘 배치된 텍스트

기본적인 것처럼 보일 수 있지만 적절한 글꼴 크기 및 사용법과 함께 텍스트를 적절하게 배치하면 문서를 더 쉽게 읽고 사용할 수 있습니다.

페이지 번호 매기기 부족 이제 다른 규칙을 설정할 때입니다. 만드는 모든 사이트 맵의 모든 페이지에 번호를 매깁니다. 그림 10.12와 같이 모호하고 숫자가 없는 지도를 만들지 마십시오. 이용약관

홈페이지

블로그

에 대한

정황

일하다

연락하다

그림 10.12 번호 구조가 없는 사이트 맵

사이트 맵에서 식별하는 모든 페이지에는 번호가 지정되어야 하며 번호 지정 시스템은 프로젝트의 새 반복 및 버전이 생성될 때 발생하는 다운스트림 변경을 허용해야 합니다. 페이지 번호 매기기에 다양한 방법을 사용할 수 있습니다. 가장 일반적인 방법은 홈페이지를 1.0 또는 0.0.0.0으로 식별하는 것입니다(그림 10.13). 시간이 지남에 따라 이 중 어떤 것이 가장 적합한지 결정할 수 있지만 편안해지고 두 접근 방식의 장단점을 이해할 때까지 홈 페이지를 1.0으로 식별하는 것부터 시작하십시오. 이 방법을 사용하면 Flash 프리로더, 로그인 또는 등록 화면 또는 기타 여러 페이지 유형과 같이 홈 페이지 이전에 발생할 수 있는 결정 및 페이지를 0.X로 설명할 수 있습니다. 사이트 맵의 번호 매기기 시스템을 통해 다른 문서와 동기화할 수 있습니다. 번호 지정 시스템은 콘텐츠 매트릭스와 같은 다른 문서로 확산될 수 있습니다. 콘텐츠 제작자는 사본 및 기타 콘텐츠를 다음과 같이 매핑할 수 있습니다.

특정 페이지(및 와이어프레임의 특정 요소, 나중에 자세히 설명). 작업 흐름. 작업 흐름은 동일한 번호 지정 시스템을 사용하여 작업 방법을 표시할 수 있습니다.

사용자는 특정 작업의 페이지를 통해 진행합니다. 와이어프레임(11장 참조). 와이어프레임의 페이지는 공유해야 합니다.

두 문서 간의 명확한 연결을 제공하기 위해 사이트 맵의 페이지와 동일한 번호 매기기 시스템입니다.

흔한 실수

173

시각 디자인. 비주얼 디자이너는 디자인 페이지와 요소를 다음과 동기화할 수 있습니다.

사이트 맵의 특정 페이지. 이를 통해 디자인을 개발자에게 전달해야 할 때 재고를 분류할 수 있습니다. 품질 보증 문서. 품질 보증 팀은 테스트를 작성할 수 있습니다.

사이트 맵의 특정 페이지 또는 페이지 전용 스크립트입니다. 이 시점에서 세부 사항과 구조에 주의를 기울이면 프로젝트를 순조롭게 진행하는 모든 사람을 유지하고 작업을 위한 구조를 제공할 수 있습니다. 1.0

1.0.1 이용약관

홈페이지

2.0 – 2.x 블로그

3.0 정보

4.0 작업

5.0 연락처

그림 10.13 요소가 정렬되고 간격이 균등하며 적절하게 번호가 지정된 페이지를 올바르게 연결하는 사이트 맵

요컨대, 사이트 맵의 페이지에 번호를 매기면 다른 모든 사람의 삶이 더 쉬워질 것입니다. 즉, 여러분의 삶도 더 쉬워질 것입니다.

간단한 사이트 맵 페이지 번호를 포함하는 것 외에도 그림 10.13은 제한된 동적 기능과 대부분 정적인 특성을 가진 기본 웹 사이트의 맵을 만들기 위한 좋은 모델입니다. 이 웹 사이트에 대해 확인된 페이지는 다음과 같습니다. 홈 블로그 정보 작업 샘플 연락처

보시다시피 이 간단한 사이트 맵은 시각적 어휘의 핵심 요소를 통합하고 전문적인 스타일과 모양을 유지합니다. 가장 중요한 것은 웹 사이트 사용자가 사용할 수 있는 탐색, 페이지 및 조건에 대한 매우 명확한 그림을 제공한다는 것입니다.

174

10장: 사이트 맵 및 작업 흐름

고급 사이트 맵 간단한 사이트 맵은 일반적으로 종이 한 장에 들어갈 수 있으며 대개 고용주의 조직도와 비슷합니다. 그러나 고급 사이트 맵은 여러 페이지로 확장될 수 있습니다. 1.0 Lorem Ipsum Dolor 홈페이지

고통을 아주 좋게하자

2008년 2월 9일

페이지 3/9

그림 10.14 고급 사이트 맵 홈 페이지 보기

고급 사이트 맵이나 더 큰 규모의 웹 사이트 및 응용 프로그램을 만들 때 첫 번째 페이지를 사용하여 사이트의 홈 페이지에 도달하는 데 필요한 단계를 식별하는 것이 한 가지 방법입니다. (맞습니다. 고급 사이트 맵의 일부로 작업 흐름을 사용하는 것이 좋습니다.) 또한 모든 최상위 페이지, 전역 탐색 요소 및 바닥글 요소를 식별해야 합니다. 이를 통해 사이트에 대한 매우 높은 수준의 개요를 미리 보여주고 팀과 고객에게 프로젝트에 대한 명확한 그림을 제공할 수 있습니다. 첫 번째 페이지는 사이트 맵을 읽는 데 도움이 되는 범례나 키를 포함하기에 적절한 위치이기도 합니다(그림 10.14 참조). 귀하의 팀과 고객은 하나가 필요합니다. 이 단계를 건너뛰지 마세요!

고급 사이트 맵

175

고통을 아주 좋게하자

2008년 2월 19일

페이지 4/9

그림 10.15 고급 사이트 맵 섹션 보기

첫 번째 페이지 이후에 생성하는 페이지는 기본적으로 해당 페이지에 다시 매핑되어야 합니다. 모든 최상위 페이지에는 웹 사이트나 응용 프로그램에 필요한 모든 페이지, 페이지 스택 및 외부 콘텐츠를 식별하는 페이지가 최소한 하나 이상 있어야 합니다(그림 10.15). 필요한 경우 하위 페이지를 함께 연결하는 것을 두려워하지 마십시오. 사이트 맵은 표준 크기의 종이 한 장보다 더 확장될 수 있습니다. 사이트 맵이 잘 구성되어 있고 청중을 위해 연결이 명확하게 문서화되어 있는 한 걱정할 필요가 없습니다. 이러한 예는 사이트 맵 생성의 세계에서 시작하기에 충분합니다. 다양한 프로젝트를 진행하면서 자신의 기술, 종종 팀 또는 클라이언트 요구 사항이 증가하고 있음을 알게 되면 사이트 맵을 제공하기 위해 취할 수 있는 접근 방식과 방법이 매우 다양하다는 것을 알게 될 것입니다.

176

10장: 사이트 맵 및 작업 흐름

사이트 맵 틀 깨기 이제 기본 작업을 수행하는 데 필요한 대부분의 요구 사항에 맞는 사이트 맵의 확실한 예를 보았습니다. 이러한 모델로 인해 더 나은 방법을 탐색하는 데 방해가 되지 않도록 하고 공유해 주세요! 다양한 접근 방식을 통해 기본 사이트 아키텍처 이상의 정보를 강조할 수 있습니다. 예를 들어 Vanguard의 수석 정보 설계자인 Andrew Hinton이 친절하게 제공한 그림 10.16의 사이트 맵을 고려하십시오. 새로운 연구 모니터링

구독하다

bc.org 지원

로그인

프로필 업데이트

비슷한 사람 찾기

"학문적" 관심사(의학, 학생, 일반)

기여하다

대화 Mtrls 인쇄 가져오기

bc.org에 대해 알아보기

새로운 관심사

위험 관리

걱정되는 사랑하는 사람

사회화하다

전문가 회의 참여학습

New Diag New Stage / 앉아.

그림 10.16 고급 사이트 맵. 앤드류 힌튼 제공.

이 사이트 맵은 웹 사이트의 다양한 페이지를 보여줄 뿐만 아니라 사용자 경로와 우선 순위에 대한 통찰력을 제공합니다. Andrew(www.inkblurt.com)는 Wolf Noeding의 창의적인 아이디어를 본 후 사이트 맵을 만들었다고 말합니다. Andrew는 이 사이트 맵을 사용하여 웹 사이트와 관련된 다양한 사용자 시나리오 및 정신 모델을 보여줍니다. 지도에서 더 큰 원은 추가 기능을 수행합니다. 가장 많은 트래픽을 받는 사이트의 최상위 영역을 강조 표시합니다. 모든 우수한 사용자 경험 실무자와 마찬가지로 Andrew는 빌렸지만 공로를 인정했습니다. 도구를 사용하고 작업 제품과 고객의 요구를 식별하는 데 더 익숙해짐에 따라 사이트 맵을 확장할 수 있는 방법은 무궁무진합니다. 당신이 그것을 찾는 곳에서 영감을 얻으십시오! 새로운 것을 시도하는 것을 두려워하지 말고 시간을 들여 유용하고 가치 있는 시간을 보내십시오.

사이트 맵 틀 깨기

177

작업 흐름 사이트 맵과 동일한 기본 요소를 많이 사용하는 작업 흐름은 사용자(때로는 시스템)가 웹 사이트나 응용 프로그램을 진행하면서 거치게 될 경로 또는 프로세스를 식별하는 다이어그램입니다. 다양한 방법으로 작업 흐름을 사용할 수 있습니다. 사이트 맵과 함께 사용하면 사용자가 특정 정보 세트가 표시된 페이지에 도달하는 방법을 보여줄 수 있습니다. 때때로 특정 사용자 유형(페르소나)이 웹 사이트를 어떻게 이동할 것으로 예상하고 해당 페르소나가 개인 정신 모델을 기반으로 무엇을 볼 것으로 예상하는지 보여주기 위해 사용됩니다. 또한 작업 흐름을 사용하여 프로젝트를 개발 팀에 보내기 전에 명확하게 이해해야 하는 복잡한 프로세스를 식별할 수 있습니다. 작업하는 모든 프로젝트에서 작업 흐름을 사용하지 않을 수 있으며 클라이언트에게 제시하는 작업 결과로 끝나지 않을 수도 있지만 항상 사용하는 것이 좋습니다. -자신의 이익을 위한 종이 형식. 약간의 명확성은 먼 길을 갈 수 있습니다. 작업 흐름을 생성하려면 사용자의 목표를 이해해야 합니다. 어떤 경우에는 요구 사항 문서를 받을 수 있고 다른 경우에는 사용 사례를 받을(또는 작성) 수 있습니다. 사용 사례는 작업과 목표를 요약하는 몇 개의 문장으로 구성되지만 사용자의 관점을 경험으로 통합할 수 있습니다. 그림 10.17의 시나리오에 대한 사용 사례는 다음과 같습니다. 시스템은 프로젝트 목록을 표시합니다. 사용자가 프로젝트를 선택합니다. 시스템은 쓰기 모드에서 기본 프로젝트 정보를 표시합니다. 사용자가 프로젝트 상태를 종료됨으로 변경합니다. 시스템이 보류 중인 작업을 확인합니다. 보류 중인 작업이 있으면 시스템에 오류 알림이 표시됩니다. 보류 중인 작업이 없는 경우…

178

10장: 사이트 맵 및 작업 흐름

시스템에서 보류 중인 지불을 확인합니다. 보류 중인 결제가 있는 경우 시스템에 오류 알림이 표시됩니다. 보류 중인 지불이 없는 경우… 시스템에 요약 페이지가 표시됩니다.

홈 [내 클레임 목록] 클레임 선택

정보 [쓰기 모드]

청구 상태 변경됨: 종료됨

대기 중인 작업?

예

오류 안내

아니요

[보류 중인 작업 및 요청 표시] 예

대기 중인 지불 요청?

아니요

정보 [읽기 전용 모드]

그림 10.17 이 작업 흐름은 시스템이 여러 조건에 대한 응답을 기반으로 사용자에게 정보를 표시하는 방법을 식별합니다.

그림의 작업 흐름은 사용 사례의 다양한 조건이 충족되는지 여부에 따라 사용자에게 표시되는 일련의 정보를 보여줍니다. 센터의 질문("대기 중인 작업?" 또는 "대기 중인 지불 요청?") 중 하나에 예라고 대답하면 시스템은 오류 알림을 표시하여 사용자가 앞으로 진행하기 전에 필요한 작업을 완료하는 데 도움이 되는 추가 정보를 제공할 수 있습니다. . 두 조건이 모두 아니오라고 대답하면 시스템은 성공을 식별하는 디스플레이를 사용자에게 제공합니다. 그림 10.18의 작업 흐름은 사용자가 여행 쇼핑 사이트를 통해 달력 응용 프로그램에서 선택할 수 있는 경로를 보여줍니다. 작업 흐름은 각 경로에 대한 세부 흐름이 사용자 요구 사항을 충족하는지 확인하기 위해 사용자가 테스트해야 하는 세 가지 매우 다른 경로를 식별한다는 점에서 매우 높은 수준입니다.

작업 흐름

179

캘린더 S100 캘린더 쇼핑 운임 찾기

S10 상세 운임 찾기

찾다

가격으로 검색(운임표 표시)

일정으로 찾기

유연한 날짜

select R20 검색 결과(가격 기준) - 여정 표시 - 검색 편집

P30 좌석 선택기

검토

R60 자유 날짜 검색 결과(가격별)

R10 검색 결과(일정별)세그먼트 표시 -검색 편집

P10 여정/승객 정보 검토 - 좌석 선택

구입

P20 결제 및 청구 정보

열쇠

페이지

여러 페이지

확인하다

P50 확인

결정 포인트 커넥터

조건부 커넥터

그림 10.18 구매 프로세스 단계를 통해 사용자의 경로를 설명하는 데 사용되는 작업 흐름

이 애플리케이션의 사용자는 여행 날짜를 입력한 다음 자신의 우선 순위에 따라 구매할 수 있습니다. 사용자는 여행을 검색할 날짜를 설정한 후 가격, 여행 날짜의 유연성 또는 여행 시간(일정)과 같이 자신에게 가장 중요한 것에 따라 검색 결과의 우선 순위를 지정할 수 있습니다. 작업 흐름은 테스트를 촉진하는 사람에게 지침을 제공하기 위해 사용자가 취할 수 있는 높은 수준의 경로를 식별합니다. 그룹화의 각 경로에 대해 자세한 작업 흐름을 만든 다음 개발 팀에 제공하여 테스트에 필요한 페이지를 만들 수 있습니다.

180

10장: 사이트 맵 및 작업 흐름

작업 흐름을 다음 단계로 끌어올리기 이 책의 모든 주제와 마찬가지로 여기에서 보고 있는 것이 작업 흐름 세계의 시작과 끝인 것처럼 느끼지 마십시오. 좋은 목적이 있는 한, 새로운 용도를 탐색하고 여기에 설명된 기본 사항의 사용을 최대한 확장하십시오. 작업 흐름을 생성하는 기술이 계속 성장함에 따라 좀 더 다채롭고 더 많은 옵션이 있으며 수정되거나 개선된 언어 규칙 등을 포함하는 작업 산출물을 생성하는 자신을 발견할 수 있습니다.

프로세스 흐름 그림 10.19는 Will Evans(www.semanticfoundry.com)가 한 단계 더 나아가 프로세스 흐름 다이어그램으로 전환한 작업 흐름을 보여줍니다. 그의 프로세스 흐름은 매우 높은 수준이고 유연하며 여기에서 프로젝트 프로세스의 여러 단계에서 프로젝트의 첫 번째 단계가 단일 단계인 것처럼 보이지만 이 특별한 경우에는 단계가 단일 이벤트로 구성되지 않음을 이해합니다. 대신, 이 경우 프로젝트의 첫 번째 단계는 실제로 다음과 같은 다양한 활동으로 구성됩니다. 사용자 조사 시장 조사 민족지학 및 상황별 조회 사용성 테스트 경쟁 분석 시장 분석 문화 분석 로그 파일 분석

작업 흐름을 다음 단계로 가져가기

181

그림 10.19 이 프로세스 흐름 다이어그램은 작업 흐름을 한 단계 더 발전시켜 복잡한 시나리오를 표현합니다. 윌 에반스의 의례.

이러한 각 활동에 대해 필요한 이해 관계자가 모여 범위, 우선 순위 및 날짜를 결정하는 프로젝트 시작 전에 다른 다양한 문서에 제공되는 보고서가 생성됩니다. 이 모든 것이 프로세스 흐름 다이어그램에 표시됩니다. 이 예에서 볼 수 있듯이 작업 흐름을 만드는 데 있어 하늘은 한계입니다. 위의 예를 보고 결과물을 다음 단계로 끌어올리는 방법을 고려하십시오. 약간의 연습이 필요할 수 있지만 약간의 기교만 있으면 고객을 놀라게 할 작업 흐름을 만들 수 있습니다!

Swimlanes James Melzer(www.jamesmelzer.com), SRA International Inc.(www.sra.com)의 수석 정보 설계자는 기본 작업 흐름을 훨씬 뛰어넘는 다양한 다이어그램을 만들었습니다. 그림 10.20의 다이어그램은 동시에 발생하는 많은 이벤트가 있는 프로세스에서 작업, 알림 등의 "스윔 레인"을 표시하도록 확장된 작업 흐름을 보여줍니다. 악몽이었다!

182

10장: 사이트 맵 및 작업 흐름

대신 James는 훨씬 더 이해하기 쉬운 형식으로 발생하는 모든 다양한 단계와 작업을 포함하도록 기본 작업 흐름을 확장하는 방법을 모색했습니다.

그림 10.20 이 스윔 레인 다이어그램은 여러 위치에서 여러 작업이 있는 복잡한 시나리오를 설명하기 위해 작업 흐름을 확장하는 예입니다. 제임스 멜저 제공.

James는 프로젝트와 스윔 레인을 다음과 같이 설명했습니다. 이 시스템을 통해 사람들은 자신이 소유한 건물에 대한 정보를 관리할 수 있습니다. 이 확장을 통해 빌딩 서비스 파트너는 고객을 대신하여 데이터 시스템 간 데이터를 제공하여 소유자가 입력해야 하는 데이터를 줄일 수 있습니다. 이 프로젝트는 데이터 서비스의 표시 및 운영을 구성하는 파트너, 파트너 데이터 서비스에 가입하고 사용하는 고객, 백엔드에서 지속적인 파트너 데이터 관리 및 문제 해결의 세 부분으로 구성되었습니다. 우리는 기존 시스템에 대대적인 확장을 계획하고 있었습니다. 우리는 거의 모든 서비스 시나리오에 여러 사용자와 여러 시스템이 관련되어 있다는 것을 일찍부터 알고 있었습니다. 많은 알림이 있었고 많은 프로세스가 비동기식이었습니다. 이 다이어그램은 프로젝트에 필요한 서비스 시나리오를 식별, 설계 및 설명하는 데 도움이 되었습니다. 이 작업 제품의 정식 버전에서는 실제로 이 다이어그램의 흐름 아래에 상세한 와이어프레임이 배열되어 있습니다. 전체가 벽을 덮었습니다. 일단 디자인 컨셉에 상당히 확신이 생기면 이를 좀 더 전통적인 다중 페이지 사양으로 잘랐습니다.

작업 흐름을 다음 단계로 가져가기

183

여기서 기억해야 할 중요한 점은 작업 흐름이나 사이트 맵 사용에 제한을 두지 않는 것입니다. 이 장에서 보여준 기본 사항의 경계를 넓히십시오. 자신의 기질을 시험할 무언가가 정말 필요한 경우 신발 끈 묶는 방법에 대한 작업 흐름을 만드는 데 시간을 할애하십시오. 행운을 빌어요!

184

10장: 사이트 맵 및 작업 흐름

와이어프레임 및 주석 디자인 및 방향 - 시각적 디자인을 시작하기 전에 와이어프레임 및 주석은 웹 페이지 또는 응용 프로그램 보기의 기능 동작뿐만 아니라 제안된 콘텐츠 및 구조를 식별하는 방법입니다. 사이트 맵 및 작업 흐름과 결합할 때 이러한 문서는 프로토타이핑 시나리오 및 개념 증명을 식별하는 데에도 매우 유용합니다. 와이어프레임은 일반적으로 그래픽 요소나 완성된 콘텐츠가 없는 회색조로 표시됩니다. 대신 시각적 디자인에서 지침으로 사용할 수 있는 대표적인 위치를 강조하기 위해 자리 표시자 콘텐츠를 사용합니다. 러스 웅거

와이어프레임이란 무엇입니까? 기본적으로 웹 페이지 또는 애플리케이션 화면의 저충실도 프로토타입인 와이어프레임은 페이지 또는 화면에 표시될 요소(예: 탐색 콘텐츠 섹션 이미지 및/또는 미디어 필요) 양식 요소 클릭 유도문안(CTA)을 식별하는 데 사용됩니다. )

와이어프레임은 일반적으로 흑백 또는 회색 음영으로 생성되고 이미지에 자리 표시자를 사용하며 특정 글꼴에 포함되지 않습니다(많은 경우 복사 유형의 구분을 전달하기 위해 글꼴 크기 조정을 적용하지만). 매우 기본적인 것부터 전체 화면 디자인을 거의 복제하는 고급 제품에 이르기까지 모든 모양과 크기로 제공됩니다. 와이어프레임은 진화하고 있습니다. 더 이상 디자이너와 개발자에게 작업의 개요로 제공되지 않습니다. 이제 와이어프레임은 클라이언트, 디자이너, 개발자 및 핵심 수준에서 관련이 있는 다른 팀 구성원에게 사이트 또는 애플리케이션을 나타내는 데 사용됩니다. 시각적 디자인 및 개발 단계가 시작되기 전에 "디자인 사고"에 대한 검증을 얻기 위해 클라이언트에게 보여주는 것이 일반적입니다. 종종 와이어프레임을 생성하는 사람들은 비즈니스 요구 사항을 생성하는 사람들과 손을 맞잡고 작업합니다(어떤 경우에는 동일한 사람들입니다). 또한 최고의 와이어프레임과 주석 중 일부는 비즈니스 분석가에서 개발자 및 기타 설계자에 이르기까지 다양한 작업 파트너 간의 직접적인 상호 작용 및 공동 작업의 결과라는 점에 유의해야 합니다. 일부 회사는 BRD(비즈니스 요구 사항 문서) 대신 와이어프레임과 주석을 사용하는 방향으로 전환하고 있습니다. 비록 세상이 BRD가 멸종했다고 주장하는 것과는 거리가 멀지만, 이 변화의 시작은 와이어프레임과 주석을 만들 때 매우 철저하고 사려깊은 것이 얼마나 중요한지를 보여주기에 충분합니다. 대부분의 경우 사용자에게 와이어프레임이 표시되어 페이지 요소를 확인하거나 수정을 요청할 수 있는 피드백을 이끌어냅니다. 와이어프레임

186

11장: 와이어프레임과 주석

일반적으로 프로토타입이라는 다른 이름을 가진 사용자 앞에 배치됩니다. (프로토타이핑에 대한 자세한 내용은 12장을 참조하십시오.) 가장 적합한 접근 방식을 식별하는 데 도움이 되도록 이 장에서는 와이어프레임 생성의 기본 사항에 대해 설명하고 현장 디자이너의 예를 보여줍니다. 이 책의 나머지 부분과 마찬가지로 이러한 예는 시작에 불과합니다. 스스로 탐구하고 혁신하는 것을 두려워하지 마십시오.

주석이란 무엇입니까? 주석은 매우 간단하게 와이어프레임의 요소 또는 상호 작용에 대한 설명 및 메모입니다. 여기에는 일반적으로 콘텐츠 식별 또는 레이블 지정 콘텐츠 소스 표시 규칙 상호 작용 규칙 상호 작용 대상 프로세스 규칙 오류 콘텐츠/메시징과 같은 정보가 포함됩니다.

간결하지는 않더라도 매우 직접적인 어조와 명확한 설명으로 주석을 작성하는 것이 가장 좋습니다. 주석에 어떤 것도 우연에 맡기지 마십시오. should와 shall 사이에는 매우 큰 차이가 있습니다. 나쁨: "이 클릭 유도문안(CTA)을 트리거하면 홈페이지가 표시되어야 합니다." 좋음: "이 클릭 유도문안(CTA)을 트리거하면 홈페이지가 표시됩니다." 공정하게 말하면, 첫 번째 예는 정확히 끔찍하지는 않지만, 그 단어는 프로세스에서 자신이 좋아하는 UX 디자이너가 질문에 답하기 위해 대기할 수 있는 사치가 없을 수 있는 개발자 다운스트림에게 혼란의 여지를 남겨둘 수 있습니다. 주석 스타일이 간결하고 지침을 읽고 의존해야 하는 모든 사람에게 모호함이 없도록 하십시오.

주석이란 무엇입니까?

187

누가 와이어프레임을 사용합니까? 명확하고 간결한 주석이 있는 와이어프레임은 매우 훌륭하지만 이러한 출력의 실제 대상은 누구입니까? 불행히도 이에 대한 간단한 대답은 없습니다. 프로젝트마다 청중은 한 사람에서 여러 그룹의 조합에 이르기까지 다양할 수 있습니다. 표 11.1에는 와이어프레임의 잠재 고객이 요약되어 있습니다. 표 11.1

188

와이어프레임 대상

청중

목적

프로젝트 관리

프로젝트 관리자는 팀 내에서 와이어프레임을 논의 지점으로 사용하여 전략, 기술 요구 사항 및 매우 높은 수준의 사용자 경험을 강조할 수 있습니다.

비즈니스 분석가

비즈니스 분석가는 와이어프레임을 사용하여 요구 사항이 충족되고 포함되어야 하는 요구 사항이 누락되지 않았는지 확인할 수 있습니다.

비주얼 디자이너

비주얼 디자이너는 와이어프레임을 출력의 청사진으로 사용할 수 있습니다. 와이어프레임은 포함되어야 하는 페이지 요소 및 동작에 대한 설명을 제공합니다.

콘텐츠 제작자

카피라이터, 콘텐츠 전략가, 편집자 및 카피를 담당하는 기타 사람들은 와이어프레임을 사용하여 콘텐츠 매트릭스에 매핑하고 프로젝트 전체에서 콘텐츠 요구 사항을 식별할 수 있습니다.

검색 엔진 최적화(SEO) 전문가

SEO 전문가는 와이어프레임을 사용하여 적절한 명명 체계, 카피 요구 사항 및 전체 SEO 전략의 개선 사항을 식별하는 데 도움을 줄 수 있습니다. (SEO에 대한 자세한 내용은 8장을 참조하십시오.)

개발자

개발자는 종종 비즈니스 요구 사항과 함께 와이어프레임을 사용하여 설계의 예상 기능과 동작을 이해합니다. 경우에 따라 와이어프레임이 개념 증명의 기초로 사용될 수 있습니다.

품질 보증

QA 팀은 테스트 스크립트를 작성하기 위한 기초로 와이어프레임을 사용할 수 있습니다. 고객이 와이어프레임을 승인하면 변형이 최소화되어야 하며 이를 통해 QA 팀은 작업을 더 일찍 시작할 수 있습니다.

사용자

사용자는 디자인 방향을 테스트하기 위한 메커니즘으로 매우 초기 단계에서 "종이 프로토타입"의 형태로 와이어프레임을 볼 수 있습니다. (12장 참조)

클라이언트

클라이언트는 비즈니스 요구 사항, 목표 및 목적이 충족되었는지 확인하고 시각적 디자인 단계로 진행하기 위한 승인을 제공하기 위해 와이어프레임 검토에 점점 더 많이 참여하고 있습니다.

11장: 와이어프레임과 주석

와이어프레임 생성 와이어프레임을 생성하려면 일반적으로 일련의 요구 사항이 필요합니다. 이는 클라이언트의 공식적인 비즈니스 요구 사항 문서, 크리에이티브 요약서 또는 프로젝트 요약서, 회의 메모, 잘 표현된 사이트 맵 또는 작업 흐름 또는 방향을 제공하는 냅킨 메모의 형태로 제공될 수 있습니다. 어떤 식으로든 사용자를 위해 만들려고 하는 것이 무엇인지, 연결이 무엇인지, 기술적 한계와 기대치에 대한 일반적인 이해가 필요합니다. 참고 비즈니스 요구 사항 정의에 대한 자세한 내용은 4장과 5장을 참조하십시오. 효과적인 회의록에 대한 제안 사항은 www.projectuxd.com에서 온라인 보너스 장인 "A Brief Guide to Meetings"를 참조하십시오.

필요한 정보를 수집한 후 시간을 내어 모든 요구 사항을 주의 깊게 읽고 질문하고 답변을 고려하여 추가 명확성을 얻으면 와이어프레임 생성을 시작할 준비가 된 것입니다!

무역 도구 10장의 "무역 도구" 섹션에는 사이트 맵과 작업 흐름을 만드는 데 사용할 수 있는 많은 디자인 도구가 나열되어 있습니다. 좋은 소식은 와이어프레임과 주석에 대해 기본적으로 동일한 응용 프로그램을 사용할 수 있다는 것입니다. 나쁜 소식은 이것이 와이어프레임을 만드는 첫 경험이라면 어디서부터 시작해야 할지 조금 헤매는 느낌이 들 수 있다는 것입니다. 하지만 기다리세요. 아직 더 좋은 소식이 있습니다. 거의 모든 노련한 사용자 경험 전문가는 연필과 종이로 작업을 시작하므로 기술 솔루션을 즉시 선택해야 하는 것처럼 느껴서는 안 됩니다(스케치에서 디지털로 다소 빠르게 변환해야 할 수도 있음). Adaptive Path의 경험 디자이너인 Leah Buley는 "How to Be a UX Team of One" 프레젠테이션에서 연필과 종이(저자와 마찬가지로) 사용의 중요성을 강조합니다. Leah는 "와이어프레임에 대한 아이디어 스케치를 처음 시작할 때 자주 발생하는 상황은 다음과 같습니다. 한두 가지 좋은 아이디어가 있는데 벽에 부딪힙니다. 이러한 아이디어는 아마도 당신이 보고 좋아했던 것 또는 과거에 디자인한 것에서 나올 것입니다. 그것은 끝이 아닙니다. 좋은 출발점입니다.

누가 와이어프레임을 사용합니까?

189

마음은 익숙한 것에 집중하는 경향이 있지만 익숙한 것이 항상 문제에 대한 최선의 해결책은 아닐 수 있습니다. 종종 아이디어 4 또는 5로 더 다양한 아이디어를 찾도록 강요하면 새롭고 흥미로운 것을 생각해낸 것입니다. 왜 그렇게 되는지 모르겠습니다. 그냥 그렇습니다. 템플릿은 이 프로세스를 안내하는 데 유용할 수 있습니다. Adaptive Path에서는 6개의 작은 썸네일 스케치를 수행할 수 있는 공간을 제공하는 6업 템플릿을 사용합니다. 스케치의 수는 실제로 그다지 중요하지 않습니다. 중요한 것은 처음 몇 가지 명백한 아이디어를 넘어서도록 자신을 강요하는 것입니다. 여섯 개의 작은 상자가 있는 식스 업 템플릿은 모든 작은 축소판이 채워질 때까지 계속 진행하도록 격려하기 때문에 6은 (나에게) 마법의 숫자입니다.

그림 11.1 Adaptive Path의 6업 템플릿

특히 UX 디자인의 세계에서 하고 있는 작업에 이제 막 익숙해지고 있는 경우 더욱 그렇습니다. 시간이 지남에 따라 자신에게 가장 적합한 접근 방식을 식별하기 시작하지만 Leah보다 더 나은 조언은 없습니다. 그녀의 접근 방식에 대한 추가 정보를 보려면 www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one에서 전체 "하나로 구성된 UX 팀이 되는 방법" 프레젠테이션을 온라인으로 볼 수 있습니다. 연필과 종이로 시작하는 것을 두려워하지 마세요. 지우개를 많이 가져오세요. 실수는 프로세스의 일부이며 연필 스케치를 한 후에도 디지털로 이동함에 따라 수정해야 합니다.

190

11장: 와이어프레임과 주석

반복 영역 내에서 UX 디자이너만큼 자주 그리고 일관되게 작동하는 직업은 거의 없습니다. 첫 번째 패스에서 디자인 작업이 승인되는 경우는 매우 드물며 때로는 "올바른 방향으로 잘못"되기를 바랄 뿐입니다. 이 때문에 작게 시작하십시오. 프로젝트의 한 페이지 또는 섹션의 작은 부분을 가져와 먼저 내부 팀과 검토한 다음 클라이언트 팀과 함께 이해가 제대로 되었는지 확인하십시오. 비즈니스 목표에 대한 클라이언트의 생각 방식에 디자인을 맞추면 앞으로 많은 재작업을 줄일 수 있습니다. 사용자와의 디자인 테스트에도 동일한 접근 방식을 적용할 수 있습니다. 조기에 검증을 받으십시오!

간단하게 시작: 기본 와이어프레임 설계 이 섹션에서는 매우 기본적인 수준에서 와이어프레임을 생성하는 방법을 살펴봅니다. 종종 간단한 사이트 맵과 몇 가지 추가 요구 사항만으로 시작할 수 있지만 이를 통해 웹 사이트의 홈 페이지에 대한 와이어프레임을 구축할 수 있습니다. 매우 단순한 웹 사이트가 어떻게 구성될 수 있는지를 보여주었던 10장의 기본 사이트 맵을 기억하십니까? 그림 11.2는 복습을 제공합니다. 보다시피 어느 정도의 탐색 계층 구조가 표시되어 있습니다. 식별된 모든 X.0 페이지는 최상위 또는 기본 페이지일 가능성이 높습니다. 이를 비즈니스 요구 사항 및 와이어프레임의 일부를 정의하기 위한 출발점으로 사용할 수 있습니다. 1.0

1.0.1 이용약관

홈페이지

2.0 – 2.x 블로그

3.0 정보

4.0 작업

5.0 연락처

그림 11.2 블로그 기능이 있는 기본 웹 사이트의 사이트 맵

간단하게 시작: 기본 와이어프레임 설계

191

시작하기 자신의 비즈니스 요구 사항 문서를 작성하는 것은 드문 일이 아니며 이는 축복이자 저주가 될 수 있습니다. 당신이 요구사항의 작성자일 때, 본질적으로 모호하거나 상대적으로 정의되지 않은 것의 의미를 논의할 사람은 당신 자신 또는 당신의 고객뿐입니다. 종종 당신이 가면서 그것을 꾸며내고 있는 것처럼 느껴질 수 있지만, 그것이 당신을 단념하게 해서는 안 됩니다. 많은 경우 와이어프레임은 작업 중인 정보의 차이를 식별하는 데 도움이 됩니다. 이것은 궁극적으로 최상의 솔루션을 만드는 데 도움이 될 수 있습니다. 사용자 경험 실무자는 사용자를 위해 가능한 최상의 솔루션을 제공하기 위해 노력하며 모든 프로젝트의 첫 번째 버전은 항상 피드백을 요청하고 디자인의 다음 반복에 영향을 미치는 데 사용됩니다. 디자인이 완벽할 필요는 없지만 깨끗하고 전문적으로 보이고 최악의 경우 올바른 방향으로 잘못되었는지 확인하고 싶습니다. 이 홈 페이지 디자인에 대한 요구 사항은 제한적이고 매우 간단합니다. 다행스럽게도 그림 11.2의 사이트 맵은 웹 사이트에 사용할 수 있는 탐색을 공식화하기에 충분한 정보를 제공합니다. 홈 페이지(번호 1.0)는 탐색의 최상위 수준입니다. 자귀

& 조건(1.0.1)은 일반적인 바닥글 요소일 가능성이 높거나 적어도 기본 탐색의 일부로 간주되어서는 안 됩니다. 다른 기본 탐색 요소는 About(3.0), Work(4.0), Con-

tact(5.0) 및 Blog(2.0–2.x) - 페이지 스택으로 표시되므로 여러 동적 페이지로 표시되고 "이전" 및 "다음" 탐색 형식이 있을 수 있음을 확인할 수 있습니다. 이러한 기본 탐색 요소는 시작할 수 있는 많은 정보를 제공하지만 웹 사이트의 홈 페이지를 효과적으로 만들기에는 충분하지 않습니다. 따라서 방향을 제시하는 데 도움이 되도록 클라이언트는 몇 가지 추가 정보를 제공했습니다. 이 회사는 블로그 및 작업한 프로젝트 범위로 인해 노출된 부티크 사용자 경험 디자인 회사입니다. 웹 사이트 방문자가 사용자 경험 디자인과 함께 작동하는 제한된 텍스트와 강력하고 연상시키는 이미지를 통해 회사/웹 사이트가 무엇인지 빠르게 알 수 있도록 하는 것이 중요합니다. 또한 탐색이 명확해야 하며(가능한 경우 재사용 가능한 머리글과 바닥글을 선호함)

192

11장: 와이어프레임과 주석

방문자가 사용자 경험 세계의 현재 문제에 대한 당사의 최신 테이크 요약을 빠르게 읽을 수 있도록 가장 최근의 블로그 게시물에 클릭 유도문안이 있습니다. 가능하다면 홈페이지에서 최근 작업을 강조할 수 있으면 좋겠지만, 우리 작업의 대부분이 종종 개발 중이거나 엄격한 비공개 상태에 있기 때문에 이것은 부차적인 일입니다.

와이어프레임 및 주석 이러한 요구 사항을 해석하는 방법에는 여러 가지가 있으며 클라이언트에 대한 첫 번째 와이어프레임 프레젠테이션은 그림 11.3과 매우 유사할 수 있습니다. 주석이 있는 와이어프레임 홈 페이지 주석 1

로고 2

집

삼

블로그

우리의 일

회사 소개

연락하다

1 · 로고 이미지. · 로고는 의 홈페이지에 대한 링크 기능을 합니다.

웹 사이트 내의 모든 위치에서 웹 사이트. 2 · 홈 내비게이션. · 웹사이트의 홈페이지로 연결됩니다.

웹 사이트 내의 모든 위치에서. 3 · 블로그 내비게이션.· 모든 곳에서 블로그 랜딩 페이지로 연결됩니다.

웹 사이트 내의 위치. 4 · Our Work Navigation.· Our Work 랜딩 페이지로 연결됩니다.

웹 사이트 내의 모든 위치에서. 5 · About Us Navigation. · About Us 방문 페이지로 연결됩니다. 6 7

7 8 9 10 11

환영 제목이 여기에 표시됨

Lorem ipsum pain sit amet, consectetuer adipiscing elite, sed diam nonummy nibh euismod tincidunt out laoreet 9 pain magna aliquam erat volutpat.

<가장 최근 블로그 제목>

Lorem ipsum pain sit amet, consectetuer adipiscing elit, 15 sed diam nonummy nibh euismod tincidunt ut laoreet pain magna aliquam erat volutpat.

내가 본 것처럼 나는 그들 중 일부와 같이 플레이어의 체벌을 행사하지 않는 최소한으로 올 것입니다. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolor magna aliquam erat volutpat.

나는 고통에 대해 매우 유감입니다, consectetuer adipiscing 12

13 더보기 > 17

안건 #

15 16 17 18 19

웹 사이트 내의 모든 위치에서. · 연락처 탐색. · 웹 사이트 내의 모든 위치에서 연락처 페이지로 연결됩니다. · 영웅 이미지 회전. · 이미지는 미학적으로 만족스럽고 브랜드와 일치하는 여러 이미지를 통해 회전해야 합니다. · Welcome Title. · 일반 웹사이트 개요 텍스트의 제목. · 환영 콘텐츠. · 웹사이트에 대한 일반적인 개요 콘텐츠. · · 제목. · 작업 포트폴리오에서 임의로 표시된 예의 제목. · · 이미지 링크. · 작업 포트폴리오에서 임의로 표시된 예의 이미지. 작업 포트폴리오에서 표시된 무작위 사례의 세부 정보를 보려면 링크해야 합니다. · · 요약. · 작업 포트폴리오에서 임의로 표시된 예시에 대한 간략한 요약 텍스트(텍스트 최대 1-2줄 권장). · · More Link. · 작품의 포트폴리오에서 임의로 표시된 예제의 세부 사항을 볼 수 있도록 링크합니다. · · 제목. · 가장 최근 라이브 블로그 게시물의 제목입니다. · · Intro Content. · 가장 최근 라이브 블로그 게시물의 처음 200자. · · 추가 링크. · 가장 최근 라이브 블로그 게시물의 전체 블로그 게시물을 보려면 링크해야 합니다. · 저작권 콘텐츠. · 회사 이름과 함께 저작권 및 올해. · 이용약관 링크. · 웹사이트 내의 모든 위치에서 이용약관 페이지로 연결됩니다. · 연락처 링크. · 웹 사이트 내의 모든 위치에서 연락처 페이지로 연결됩니다.

8 · Welcome Title. · 일반 웹사이트 개요 텍스트의 제목. 9 · Welcome Content.· 웹사이트의 일반적인 개요 콘텐츠. 10 · · 제목. · 무작위 예의 제목

작업 포트폴리오에서 표시됩니다. 11 · · 이미지 링크. · 임의의 이미지

nt 블로그 제목>

pain sit amet, consectetuer a 15 um nibh euismod tincidunt aliquam erat volutpat.

d 나는 우리가 누구인지 알게 될 것이다

15 16 17 18

주석 19

작업 포트폴리오에서 표시되는 예입니다. 작업 포트폴리오에서 표시된 무작위 사례의 세부 정보를 보려면 링크해야 합니다. · · 요약. · 작업 포트폴리오에서 임의로 표시된 예시에 대한 간략한 요약 텍스트(텍스트 최대 1-2줄 권장). · · More Link. · 작품의 포트폴리오에서 임의로 표시된 예제의 세부 사항을 볼 수 있도록 링크합니다. · · 제목. · 가장 최근 라이브 블로그 게시물의 제목입니다. · · Intro Content. · 가장 최근 라이브 블로그 게시물의 처음 200자. · · 추가 링크. · 가장 최근 라이브 블로그 게시물의 전체 블로그 게시물을 보려면 링크해야 합니다. · 저작권 콘텐츠. · 회사 이름과 함께 저작권 및 올해. · 이용약관 링크. · 웹사이트 내의 모든 위치에서 이용약관 페이지로 연결됩니다. · 연락처 링크. · 웹 사이트 내의 모든 위치에서 연락처 페이지로 연결됩니다.

그림 11.3 홈페이지 디자인을 위해 제출된 주석이 있는 와이어프레임

간단하게 시작: 기본 와이어프레임 설계

193

주석이 있는 와이어프레임은 페이지의 모든 요소는 물론 예상 클릭 유도 문안 및 작업 결과(예: 특정 페이지 로드)를 자세히 설명합니다. 이 특정 예는 제한된 수의 요소와 제한된 양의 세부 사항이 필요하기 때문에 매우 잘 작동합니다.

그림 11.4 www.userglue.com의 라이브 홈 페이지 디자인

그림 11.4에서 볼 수 있듯이 현재 이 홈 페이지의 라이브 버전은 그림 11.3의 원래 와이어프레임과 약간만 다릅니다. 예를 들어 타임라인과 콘텐츠가 문제가 되었기 때문에 포트폴리오 예시 섹션이 제거되었습니다. 또한 내비게이션과 클릭 유도문안에 대한 명명 규칙의 차이점에 주목하세요. 와이어프레임은 가이드라인 역할을 했지만 최종 단어는 아니었습니다. 최종 결과 역시 와이어프레임의 내용에 비해 다양한 사소한 변경 및 업데이트가 있는 경우가 많습니다.

194

11장: 와이어프레임과 주석

연습: 홈 페이지 와이어프레임 디자인 예제를 보았으므로 이제 바로 들어가서 직접 와이어프레임을 만들 차례입니다. 귀하의 임무는 가상의 국제 크루즈 라인인 Global Cruises의 홈페이지를 재설계하는 것입니다. Global Cruises는 홈 페이지가 재방문자(크루즈를 예약하고 다른 기회 및 추가 기능, 여행 조건 업데이트에 대해 자세히 알아보는 데 관심이 있는 것으로 보이는 경우가 많음)를 위한 판매 도구 및 정보 리소스로 보다 효과적이기를 원합니다. , 기타 등등. 연습은 아래 요구 사항을 사용하여 문서 또는 별도의 문서(선택)에 주석이 있는 하나의 홈 페이지 와이어프레임을 만드는 것입니다. 더 이상은 없습니다.

요구 사항 주요 필수 요구 사항은 전체 머리글과 바닥글(그림 11.5)이 동일하게 유지되어야 한다는 것입니다. GLOBAL HEADER 로고 목적지

현재 캠페인 로고 여행 경험

여행 계획

찾다

여행 전

글로벌 크루즈

VIP 클럽

스페셜

가다

마이 글로벌 크루즈

Welcome Back, <사용자 이름> N ( ot <사용자 이름>?) | 다음 크루즈까지 XX일 –예약 관리 | BookTravel 애드온| 온라인 체크인

그림 11.5 기존 Global Cruises 전역 머리글 및 바닥글

연습: 홈 페이지 와이어프레임 디자인

195

"있으면 좋은 것"은 최신, 가장 인기 있는 및/또는 판매 일정을 표시하는 기능 일정 지리적 위치 및 여행 지점을 표시하는 기능 로그인한 경우 일정을 볼 수 있는 기능(내 일정/IES) 상향 판매 항목을 볼 수 있는 기능입니다. 추가 정류장으로(예: 가는 경우

하와이 여행, 섬 투어 예약), 선상 식사 경험 등 추가할 가치가 있다고 생각할 수 있는 모든 것

글로벌 크루즈 이제 작업이 시작됩니다. 와이어프레임 스케치를 시작하고 그에 따라 주석을 다는 것을 잊지 마십시오! 와이어프레임을 완성했으면 다음 페이지에서 동일한 요구 사항 세트를 받은 다른 최고 전문가의 예를 확인하십시오.

196

11장: 와이어프레임과 주석

결과: 홈 페이지 와이어프레임 설계 Semantic Foundry(www .semanticfoundry.com)의 사용자 경험 아키텍트인 Will Evans는 친절하게 Global Cruise 연습 요구 사항을 기반으로 와이어프레임을 만들었습니다. 자신의 작업을 그림 11.6 및 11.7의 디자인과 비교하여 그의 접근 방식이 당신의 접근 방식과 어떻게 비교되는지 확인하십시오. 와이어프레임과 주석을 어떻게 연결했는지에 대한 설명이 이어집니다. 990px 너비의 여행 알림

크루즈 찾기

심벌 마크

5.0

4.0

3.0

2.0

1.0

바하마

새로운 여정

가다

주석이 달린 메모

인기 일정 1

글로벌 크루즈 VIP 클럽 6.0

스페셜

크루즈 스페셜

다시 오신 것을 환영합니다. W iMMŔ로그아웃

7.0

$279

바하마 및 플로리다

$279

바하마 및 플로리다

$279

바하마 및 플로리다

$279

바하마 및 플로리다

찰스턴 프리포트

다음 크루즈까지 15일 -

7박

그레이트 스터럽 케이(우리만의 섬) 포트 커내버럴 찰스턴

나소

그레이트 스터럽 케이(우리만의 섬) 포트 커내버럴 찰스턴

나소

미디어/플래시/헤도닉 이미지

글로벌 헤드라인 필터링 | 나만의 주연 만들기 크루즈 계획에 도움이 필요합니다

찰스턴 프리포트

그레이트 스터럽 케이(우리만의 섬) 포트 커내버럴 찰스턴

IMG

6.0

빠른 제안: 캐시된 결과에 일치하는 문자열 표시

7.0

다음 메타데이터가 포함된 크루즈 빌렛: 1. 가격 2. 평균 평점 3. 제목: 크루즈 제목 4. 기간 5. 기항지 6. 세부 정보 링크 7. 이 크루즈 링크 예약 8. 이 크루즈 기억/즐겨찾기

8.0

패싯 탐색을 통해 사용자는 포트, 여행 월, 선박 또는 가격 범위를 동적으로 변경할 수 있으며 일치하는 결과 세트를 동적으로 정렬/필터링합니다. 사용자가 검색 결과 화면에서 전체 결과를 본 후에는 이 중 하나를 되돌릴 수 있습니다.

9.0

사용자가 예측 검색을 위해 필터를 조정한 후 Ajax를 사용하여 빠른 정렬을 위해 자바스크립트 배열에 전체 결과 세트를 로드하는 모든 검색 결과를 클릭하여 볼 수 있습니다.

Share Your Moments Call Out, 회원 프로필 크라우드소싱 페이지에 나만의 Starring Your Moments 링크를 게시합니다.

세부

Shot FridayHero Saturday의 제목

이 특별 패키지 예약

-모든 선박 프로모션/뉴스

$190 ~ $1650

헤더 Adipisic Duis가 따를 것인가, 아니면 고통이 쾌락 속에서 꾸짖을 것인가, 그는 고통에서 머리털이 날까, 태어날 일이 없을 것입니다.

명료함은 주님 자신의 고삐, 또는 꾸짖음의 고통의 분노, 고통의 깃털이 되고자 하는 기쁨의 분노입니다.

주연 당신 순간

세부

가격: 헤도닉 이미지

명료함은 주님 자신의 고삐, 또는 꾸짖음의 고통의 분노, 고통의 깃털이 되고자 하는 기쁨의 분노입니다.

링크가 포함된 새 여정 드롭다운: 섹션 4.x 인기 여정에 대한 링크가 포함된 여정 표시 - 가장 인기 있는 상위 5개 여정을 보여주는 드롭다운

5.0

나소

배:

-매월-

쾌락적 이미지

헤더 결과 Adipisicing

예측 제안 정의 사용자 시나리오 3.X로 검색

4.0

세부

당신의 결과 당신 Y 순간 지금! 가다

(Video) 클릭 한 번으로 놀라운 UX 사례 연구를 만드십시오! | 디자인 에센셜

월:

브랜딩/로고 링크 홈 페이지

3.0

금요일 토요일 7박

그레이트 스터럽 케이(우리만의 섬) 포트 커내버럴 찰스턴

홈 항구/도시: 프로모션/뉴스 워싱턴 D.C. 8.0

나소

여정 보기 | 마이글로벌

금요일 토요일 7박

여행 알림: 0.2.0.0에 연결

2.0

세부

금요일 토요일 7박

1.0

마이 글로벌

HEDONIC IMAGE 9.0 검색결과 전체보기

헤더 Adipisic Duis가 따를 것인가, 아니면 고통이 쾌락 속에서 꾸짖을 것인가, 그는 고통에서 머리털이 날까, 태어날 일이 없을 것입니다.

아이디어 헤더 번호 1

아이디어 헤더 번호 3

아이디어 헤더 번호 2

아이디어 헤더 번호4

아이디어 헤더 번호 3

2008년 10월 8일 오후 6:46

브랜드 프로모션

그러나 즐거움을 고발하고 고통을 찬양하는 사람들의 이 모든 타고난 오류가 어디에서 오는지 여러분이 알 수 있도록 전체 문제를 공개하고 진리의 발견자, 말하자면 건축가가 말한 바로 그 내용을 설명하겠습니다. 행복한 삶의. 그러나 당신이 이 모든 오류가 어디서 비난하는 자들의 기쁨이 되고 찬양하는 자들의 고통인지 알 수 있도록 모든 문제를 공개하겠습니다.

나만의 포스트

11 1 12

이메일을 받으려면 가입하세요

국가 변경 링크

전역 바닥글 링크

consectateur nonummy lorenzino의 손실에 대해 매우 유감입니다. 때때로 평범한 사람은 그가 실수하는 곳을 봅니다.

13 12

글로벌 이메일을 수신하려면 등록하세요.

에서 아님? 여기를 클릭하세요

페이지: 3

그림 11.7 검색이 활성화된 Will Evans의 Global Cruises 홈페이지 와이어프레임

Will의 말에 따른 와이어프레임 생성 나에게 와이어프레임은 주어진 문제 공간(이 예에서는 유람선 운영자의 홈 페이지)을 설정하고 탐색하기 위한 일종의 "사고 장치" 역할을 합니다. 와이어프레임의 사용을 통한 설계는 대안의 문제 공간에서 검색입니다. 문제를 해결하는 과정인 만큼 문제를 설정하는 과정이다. 즉, 나는 항상 맥락에서 시작한다. 이 경우 주요 청중은 적시에 적절한 가격으로 최고의 크루즈를 쉽게 찾고 싶어합니다. 단순화하기 위해 저는 주요 청중과 그들이 하나의 목표를 빠르고 쉽게 우아하게 해결할 수 있는 하나의 활동을 선택합니다. 여러 개의 와이어프레임을 스케치함으로써 대안을 탐색할 수 있으며 불가능하고 상상할 수 있는 아이디어가 모두 제시되고 테스트되며 많은 경우 폐기됩니다. 나는 가능한 최고의 크루즈 라인 검색 인터페이스를 디자인하고 싶다는 것을 이미 알고 있었고 그 활동이 디자인의 전면과 중심에 있기를 원했습니다. 사용자가 보기로 약속하기도 전에 즉시 제안된 크루즈를 제공하는 개념을 스케치한 곳이 바로 여기였습니다.

198

11장: 와이어프레임과 주석

전체 검색 결과 화면. 나는 사용자가 대화에 참여하고 훌륭한 크루즈를 찾는 과정에 참여하기를 원했습니다. 크루즈 찾기

바하마

알겠습니다. '바하마'를 찾았습니다.

가다

18 크루즈 스페셜

$279

바하마 및 플로리다

$279

바하마 및 플로리다

$279

바하마 및 플로리다

$279

바하마 및 플로리다

찰스턴 프리포트

7박

그레이트 스터럽 케이(우리만의 섬) 포트 커내버럴 찰스턴

나소

7박

그레이트 스터럽 케이(우리만의 섬) 포트 커내버럴 찰스턴

나소

세부

금요일 토요일 7박

그레이트 스터럽 케이(우리만의 섬) 포트 커내버럴 찰스턴

세부

금요일 토요일 7박

그레이트 스터럽 케이(우리만의 섬) 포트 커내버럴 찰스턴

세부

금요일 토요일

세부

금요일 토요일

결과 필터링 Y 고향 항구/도시: 월:

워싱턴 DC.

배:

-매월-

가격:

-모든 선박

$190 ~ $1650

모든 검색 결과 보기

그림 11.8 Will Evans의 첫 페이지 크루즈 검색 결과 기능

유람선 운영자의 경우 머리글, 바닥글, 정적 콘텐츠 및 CTA 및 프로모션과 같은 콘텐츠 모듈을 위한 디자인 영역을 차단해야 할 필요성을 스케치했습니다. 이 단계의 결과를 주요 이해 관계자와 공유하지만 비주얼 디자이너, 개발 리드, 품질 보증도 참여시켜 그들이 프로세스에 기여하고 더 많은 아이디어를 제공하고 함정과 제약 사항을 문서화하기 시작할 수 있도록 합니다. 마지막으로 설계자로서 설계를 사양으로 구현하기로 결정해야 했습니다. 나는 최종 고려를 위해 2~3개의 후보를 만들었고, 주석을 사용하여 와이어프레임이 이해관계자와 대상 테스터에게 해당 사례를 간청할 수 있도록 했습니다. 그림 11.6과 11.7에서 볼 수 있는 와이어프레임은 이제 디자인 변경이 적고 세부 사항이 다듬어지는 이 단계에 있습니다.

연습: 홈 페이지 와이어프레임 디자인

199

비교 및 대조 그림 11.3의 예와 Will Evans의 작업은 와이어프레임을 생성하는 스타일이 상당히 유사하지만 서로 다르다는 점에 유의하는 것이 중요합니다. 지금은 두 가지 모두 보기 쉽고 자랑스럽게 "저게 와이어프레임입니다!"라고 말할 수 있습니다. 둘 다 고유한 스타일과 접근 방식의 요소가 있지만 핵심은 매우 유사합니다. 이 장의 예는 자신에게 가장 잘 맞는 와이어프레임 스타일을 찾기 시작하기에 좋은 곳입니다.

Maciej Piwowarczyk의 사진 제공

시각 디자인: 와이어프레임이 성장하고 세계에서 고유한 방식을 찾을 때

그림 11.9 Mark Brooks의 Global Cruises 홈페이지 시각 디자인

200

11장: 와이어프레임과 주석

요구 사항과 Will Evans의 와이어프레임에서 Mark Brooks(www .markpbrooks.com)는 가상의 Global Cruise Lines에 대한 홈 페이지 디자인을 만들었습니다. 그림 11.9의 시각적 디자인을 검토하면서 그가 페이지의 레이아웃과 콘텐츠를 어떻게 설명했는지 주목하십시오. 디자인이 프로세스를 거쳐 개발 단계로 넘어가면 인터랙션 모델이 생기기 시작합니다.

디자인 실습 후속 조치: 어떤 디자인이 옳은가? 요구 사항이 충족되는 한 옳고 그른 설계는 없습니다. 때때로 다양한 접근 방식을 탐색하고, 세부 사항을 검토하고, 잠재 사용자, 팀원 및 고객에게 제시하기 위해 단일 페이지에 대한 여러 와이어프레임을 만들어야 한다는 강박감을 느낄 수 있습니다. 이것은 완전히 허용됩니다. 이것은 반복 연습이라는 것을 기억하십시오. 고객에게 제공하는 작업은 첫 번째 시도에서 "올바른" 또는 "최종"으로 간주되지 않는 것이 거의 항상 보장됩니다. 대부분의 경우 적어도 한 번의 반복 및 업데이트를 통해 작업하는 자신을 발견하게 될 것입니다. 불행히도 이는 때때로 여러 라운드로 확장될 수 있지만 이는 프로젝트의 특성이며 궁극적으로 하위 작업 파트너에 대한 탐색을 줄여야 합니다. 와이어프레임과 주석을 제공된 두 가지 예와 비교할 때 프레젠테이션 방식과 스타일의 차이점을 살펴보세요. 이 장 앞부분의 홈 페이지 예제 및 수행한 작업과 이를 비교하십시오. 유사점과 차이점을 찾고 이미 설정된 템플릿이 없는 한 가장 적합한 접근 방식을 만드십시오. 많은 경우 와이어프레임을 만들 때 가장 어려운 부분은 처음으로 종이에 연필을 대는 것입니다. Leah Buley의 조언에 따라 다양한 아이디어 스케치를 시작하세요. 낙서하고 그림을 그리고, 다양한 접근 방식을 탐색하고, (방어하지 않고) 디자인을 방어할 수 있다는 확신이 들 때까지 동료, 동료, 가족과 함께 디자인을 테스트하세요. 올바른 방향으로 나아가고 있는 자신을 찾으십시오.

연습: 홈 페이지 와이어프레임 디자인

201

와이어프레임 표시에 대한 최종 참고 사항 일단 와이어프레임 생성을 시작하고 작업 산출물에 더 익숙해지고 워크플로우에 얼마나 가치가 있는지 이해하게 되면 모든 사람이 와이어프레임을 생성하는 데 드는 생각과 시간의 양을 이해하는 것은 아니라는 사실을 잊기 쉽습니다. 종종 클라이언트와 작업 파트너는 완전히 다른 품질 수준, 복잡성 또는 다른 주석 스타일의 와이어프레임에 노출되었을 수 있습니다. 사실, 많은 작업 파트너와 고객이 이전에 와이어프레임을 본 적이 없다는 것을 알 수 있습니다(그들이 본 적이 있다고 말하더라도). 클라이언트와 작업 파트너가 사이트 맵과 와이어프레임의 차이점과 각각의 목적에 대해 혼란스러워하는 것도 드문 일이 아닙니다. 즉, 첫 번째 와이어프레임이 잠재적으로 클라이언트의 첫 번째 와이어프레임이 될 수도 있습니다! 따라서 발표할 내용의 무대를 정확하게 설정하는 것이 매우 중요합니다. 와이어프레임을 제시하기 전에 와이어프레임이 무엇인지, 최종 시각적 디자인과 비교하여 어떻게 보일지, 그리고 그 목적이 무엇인지 명확하게 설명해야 합니다. 다음은 와이어프레임 제시에 대한 몇 가지 추가 조언입니다. 가능하면 검색 중에 고객 팀을 참여시키십시오. 그들을 얻으려고

화이트보드에 적극적으로 그림을 그리고 있습니다. 그들은 와이어프레임 프로세스에 기여하고 있으며 최종 결과는 비슷해 보이지만 전자 형식으로 생성될 것이라고 설명합니다. 이것은 설계 옵션을 탐색할 때 완전히 다르게 보일 수 있는 와이어프레임으로 이어지는 활동임을 설명하는 것이 매우 중요합니다. 와이어 간의 차이점을 전달하기 위해 강력한 은유를 찾으십시오.

프레임과 프로젝트의 최종 디자인. 인기 있는 은유는 "집에 청사진/평면도가 있는 것처럼 응용 프로그램/웹 사이트에 와이어프레임이 있습니다."입니다. 와이어프레임을 사용하면 변경 사항을 보다 쉽고 효율적으로 구현할 수 있으며 일반적으로 변경 비용이 덜 드는 단계(빌드 팀을 참여시키고 기초를 붓기 전)에 적용할 수 있습니다. 회의 참석자들에게 와이어프레임이 최종 표현이 아니라는 점을 알리십시오.

사이트의 그래픽 처리에 대한 설명입니다. 와이어프레임은 콘텐츠, 일반 레이아웃 및

202

11장: 와이어프레임과 주석

페이지의 요소. 와이어프레임이 승인되면 건물을 시작할 수 있습니다. (아, 미묘한 변화는 여전히 발생할 수 있습니다!) 시간과 예산이 있다면 시각 디자이너를 참여시켜

와이어프레임과 최종 디자인 간의 차이점을 보여주기 위해 목업을 디자인합니다. 가능하면 와이어프레임과 최종 디자인이 어떻게 유사하고 동시에 다른지를 보여주는 다른 프로젝트의 고객 사례를 보여주십시오. 프로젝트 팀의 다른 구성원이 와이어를 사용하는 방법을 설명하십시오.

프레임 — 고객이 이 이정표에 대한 검토 및 승인의 중요성과 와이어프레임이 프로젝트의 나머지 부분에 알리는 방법을 이해하는 것은 결코 나쁠 일이 없습니다. 클라이언트와 작업 파트너가 와이어프레임의 가치와 디자인 프로세스의 위치를 이해하고 인식하기 시작하면 프로젝트를 진행하기가 더 쉬워집니다. 왜? 와이어프레임은 프로젝트의 나머지 부분에서 시각적 명확성과 방향성을 만드는 데 도움이 되기 때문입니다. 많은 경우에 작업 파트너와 클라이언트는 귀하를 대신하여 와이어프레임의 유용성을 전파할 수도 있습니다. 이를 통해 사용자 경험 디자인에 더 많은 시간을 할애하고 판매 시간을 줄일 수 있습니다!

와이어프레임 표시에 대한 최종 참고 사항

203

디자인에 생명을 불어넣는 프로토타이핑 프로토타이핑은 개발에 투자하기 전에 제안된 기능과 디자인을 테스트하고 검증하는 효과적인 방법입니다. 프로토타입을 생성하기 위해 빠르고 간단한 것(빠르고 깔끔한 것을 선호함)부터 대화식의 강력한 것까지 다양한 도구와 접근 방식을 사용할 수 있습니다. 사용하는 방법은 주로 프로토타입 개발에 사용할 수 있는 시간과 자료라는 두 가지 요소에 의해 결정됩니다. 러스 엉거와 조노 케인

프로토타이핑이란 무엇입니까? 사용자 경험 디자인의 맥락에서 프로토타이핑은 사용자와 함께 애플리케이션이나 웹 사이트의 기능 전체 또는 일부를 만들고 테스트하는 행위(대부분의 경우 기술)입니다. 프로토타입은 아날로그 도구(예: 화이트보드 또는 연필과 종이)를 사용하거나 PowerPoint, Acrobat, Visio, OmniGraffle, HTML 또는 기타 기술 기반 도구를 사용하여 디지털 방식으로 만들 수 있습니다. 프로토타이핑은 일반적으로 사용자 경험과 관련된 문제를 식별하거나 검증하기 위해 생성되기 때문에 반복적인 프로세스가 될 수 있습니다. 피드백을 수집하면 추가 테스트를 위해 프로토타입을 수정할 수 있습니다. 다른 경우에 성공적인 (충분한) 프로토타입은 프로젝트를 개발 수명 주기의 다른 단계로 계속 진행할 수 있습니다. 프로토타이핑은 가공물이 아니라 프로세스라는 점을 기억하십시오. 프로토타입이라고 부르는 화면 및 (때로는 모의) 기능을 생성하게 될 수 있지만 이는 최종 결과가 아니라 프로토타이핑의 일부입니다. 프로토타이핑 프로세스의 결과는 디자인을 향상하고 개선하는 데 사용할 수 있는 개념의 실행 가능한 피드백입니다. 그러나 이 장은 프로토타입 생성에만 초점을 맞추고 테스트 세부 사항은 13장에 맡깁니다.

얼마나 많은 프로토타입이 필요합니까? 모든 사용자 경험 디자인 프로세스에는 공식적이든 비공식적이든, 대화형이든 정적이든 어느 정도의 프로토타이핑이 포함되어야 합니다. 전체 웹 사이트나 애플리케이션에 대해 프로토타이핑을 수행할 필요는 없습니다. 실제로 프로토타이핑은 시스템의 대표적인 샘플링만 사용할 때 매우 효과적일 수 있습니다. 즉, 전체 시스템의 시뮬레이션을 생성할 필요가 없고 핵심 부분만 생성할 수 있습니다. 대부분의 경우 몇 가지 개념을 테스트하고 싶을 것이며 프로토타입에는 이러한 개념과 약간의 추가 정보가 포함되어야 합니다. 화이트보드, 연필과 종이 스케치, 스토리보드, 카드보드 오려내기 등 즉시 사용할 수 있는 여러 가지 방법을 사용하여 프로토타이핑을 할 수 있습니다. 또한 대화형 프로토타입을 만들고 보다 현실적인 환경에서 테스트 사용자를 참여시킬 수 있는 다양한 디지털 도구를 사용할 수 있습니다.

얼마나 많은 프로토타입이 필요합니까?

205

선택한 프로토타이핑 방법은 사용 가능한 시간과 재료에 따라 크게 달라집니다. 다음은 많은 프로토타이핑 요구 사항을 충족하는 데 사용할 수 있는 보다 인기 있는 방법 중 일부입니다.

종이 프로토타이핑 종이 프로토타이핑의 실습, 예술 및 공예 접근 방식만큼 어린 시절로 돌아갈 수 있는 활동은 거의 없습니다. 필요한 유일한 도구는 연필과 펜, 종이, 가위, 그리고 미술 부서에서 스 와이프하거나 지역 사무용품점에서 구입할 수 있는 모든 것입니다. 종이 프로토타이핑은 유연합니다. 지우개 또는 더 많은 재료가 있는 한 필요한 만큼 시나리오를 만들 수 있습니다. 또한 테스트에서 테스트로 신속하게 수정할 수 있습니다. 즉, 잠재적 사용자가 귀하가 만든 항목에서 눈에 띄는 오류를 지적하는 경우 다음 잠재적 사용자에게 보여주기 전에 디자인을 업데이트하는 복잡한 프로세스가 아닙니다. 또한 저렴합니다. 종이 프로토타이핑에 투자하는 시간 외에도 일반적으로 하이브로우 라떼 두어 개 비용보다 훨씬 적은 비용으로 모든 시나리오를 만들 수 있습니다. 종이, 포스트잇, 색인 카드, 연필 등은 이미 마음대로 사용할 수 있어야 하며, 그렇지 않은 경우 비축하여 은행을 망치지 않을 것입니다. 프로세스는 간단합니다. 테스트하려는 기능 부분을 스케치합니다. 사용자에게 기능을 제공합니다. 피드백을 문서화합니다(종이이므로 프로토타입을 뒤집고 쓰기 시작). 그런 다음 다음 사용자로 이동하거나 업데이트하고 다시 시작하십시오. 단순한. 재미있는. 효과적인. 프로세스 초기에 종이 프로토타이핑을 사용하면 막대한 투자를 하기 전에 디자인 관련 문제를 발견하는 데 도움이 될 수 있습니다. 이 단계에서 변경을 빠르고 효율적으로 수행하여 위험을 줄일 수 있습니다. 이렇게 하면 설계에 너무 많은 투자를 하기 전에 효율적으로 변경할 수 있습니다. 서로 다른 색종이 세 장을 사용하여 그림 12.1의 각 탭은 웹 사이트에 표시되는 대로 스케치하고 서로 쌓였습니다. Global Now 탭은 맨 위에 배치되어 사용자가 처음으로 홈페이지를 방문한 것처럼 콘텐츠를 표시합니다. 각 탭은 사용자가 사용할 수 있는 탐색을 표시하고 다른 보기 옵션을 선택할 수 있도록 합니다.

206

12장: 프로토타이핑

그림 12.1 수직 탭 기반 내비게이션의 페이퍼 프로토타입

그림 12.2 My Itinerary 탭이 활성화된 수직 탭 기반 탐색의 페이퍼 프로토타입

사용자가 다른 탭을 선택하면 그림 12.2에 표시된 My Itinerary 탭과 같이 새로 활성화된 탭의 콘텐츠 영역 보기를 표시하기 위해 해당 탭이 스택의 맨 앞으로 이동합니다. 종이 프로토타이핑은 최대한 적은 예산으로 위의 연습처럼 간단할 수 있습니다. 전체 시스템을 탐색하기 시작하면 투자하는 시간이 상당히 늘어날 수 있습니다(재료 비용은 약간만 증가하지만). 100페이지의 종이 프로토타입에서 기본 탐색을 변경해야 하는 경우 이 방법은 비용이 많이 듭니다. 종이 프로토타이핑은 기본적으로 비용이 저렴하지만 조각을 업데이트해야 할 때 재사용하기에는 적합하지 않습니다. 이 시점에서 디지털 도구로 전환하는 것이 더 유익한지 고려해야 합니다.

디지털 프로토타이핑 프로토타이핑 요구 사항이 종이로 처리할 수 있는 것보다 더 큰 경우 기술 기반 솔루션이 귀하와 청중에게 더 적합하다는 것을 알 수 있습니다. 이러한 도구를 사용하면 사이트 또는 응용 프로그램의 대화형 부분이 사용자에게 어떻게 표시되는지 정확하게 보여줄 수 있습니다. 디지털 프로토타이핑은 디자인 프로세스의 다른 많은 측면에서 가져옵니다. 디지털 프로토타입을 제시하거나 테스트할 때 페르소나를 참조할 수 있고, 프로토타입의 차단 및 시각적 처리를 위해 와이어프레임을 참조할 수 있으며, 현실적인 프로토타입에 맞춰 마무리합니다.

와이어프레임과 사실적인 프로토타입 종이 프로토타이핑 방법과 마찬가지로 마일리지는 디지털 프로토타입에 따라 다를 수 있습니다. 귀하가 보유하고 있는 도구, 리소스 및 기술에 따라

디지털 프로토타이핑

207

처리하고 있는 요구 사항뿐 아니라 와이어프레임처럼 보이는 프로토타입이 프로젝트에 적합하다는 것을 알 수 있습니다. 사실 그게 더 좋을 수도 있습니다. 와이어프레임은 프로젝트가 아직 진행 중인 작업이며 최종 생산 준비 사이트가 아님을 청중에게 보여줄 수 있습니다. 반면에 때때로 사용자와 디자인 테스트를 하는 동안 프로토타입의 가장 중요한 측면이 최종 시스템을 얼마나 현실적으로 표현하는지를 알게 될 것입니다. 디지털 프로토타입의 결과는 세 가지 요소에 따라 달라집니다. 타임라인은 어떻게 생겼습니까?

팀을 구성하고 바로 앞에 앉아 있는 사용자에게 생산 준비가 완료된 사이트에 대한 명확한 비전을 보여줄 거의 생산 준비가 된 놀라운 프로토타입을 구축할 시간이 있습니까? 몇 시간 동안 와이어프레임을 HTML로 내보내거나 아주 간단한 Flash 프로젝트를 만들어 프로젝트 내에서 페이지 흐름과 기본적인 상호 작용 요소를 보여주나요? 두 가지 유형의 디지털 프로토타입 모두 매우 유용할 수 있습니다. 그러나 기한이 임박한 실제 프로젝트와 마찬가지로 사용 가능한 시간과 자료를 기반으로 기대치를 설정하는 것이 중요합니다. 누구를 위해 이 프로토타입을 만들고 있으며 그 이유는 무엇입니까?

프로젝트에 너무 깊이 들어가기 전에 프로토타입으로 무엇을 하는지 아는 것이 프로토타입의 성공에 매우 중요합니다. 사용자와 함께 디자인 테스트를 위한 프로토타입을 만들고 있습니까? 그렇다면 테스트에 중점을 두는 것이 중요합니까? 프로토타입이 흑백 와이어프레임인지 아니면 라이브 웹 사이트와 유사해야 하는지가 중요합니까? 버튼과 링크의 검색 가능성을 테스트하고 있습니까? 경영진, 관리자, 투자자 또는 하루가 끝날 때 귀하의 수표에 서명할 수 있는 다른 사람들의 동의가 필요한 비즈니스 프레젠테이션의 프로토타입을 만들고 있습니까? 그렇다면 그들에게 무엇을 전달하려고 합니까? 기능적이어야 하는 것과 단순히 기능적으로 보이면 되는 것은 무엇입니까? 이러한 질문은 디지털 프로토타입에 대한 요구 사항을 결정하는 데 도움이 될 수 있습니다.

208

12장: 프로토타이핑

어떤 유형의 리소스, 도구 및 기술을 사용할 수 있습니까?

HTML 또는 Flash 전문가가 아니고 전문가를 고용할 예산이 없는 경우에도 PowerPoint 또는 Keynote와 같은 간단한 프레젠테이션 도구나 Visio 또는 OmniGraffle과 같은 와이어프레임 도구를 사용하여 매우 기능적인 프로토타입을 제작할 수 있습니다. 간단한 PDF도 가능합니다.

HTML 대 WYSIWYG 편집기 HTML은 종이 프로토타입에 해당하는 디지털입니다. 그것은 (때때로) 무료이고 (다소) 쉽습니다. HTML 마법사나 프런트 엔드 코드 전문가가 아니더라도 HTML에 대한 기본 지식만 있어도 HTML 프로토타입 마법사가 될 수 있습니다. 기본적으로 HTML 프로토타입을 만드는 두 가지 방법이 있습니다. HTML을 직접 코딩하거나 Adobe Dreamweaver, Realmac의 RapidWeaver 또는 Microsoft Visual Studio와 같은 WYSIWYG 편집기를 사용하는 것입니다. 이러한 도구에는 브라우저를 열지 않고도 코드 작업을 시각화할 수 있는 레이아웃 보기와 코드 보기가 있습니다. WYSIWYG 편집기로 프로토타입 만들기 WYSIWYG HTML 편집기에서 레이아웃 보기를 사용할 때 좋은 점은 Apple의 Keynote인 Microsoft PowerPoint에서 페이지를 레이아웃하는 데 걸리는 것과 거의 동일한 노력으로 페이지 레이아웃을 만들 수 있다는 것입니다. , 또는 기타 간단한 그래픽 레이아웃 응용 프로그램(나중에 자세히 설명). 또한 링크, 마우스 이벤트 등과 같은 상호 작용을 추가하는 것도 쉽습니다. Dreamweaver CS4(그림 12.3)의 가장 인상적인 측면 중 하나는 오픈 소스 WebKit 렌더링 엔진을 기반으로 Adobe에서 라이브 뷰라고 부르는 기능을 제공한다는 것입니다. 이것은 무엇을 의미 하는가? 간단히 말해서 라이브 뷰에 표시되는 내용이 Apple의 Safari 및 Google의 Chrome 브라우저에서 표시되는 것과 정확히 일치한다는 의미입니다. 프로토타입의 세부 사항에 세심하게 신경을 썼다고 가정하면 됩니다. Dreamweaver CS4는 특히 Adobe Fireworks CS4와 함께 사용할 때 매우 강력한 프로토타이핑 도구입니다.

디지털 프로토타이핑

209

그림 12.3 Dreamweaver CS4에서 만든 간단한 예제 프로토타입

기본 HTML 프로토타입 만들기 간단하고 빠르고 간편한 HTML 프로토타입을 만드는 가장 저렴한 방법은 "수동", 즉 텍스트 편집 도구에 수동으로 코드를 입력하는 것입니다. 디자인을 와이어프레임에서 프로토타입으로 전환하는 가장 일반적인 이유 중 하나는 사이트의 제안된 흐름과 탐색을 보여주거나 테스트해야 한다는 요구 사항입니다. 와이어프레임(또는 디자인 목업)에서 요소 블록 또는 전체 페이지를 가져와 HTML 프로토타입에서 클릭 가능한 이미지로 설정하면 작동하는 프로토타입을 매우 빠르고 쉽게 구축할 수 있습니다. 브라우저에서 전체 페이지 이미지를 클릭한 다음 다른 페이지를 로드할 수 있는 매우 간단한 프로토타입은 매우 간단합니다. 다음 실습에서는 홈 페이지와 검색 결과 와이어프레임이 필요하거나 www.projectuxd.com에서 샘플 이미지를 다운로드할 수 있습니다. 참고 오타는 HTML 코딩에서 가장 흔히 저지르는 실수이므로 입력의 정확성에 세심한 주의를 기울여야 합니다.

210

12장: 프로토타이핑

1. 선호하는 도구(예: Visio 또는 OmniGraffle)에서 홈 페이지 와이어프레임을 내보내거나 시각적 디자인 도구에서 디자인 구성 요소를 내보냅니다. 전체 페이지를 홈페이지.gif라는 GIF 이미지로 저장해야 합니다. Prototype이라는 이름의 새 폴더를 만들고 거기에 홈페이지.gif를 저장합니다. 참고 JPEG 형식은 래스터 및 사진과 같은 이미지에 적합합니다. GIF는 와이어프레임과 선 그리기에 더 적합합니다.

2. WYSIWYG HTML 편집기 또는 메모장(Windows) 또는 TextEdit(Mac)과 같은 간단한 텍스트 편집기에서 새 문서를 만들고 동일한 Prototype 폴더에 홈페이지.html로 저장합니다. TextEdit를 사용하는 경우 파일 형식으로 HTML을 선택했는지 확인하십시오. 3. 새 문서에 다음 HTML 코드를 삽입합니다. 1]iba3 1]ZVY3

1i^iaZ3=dbZeV\Z1$i^iaZ3

1$]ZVY3 1WdYn3 1$WdYn3 1$]iba3

4. 문서를 저장한 다음 웹 브라우저에서 파일을 엽니다. 빈 페이지가 표시되어야 하지만 브라우저에 제목 표시줄이 있습니다. "홈페이지"라고 표시되어야 합니다. 5. 텍스트 편집기에서 홈페이지.html 코드를 수정합니다. 및 태그 사이에 다음 HTML을 입력합니다. 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

이 코드는 전체 홈페이지.gif 이미지를 searchresults.html 페이지(기능이 제대로 작동하는지 확인하려면 만들어야 함)를 로드하는 클릭 가능한 버튼으로 바꿉니다. 6. 문서를 저장하고 브라우저에서 페이지를 다시 로드합니다. 브라우저에서 방금 생성한 새 홈 페이지가 제대로 표시되어야 합니다(그림 12.4). 브라우저에서 이미지를 클릭하면 브라우저가 searchresults.html 페이지(아직 존재하지 않음)를 로드하려고 시도합니다.

디지털 프로토타이핑

211

7. 검색 결과 와이어프레임 콘텐츠에 대해 1단계를 반복합니다. 이 페이지를 GIF 이미지로 저장하고 이름을 searchresults.gif로 지정한 다음 Prototype 폴더에 저장합니다. 현재 website.html 문서의 새 복사본을 searchresults.html로 저장합니다. 현재 "homepage.html" 페이지에 대해 "다른 이름으로 저장"을 선택하고 대신 "searchresults.html"로 저장합니다. 그런 다음 HTML을 업데이트하여 표시하고 홈 페이지(homepage.html)로 다시 연결하십시오. 다음 코드 줄을 교체해야 합니다: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

이것으로: 1V]gZ[2]dbZeV\Z#]iba31^b\hgX2hZVgX]gZhjaih#\^[WdgYZg2%31$V3

8. 이 페이지가 생성되면 두 페이지가 서로 연결되는 방식을 보여주는 매우 기본적인 HTML 프로토타입이 생깁니다.

그림 12.4 웹 브라우저에서 본 홈 페이지의 HTML 프로토타입

212

12장: 프로토타이핑

코드 세분화 이제 매우 제한된 양의 HTML을 사용하여 기본 프로토타입을 만들었으므로 사용한 코드 또는 HTML 태그를 간략하게 살펴보고 방금 수행한 내용을 더 잘 이해할 수 있습니다. HTML, 헤드 및 제목 태그 1]iba3 1]ZVY3

1i^iaZ36Wdji1$i^iaZ3

1$]ZVY3

모든 HTML 문서에 필요한 기본 태그입니다. 여기서 주목해야 할 중요한 항목은 페이지 이름을 지정할 수 있는 제목 태그입니다. 이미지 태그 1^b\hgX2]dbZeV\Z#\^[3

간단한 태그이기도 합니다. 브라우저에서 이미지를 보는 데 필요한 모든 것입니다. 다음과 같은 앵커 태그, 1V]gZ[2hZVgX]gZhjaih#]iba31$V3

HTML 문서에서 링크를 설정하는 데 사용됩니다. 단순화를 위해 예제의 앵커 태그는 튜토리얼 프로젝트가 같은 폴더에 있기 때문에 "상대"인 상대 경로를 사용합니다. 절대 경로는 다음과 같습니다. 1V]gZ[2]iie/$$lll#jhZg\ajZ#Xdb$XdciVXi#e]e31$V3

이 HTML은 양식화되지 않았거나 표준을 준수하지 않지만(개발자에게 보여주지 마십시오. 개발자가 코드 개발 관행에 대한 엄격한 교훈을 제공하라는 메시지를 받을 수 있습니다!) 프로토타입을 브라우저. 기억하세요. 이 프로토타입은 완벽할 필요가 없습니다. 목표는 단순히 청중에게 아이디어를 전달하는 것입니다. 이 간단한 마크업 예제는 페이지 간 클릭 연결을 허용하는 링크된 HTML 파일을 생성했지만 레이아웃 내에서 클릭 가능한 영역을 보다 세분화하려면 어떻게 해야 할까요? 답은 이미지 맵입니다. 이미지 맵을 사용하면 링크할 이미지 영역을 지정하고 클릭했을 때 다른 페이지를 표시할 수 있습니다. 이미지 맵을 만드는 가장 쉬운 방법은 Dreamweaver와 같은 WYSIWYG 도구를 사용하여 HTML 코드를 만드는 방법에 대한 실제 지식 없이 이미지의 링크 가능한 부분을 할당하는 것입니다. 이미지 맵 생성 방법에 대한 자세한 내용은 "이미지 맵은 어떻게 생성합니까?"를 참조하십시오.

디지털 프로토타이핑

213

내 웹 페이지” Dave Taylor의 자습서: www.askdavetaylor.com/how_do_i_create_an_image_map_for_my_web_page.html. HTML 프로토타입은 디지털 프로토타이핑에 대한 한 가지 접근 방식일 뿐입니다. 다양한 프레임워크와 동적 코딩 언어를 사용하여 거의 모든 요구 사항을 충족하는 매우 강력한 프로토타입을 만들 수 있습니다. HTML 프로토타이핑이 탐색하고 확장하려는 영역인 경우 해당 영역에 대해 자세히 알아보기 위해 자습서 및 기타 리소스를 찾을 수 있습니다. 시작하려면 JavaScript, PHP(또는 기타 동적 코딩 언어), jQuery(http://jquery.com) 또는 Yahoo! 인터페이스 라이브러리(http://developer .yahoo.com/yu). 참고 HTML에 대한 자세한 내용은 HTML Dog: The Best-Practice Guide to XHTML and CSS, by Patrick Griffiths(New Riders, 2006)를 참조하십시오.

프로토타이핑을 위한 추가 도구 이제 아날로그 및 디지털 공간 모두에서 프로토타입을 만드는 데 도움이 되는 실습 옵션을 살펴보았습니다. 이러한 방법 외에도 기본 "작업 완료"에서 보다 강력하고 상호 작용 및 지능으로 가득 찬 프로토타입을 만드는 데 사용할 수 있는 다른 소프트웨어 도구가 많이 있습니다. 다음 목록은 포괄적이지는 않지만 상황에 맞는 올바른 프로토타입을 만들기 위한 다양한 옵션을 제공합니다. PowerPoint 및 Keynote PowerPoint 또는 Keynote 프로토타입은 빠르고 간편한 범주에 속하며 때로는 그것만으로 충분합니다. 간단한 상호 작용으로 기본 슬라이드 쇼를 만드는 것처럼 PowerPoint 또는 Keynote 프로토타입을 만들 수 있습니다. 두 도구 모두 사용자와 유효성을 검사하려는 흐름의 클릭 연결을 시뮬레이션하는 상호 작용을 생성할 수 있습니다. PowerPoint 또는 Keynote "고급 사용자"인 경우 애니메이션 및 기타 요소를 포함하여 프로토타입을 좀 더 대화식으로 만들 수 있습니다. Adobe Acrobat PDF 와이어프레임 또는 시각적 디자인 구성 요소를 여러 페이지의 PDF로 내보내는 것만으로도 제품의 모양과 선형 페이지 간 형식으로 탐색하는 방법을 보여줄 수 있습니다. 많은 응용 프로그램 214

12장: 프로토타이핑

PDF로 내보낼 수 있고 Mac을 사용하는 경우 인쇄 기능을 허용하는 모든 응용 프로그램에서 거의 모든 문서 또는 파일에 대해 PDF로 인쇄를 선택할 수 있습니다. Visio 및 OmniGraffle을 비롯한 많은 응용 프로그램을 사용하면 상호 작용을 위해 링크 위치와 같은 작업과 핫스팟을 지정할 수 있습니다. Visio 및 OmniGraffle Microsoft Visio와 The Omni Group의 OmniGraffle은 모두 와이어프레임을 만드는 잘 알려진 도구입니다. 둘 다 HTML 및 PDF 형식으로 내보낼 수 있는 기능을 통해 클릭 연결 시제품을 만들 수 있습니다. OmniGraffle에서는 HTML로 내보내는 경우 작업을 쉽게 할당하고 PDF 내에서 또는 URL로 점프할 지점을 지정할 수 있습니다. Visio에는 페이지 간 탐색을 위해 클릭 가능한 영역이 있는 HTML 또는 PDF로 쉽게 내보낼 수 있는 웹에서 다운로드할 수 있는 프로토타입 키트가 있습니다. Visio 및 OmniGraffle은 또한 EPS, GIF 및 JPEG와 같은 널리 사용되는 벡터 및 래스터 형식을 내보낼 수 있으므로 이미지를 Flash로 쉽게 가져오고 HTML 프로토타입용 이미지로 사용할 수 있습니다. Axure RP Axure RP의 "RP"는 신속한 프로토타이핑을 의미하며, 이는 많은 사용자 경험 디자이너들에게 인기 있는 도구입니다. 이 도구는 Visio 및 OmniGraffle과 유사한 그리기 기능을 제공하지만 다양한 탐색 스타일, 양식, 팝업 및 기타 일반적인 페이지 기반 상호 작용을 만들 수 있는 비교적 배우기 쉬운 도구 세트를 추가합니다. . 또한 사양, 주석, 할당 및 진행률 마커의 유연한 통합을 통해 프로토타입에서 직접 문서 기반 사양을 생성할 수 있습니다. Axure는 Windows 전용 도구이지만 Mac으로 작업 중이고 Windows를 시작할 수 있는 응용 프로그램을 사용하지 않는 경우 문제가 될 수 있습니다. Fireworks CS4 Adobe의 Fireworks CS4는 최근 와이어프레임에서 시각적 디자인에 이르기까지 다양한 디자인 구성 요소를 만드는 도구로 인기를 얻고 있습니다. 여기에는 외부 개발자 없이도 기능을 강조할 수 있는 쉽게 정의된 상호 작용을 허용하는 Windows 및 Mac 양식 요소 및 컨트롤의 표준 세트가 있습니다. 공용 라이브러리는 여러 문서에서 추가하고 공유할 수 있는 요소를 저장하므로 재사용할 수 있습니다.

디지털 프로토타이핑

215

구성 요소. Fireworks에는 개발자가 "포함"을 사용하는 방식이나 일부 문서 시스템에서 문서 페이지에서 재사용할 배경을 만들 수 있는 방식과 유사하게 특정 문서 내의 모든 페이지에 공통적인 요소 세트를 만들 수 있는 페이지 기능도 있습니다. 이 기능은 각 페이지에서 고유한 콘텐츠 영역을 유지하면서 머리글, 바닥글 및 탐색과 같은 반복 가능한 페이지 수준 콘텐츠 영역을 식별하는 데 유용합니다. Balsamiq 목업 Balsamiq Studios의 목업은 컴퓨터만 사용하여 연필과 종이로 와이어프레임을 스케치하는 것과 유사한 경험을 제공하는 와이어프레임 및 프로토타이핑 도구입니다. 미리 디자인된 다양한 일반 사용자 인터페이스 컨트롤(작성 당시 60개 이상)을 화면으로 끌어다 놓고 프로젝트에 맞게 사용자 지정할 수 있습니다. 모형은 마치 손으로 그린 것처럼 스타일이 지정되어 디지털 방식으로 생성된 화면에 유기적인 느낌을 더해 주지만 디지털 플랫폼을 사용하면 빠른 반복을 위해 디자인을 빠르게 수정할 수 있습니다. Adobe Flash를 사용한 Flash 및 Flash Catalyst 프로토타이핑은 기본적인 클릭 연결 프로토타입 이상의 대화식 개념을 전달할 수 있는 좋은 방법입니다. Flash를 사용하면 클릭 연결 프로토타입을 쉽게 만들 수 있을 뿐만 아니라 마우스 오버 또는 호버 이벤트, 클릭 이벤트, 비디오 및 애니메이션을 비롯한 다른 상호 작용 요소를 추가할 수도 있습니다. Flash를 더 자세히 탐색할 수 있는 기능이 있는 경우 Flash에는 사용자 상호 작용에 응답하고 원하는 결과를 표시하도록 프로그래밍할 수 있는 핵심 사용자 인터페이스 구성 요소 세트도 있습니다. Flash 프로토타이핑에 대한 입문서는 Boxes and Arrows에서 Alexa Andrzejeski의 기사 "Quick and Easy Flash Prototypes"를 참조하십시오: www.boxesand arrows.com/view/quick-and-easy-flash. 이 책이 출판될 때 Adobe는 Flash Catalyst라는 새로운 프로토타이핑 도구를 발표했습니다. Flash Catalyst는 다른 Adobe CS4 제품군 응용 프로그램과 함께 작동하여 디자인과 개발 프로세스 간의 통로 역할을 하는 개발 환경입니다. 이를 통해 적은 노력으로 디자인을 브라우저 지원 형식으로 내보낼 수 있습니다. 자세한 내용은 www. Adobe.com.

216

12장: 프로토타이핑

개발자와 작업 사용 가능한 리소스가 있는 경우 와이어프레임이나 디자인을 기반으로 프로토타입을 만들도록 개발자를 고용할 수 있습니다. 개발자는 달성하려는 작업을 확실히 이해해야 하므로 이 접근 방식을 사용하려면 효율적이고 효과적인 프로세스를 위한 개발 사양 및 요구 사항도 만들어야 할 수 있습니다. 프로토타입이 반복 테스트에 사용되는 경우 테스트를 위해 프로토타입의 어떤 부분에 초점을 맞추고 있으며 따라서 변경 사항을 신속하게 구현해야 하는지 전달해야 합니다. 개발 프로세스 중에 개발자와 시간을 보내고 변경에 취약한 것으로 표시되어야 하는 코드의 핵심 영역(코드에 주석 포함)을 식별하는 것이 좋습니다. 의사소통 라인을 개방하고 출력의 정확성을 보장하기 위해 프로토타입 개발 중에 개발자와 계속 협력하십시오. 참고 다양한 프로토타이핑 접근 방식에 대한 자세한 내용은 Todd Zaki Warfel(Rosenfeld Media, 2009년 출판 예정: www.rosenfeldmedia.com/books/prototyping)이 저술한 A Practitioner's Guide to Prototyping 책을 참조하십시오.

프로토타입 예제 이 장에 있는 간단하고 실행하기 쉬운 프로토타이핑 예제는 모든 상황에 사용해야 하는 완전한 접근 방식과는 거리가 멉니다. 프로토타이핑의 실제 사용 사례를 강조하기 위해 Keith Tatum과 Jon Hadden은 자신의 경험을 아낌없이 공유했습니다. Slingthought(www .slingthought.com)의 수석 사용자 경험 전략가인 Keith Tatum은 Align Interactive(www .aligninteractive .com). 또한 종이 프로토타이핑 프로세스를 통해 와이어프레임 단계를 건너뛰고 시각적 디자인 및 레이아웃으로 이동할 수 있었습니다(그림 12.6).

프로토타입 예시

217

그림 12.5 개발 팀에 탐색 개념을 설명하는 데 사용되는 종이 프로토타입

그림 12.6 종이 프로토타입을 기반으로 한 라이브 웹 사이트 디자인

Keith는 설계 및 개발 작업에 대한 팀의 공통된 이해를 활용하여 근무일 기준 2일 이내에 신속하게 설계를 생성했습니다. 이를 통해 팀은 시각적 디자인 컨셉이 승인되면 빠르게 개발을 진행할 수 있었습니다.

그림 12.7 고성능 XHTML, CSS 및 JavaScript를 사용하여 목업으로 만든 캘린더 도구의 기능적 프로토타입. 존 해든의 호의

218

12장: 프로토타이핑

Yahoo의 수석 비주얼 디자이너인 Jon Hadden(www.jonhadden.com)은 자신이 만들고 있는 Project Manager라는 도구의 일정 관리 기능 프로토타입을 만들었습니다. Project Manager는 프로젝트 관리를 위한 협업 웹 기반 애플리케이션입니다. 이것은 OmniGraffle 와이어프레임으로 시작하여 고성능 XHTML 프로토타입으로 구축되어 기능이 사용 가능하고 저렴한지 판단하는 데 도움이 되었습니다. 경제성은 중요한 점입니다. 경우에 따라 기능이 비용 효율적인지 확인하기 위해 응용 프로그램 또는 프로젝트의 일부를 프로토타입 테스트에 사용할 수 있습니다. 기능을 만드는 비용이 문제가 되고 프로토타입 개발이 시간과 재료의 기대치를 초과하는 경우 프로젝트의 실행 가능성을 평가해야 할 수 있습니다.

프로토타이핑 후에는 어떻게 됩니까? 프로토타이핑 프로세스를 완료하면 결과를 종합하여 실행 가능한 것으로 전환해야 합니다. 종이 프로토타이핑을 했다면 받은 피드백을 기반으로 디지털 와이어프레임 제작을 시작해야 할 수도 있습니다. 이미 디지털 와이어프레임 모드에 있는 경우 와이어프레임을 업데이트하고 프로젝트 프로세스를 진행해야 할 수 있습니다. 또는 다른 검토를 위해 피드백을 받고 프로토타입을 업데이트해야 할 수도 있습니다. Messagefirst(www.messagefirst.com)의 사장인 Todd Zaki Warfel은 다음과 같이 말했습니다. 프로토타입은 다음 목표 중 하나 이상을 달성하는 방법입니다. 예: 상사, 다른 설계자 등) 기술 타당성 테스트 최종 사용자/고객과 함께 설계 개념 테스트 프로토타이핑은 피드백 메커니즘 역할을 합니다. 프로토타이핑을 통해 프로젝트의 다음 단계로 이동하기 전에 특정 디자인 방향을 계속할지 아니면 다른 방향을 탐색할지 결정할 수 있습니다.

기억하세요: 프로세스의 어느 위치에 있든 프로토타이핑은 프로세스의 일부일 뿐이며 다른 부분과 마찬가지로 최대 효율성 지점에 도달하고 다음 단계로 넘어갈 준비가 되었는지 알아야 합니다. 사용자 경험 프로세스의 다음 단계. 프로토타이핑 후에는 어떻게 됩니까?

219

사용자를 대상으로 한 디자인 테스트 당신이 알고 있다고 생각하는 것에서 벗어나 그들이 어떻게 생각하는지 알아보십시오 6장에서 우리는 사용자 그룹을 이해하는 데 도움이 되는 몇 가지 UX 디자인 기술을 다루었습니다. 귀하의 사이트가 나타내는 주제. 이 장에서는 특정 디자인이나 디자인 요소에 대한 사용자 정보를 수집하는 데 도움이 되는 기술에 대해 설명합니다. 디자인 단계 초기에 자주 사용되는 탐색적 기술과 프로젝트의 여러 지점에서 사용할 수 있는 사용성 테스트에 중점을 둘 것입니다. 먼저 사용자와 함께 디자인 개념을 탐색하는 방법에 대해 이야기해 보겠습니다. 캐롤린 챈들러

개념 탐색 개념은 일반적으로 행복, 협업 또는 효율성과 같은 추상적인 아이디어를 설명하는 데 사용되는 단어입니다. UX 디자인 분야에서 개념은 프로젝트 팀이나 잠재적 사용자에게 하나 이상의 추상적인 아이디어를 표현하기 위한 디자인 요소를 가리키는 데에도 사용됩니다. 이러한 의미에서 개념 디자인 요소는 시각적일 수도 있고(예: 효율성 개념을 나타내는 기계 사진) 텍스트 기반일 수도 있습니다(예: 효율성을 표현하기 위해 작성된 짧은 문장 모음). 시의적절하고 반응이 빠른 것과 같은 단어를 사용하여 효율성에 대한 회사의 초점). 개념은 또한 와이어프레임 탐색, 시각적 디자인 목업 또는 사이트에서 일반적인 메시지를 표현하기 위한 대략적인 프로토타입을 의미할 수 있습니다(프로토타입에 대한 자세한 내용은 12장 참조). 개념 탐색은 일반적으로 사용자 그룹을 정의한 후 각 페이지 또는 화면의 세부 사항에 들어가기 전에 디자인 프로세스 초기에 발생합니다. 잠재 사용자로부터 얻을 수 있는 반응을 들을 수 있고 계획을 세울 수 있기 때문에 이 연구는 디자이너에게 영감을 주고 신제품을 시장에 출시하는 위험을 일부 줄일 수 있습니다.

개념 탐색의 주요 목적은 일련의 디자인 요소에 직면했을 때 사용자 그룹에서 도출되는 반응과 아이디어의 종류를 이해하는 것입니다.

개념 탐구는 일대일 토론으로 구성되거나 그룹으로 진행될 수 있지만 다양한 관점을 수집하고 토론하기 위한 일부 개별 활동을 포함합니다. 후자는 포커스 그룹처럼 설정할 수 있으며, 일부 시간은 개념 테스트 활동에 할애하고 그룹 토론이 뒤따릅니다(포커스 그룹에 대한 자세한 내용은 6장 참조). 비영리 소액 금융 조직을 위해 수행된 개념 탐색의 예를 살펴보겠습니다.

개념 탐구

221

개념 탐색의 잠재적 함정 Henry Ford는 "고객에게 원하는 것이 무엇인지 묻는다면 더 빠른 말을 요구했을 것입니다."라고 말한 적이 있습니다. 잠재적인 사용자와 개념을 탐색하여 훌륭한 아이디어를 얻을 수 있지만 디자이너를 대신하기 위해 그들에게 의존하고 싶지는 않습니다. 결국, 가장 기억에 남는 디자인은 종종 이전에 진행된 디자인과 매우 다르며 연구 참가자는 큰 변화를 불편해할 수 있습니다. 참가자 응답은 현재 이해에 뿌리를 두고 있습니다. 당신이 수집하는 것은 반응이지 미래에 그들이 원하거나 원하지 않을 것에 대한 예측이 아닙니다. 또한 디자인 자체 이외의 다른 많은 요소가 미래의 행동(예: 긍정적인 입소문)에 영향을 미칠 것이라는 점을 명심하십시오. 참가자들에게 직접적인 선택을 하도록 요청하지 마십시오(예: "A 또는 B 중 어느 개념이 더 낫습니까?"). 대신 제시된 개념을 설명하기 위해 그들이 자신의 단어를 어떻게 사용하는지 들어보십시오. 결과는 설계자에 대한 의무가 아니라 설계 프로세스에 대한 입력으로 생각해야 합니다. 설계 개념 테스트의 잠재적 함정에 대한 훌륭한 개요와 기술을 잘 사용하는 방법에 대한 권장 사항은 AIGA 웹 사이트에서 Debbie Millman과 Mike Bainbridge가 작성한 "Design Meets Research" 기사를 참조하십시오. http: //www.aiga.org/content.cfm/design-meets-research

소액 금융은 빈곤 국가의 기업가를 위한 소액 대출 자금입니다. 이러한 대출을 통해 차용인은 사업을 시작하고 결과적으로 가족과 지역 사회의 삶을 개선할 수 있습니다. 대출 자금은 더 큰 대출을 만들기 위해 소액을 빌려주거나 기부하기 위해 함께 모인 개인들로부터 나옵니다(예: 케냐의 상점 주인이 필요로 하는 $800의 대출에 자금을 지원하기 위해 각각 $25). 기업가는 사업이 성장함에 따라 대출금을 상환합니다. 자금 조달 모델은 매우 강력하지만 조직은 때때로 개념을 간단한 용어로 설명하는 데 어려움을 겪었습니다. 소액 금융을 설명하는 데 어려움을 겪는 것 외에도 조직은 종교와 관련된 메시지 및 디자인을 처리하는 방법에 대해서도 확신이 없었습니다. 이 특정 소액 금융 조직은 설립자와 직원의 믿음에서 영감을 받았습니다. 조직의 많은 사람들이

222

13장: 사용자와 디자인 테스트

이 영감은 사이트 디자인에서 분명했지만 올바른 균형을 맞추는 방법에 대해 확신이 없었습니다. 종교적 메시지가 너무 강하면 해당 신앙의 구성원이 아닌 잠재적 제공자를 멀어지게 할 수 있습니다. 너무 미묘하면 조직이 그 가치를 진정으로 나타내지 못할 것입니다. 프로젝트의 UX 디자이너는 이미지와 텍스트를 사용하여 소액 금융 모델을 설명하고 잠재적 기부자를 소외시키지 않으면서 조직의 종교적 영감을 표현할 수 있는 가능한 방법을 탐색하기로 결정했습니다. 이를 위해 그들은 모델과 관련된 개념(예: 자립 및 투자)을 설명하는 데 사용할 수 있는 사진과 단어와 다양한 수준의 종교적 메시지(예: 신앙 및 영성)를 나타내는 다른 항목을 선택했습니다. 그런 다음 사이트의 대상 사용자 그룹에 속하는 참가자로 포커스 그룹을 계획했습니다. 종교적 신념의 표현으로 기부한다고 표시한 사용자와 그렇지 않은 사용자의 두 사용자 그룹이 포함되었습니다. 각 그룹에 대해 진행자는 기부 모델을 설명했습니다(종교에 대해서는 아무 말도 하지 않음). 그런 다음 각 참가자에게 포스터 보드 한 장, 사진 세트, 사용할 단어 세트, 그리고 원하는 경우 자신의 단어를 채울 수 있는 빈 카드를 추가로 제공했습니다. 그들은 친구와 가족에게 모델을 설명하는 데 사용할 이미지와 단어를 표시하는 콜라주를 만들라는 요청을 받았습니다. 작업이 끝나면 참가자들은 다시 모여 자신의 콜라주를 발표하고 특정 이미지와 텍스트를 선택한 이유와 다른 이미지와 텍스트를 포함하지 않은 이유를 설명했습니다. 그림 13.1은 이 연습에서 만든 콜라주의 예를 보여줍니다. 그림 13.1 개념 테스트 중 참가자가 만든 콜라주의 예

프로젝트 팀은 이러한 콜라주와 이어지는 토론에서 귀중한 통찰력을 얻었습니다. 통찰에는 참가자들이 "서부-

ern” 용어(예: 비즈니스 정장 및 서류가방). 그들은 문화를 바꾸지 않고 기업가의 삶을 개선하기를 원했습니다.

개념 탐구

223

모든 사용자 그룹은 사이트의 초점이 목표에 있어야 한다는 데 동의했습니다.

조직의 동기(종교적 영감)가 아니라(기업가에게 성장과 번영을 위한 자금 제공) 참가자들은 조직이 자신의 정체성을 유지하는 것이 중요하지만 그러한 메시지는 조직 자체를 설명하기 위해 따로 마련된 영역(예: About Us 영역)에서 제공될 수 있다고 믿었습니다. 드러난 태도와 관심사는 팀이 사이트 메시징의 방향을 결정하는 데 도움이 되었으며 개념 테스트의 가치에 대한 좋은 예를 제공했습니다!

시각적 디자인 목업 탐색에 대한 팁 프로젝트의 어느 시점에서 사이트 페이지의 잠재적인 디자인을 나타내는 목업이 있을 수 있습니다. 참가자와 함께 디자인을 탐색하기로 결정한 경우 비교하고 대조할 수 있는 두 가지 이상의 변형을 제공하는 것이 가장 좋습니다. 하나만 사용하면 "좋은" 편향을 얻을 가능성이 더 큽니다. 사람들은 디자이너의 감정을 상하게 하고 싶지 않기 때문에 모형에 대해 지나치게 비판적으로 들리는 것을 원하지 않습니다. 그러나 두 개 이상의 목업을 사용하면 디자인을 직접 비평하는 것보다 디자인을 비교하는 데 더 집중하기 때문에 일반적으로 비판적이 되는 것을 더 편하게 느낄 것입니다. 참가자들에게 각 디자인을 개별적으로 제공하고(모니터 또는 종이 인쇄물로) 일련의 질문을 할 수 있습니다. 예를 들어 참가자들에게 각 디자인을 1분 동안 살펴본 다음 목록에서 디자인을 가장 잘 설명하는 용어를 세 개 이상 선택하도록 요청할 수 있습니다. 지겹다, 트렌디하다, 보수적이다, 시끄럽다, 안전하다 등 20개의 단어가 있는 종이에 무작위 순서로 선택 항목에 동그라미를 칠 수 있습니다. 개방형 질문에 대한 응답도 수집할 수 있습니다. 예를 들어 참가자들에게 디자인에 대한 일반적인 인상을 적도록 5개의 빈 줄을 줄 수 있습니다. 수집할 수 있는 일부 정보에는 참가자가 만든 일반적인 브랜드 연상이 포함됩니다.

"Pseudo Corporation은 위젯 제조업체의 롤스로이스입니다. 멋져 보이지만 아마도 감당할 수 없을 것입니다."

224

13장: 사용자와 디자인 테스트

디자인 및 라이프스타일 적합성:

“저는 제 아들을 이 사이트에 보내지 않을 것 같아요. 그는 겨우 8살이고 이 사진들은 그에게 너무 어른스러워 보입니다.” 새로운 개념을 설명하는 특정 목업의 효과:

"아, 알겠습니다. 이 사이트는 결혼 등록부와 같지만 식기 대신 자선 기부를 위해 등록하고 있습니다." 참가자가 귀하가 사용하는 일부 핵심 용어를 정의하는 방법:

"이 사이트에서 솔루션이라는 단어를 보면 선적을 추적하는 데 필요한 모든 제품과 서비스를 찾을 것이라고 생각합니다." 특정 도구 집합이 사용되는 방식에 대한 질문 또는 우려 사항

또는 그것들을 도입하는 것의 영향(다음 섹션은 참가자 우려 사항의 몇 가지 예를 보여줍니다). 디자이너는 이러한 응답을 사용하여 그들이 얻고 있는 반응이 의도한 것과 일치하는지 또는 다른 접근 방식을 시도해야 하는지 판단할 수 있습니다. 참가자(및 해당 문제에 대한 프로젝트 이해 관계자)는 종종 다른 디자인에서 다른 요소를 선택한다는 점을 명심하십시오. "나는 개념 A의 이 부분이 좋고 개념 B의 이 부분이 좋습니다." 이것은 자연스러운 반응이지만 너무 문자 그대로 받아들여서는 안 됩니다. 서로 다른 두 가지 디자인 방향이 부자연스럽게 혼합되는 것을 원하지 않습니다. 비주얼 디자이너가 대중적인 요소가 잘 어우러진다고 생각한다면 그렇게 하세요. 그러나 그녀가 "초콜릿과 피클"보다 "초콜릿과 땅콩 버터"가 적다고 말할 여지를 남겨 두십시오. 전반적으로 개념 테스트에 포함된 활동이나 테스트할 수 있는 요소 유형에 대한 엄격한 규칙은 없습니다. 오히려 핵심은 테스트에서 나올 정보의 종류와 해당 정보가 창의성을 저해하지 않고 디자인 결정을 알리는 데 어떻게 사용될 것인지에 대해 프로젝트 팀과 올바른 기대치를 설정했는지 확인하는 것입니다.

사용성 테스트 사용성 테스트는 가장 자주 사용되는 UX 디자인 테스트 방법 중 하나입니다. 또한 UX 디자이너가 아닌 사람들 사이에서 가장 잘 알려져 있으므로 비즈니스 이해 관계자와 프로젝트 팀은 이미 익숙할 수 있습니다. 개념 자체는 매우 간단합니다. 우선 순위가 지정된 집합을 만듭니다.

사용성 테스트

225

사이트에 대한 작업 중 일부 사용자에게 작업을 수행하도록 요청하고 문제와 성공이 있는 위치를 기록합니다.

사용성 테스트 대 사용자 승인 테스트 조직의 일부 사람들은 사용성 테스트가 사이트 또는 응용 프로그램의 기능 버전(예: 베타 모드)이 있을 때 개발 종료 또는 배포 시작 즈음에만 발생한다는 오해를 가질 수 있습니다. 이 인상은 나중에 사용자 수용 테스트(UAT)를 수행하는 일반적인 관행과도 관련될 수 있습니다. 이름의 유사성으로 인해 둘이 혼동될 수 있습니다. 공식적인 QA 프로세스를 거치는 애플리케이션의 경우 UAT는 테스트의 후반 단계 중 하나이며 실제 사용자가 수행하는 경우는 거의 없습니다. UAT의 주요 목적은 응용 프로그램이 이해 관계자가 설정한 기능 요구 사항을 충족하는지 여부에 대한 최종 확인 역할을 하는 경우가 많습니다. 또한 참가자가 보고하는 오류나 버그를 포착할 수 있습니다. UAT가 사용성 문제를 일으킬 수 있지만 프로젝트에서 문제를 파악하는 유일한 방법으로 의존해서는 안 됩니다. 프로세스 후반에 발생하기 때문에 UAT의 피드백을 기반으로 하는 변경은 훨씬 더 많은 비용이 듭니다. 개발에 많은 시간을 들이기 전에 프로세스 초기에 주요 문제를 파악하는 것이 훨씬 좋습니다. 사용성 테스트는 프로세스 초기에 보다 실제와 같은 성능 정보를 제공하도록 설계되었습니다.

다음 섹션에서는 다음과 같은 사용성 테스트와 관련된 일반적인 단계에 대해 설명합니다. 접근 방식 선택 연구 계획 모집 및 물류 토론 가이드 작성 촉진 결과 분석 및 제시 권장 사항 생성

226

13장: 사용자와 디자인 테스트

시작하기 전에 프로젝트 목표를 고려하십시오. 전체적으로 초점을 유지하는 데 도움이 되지만 접근 방식을 선택하고 테스트를 계획하는 초기 단계에서 특히 도움이 됩니다.

접근 방식 선택 연구 접근 방식은 종종 양적 또는 질적이라고 설명됩니다. 정량적 연구는 수치 데이터에 중점을 두며 대상 사용자 그룹 간에 높은 신뢰도와 반복 가능한 결과를 제공하기 위한 것입니다. 이는 해당 그룹 내에 충분히 큰 사용자 집합(샘플 크기라고 함)을 포함하여 더 작은 집합에서 결과를 가져오고 특정 범위 내에서 전체 사용자 그룹이 응답하는 방식에 대해 추론할 수 있는지 여부에 따라 달라집니다. 오류. 전반적으로 테스트 설계 및 분석에 대한 형식을 갖춘 연구에 대한 보다 과학적인 접근 방식입니다. 초점은 특히 사이트의 다른 반복, 경쟁업체 또는 일련의 벤치마크와 비교하여 현재 디자인을 평가하는 데 있습니다. 정량적 연구를 수행한다는 것은 타이핑 속도, 유사한 사이트에 대한 친숙도 등과 같이 개인마다 발견할 수 있는 차이를 설명하기 위해 더 많은 참가자를 참여시키는 것을 의미합니다. 설문조사는 더 많은 청중에게 확장될 수 있는 정보 수집 방법의 한 예로서 올바른 질문을 하면 정량적 데이터를 얻을 수 있습니다(설문조사에 대한 자세한 내용은 6장 참조). 반면에 질적 연구는 신뢰 수준과 반복성에 초점을 맞추는 것이 아니라 사용자 행동에 관한 맥락과 통찰력을 얻는 데 중점을 둡니다. 디자이너의 발견, 직관 및 상식에 대한 해석에 의존합니다. (6장에서 논의된 상황 탐구는 질적 연구의 한 예입니다.) 질적 접근 방식은 아이디어를 탐구하고 통찰력을 얻는 데 도움이 되는 테스트에 대한 개방성을 허용합니다. 사용자와의 토론은 그녀의 성과만큼 중요합니다. 초점은 현재 디자인을 개선하는 것입니다. 즉, 아이디어를 생성하기 위해 제시된 내용에 대한 통찰력과 반응을 얻는 것입니다. 그렇다면 사용성 테스트는 정량적 방법입니까 아니면 정성적 방법입니까? 이는 UX 디자인 분야에서 가장 오래 지속된 토론 중 하나입니다. 두 접근 방식 모두 가능하며 유용한 결과를 가져올 수 있습니다. 보다 정량적인 접근 방식을 지지하는 사람들은 다음과 같이 말합니다.

사용성 테스트

227

테스트할 수 있는 측정 가능한 벤치마크를 설정할 수 있습니다.

이후 반복에서 목표를 향한 진행 상황을 보여줍니다(예: 체크아웃 시간을 20% 단축하거나 사이트에서 사용성 문제의 80% 파악). 이것은 또한 두 사이트의 공식 비교를 수행하거나 특정 사이트를 평가하려는 경우 좋은 접근 방식입니다. 통계적으로 검증할 수 있는 결과를 제공하며 이는 중요할 수 있습니다.

데이터 기반 결정을 신뢰하는 이해 관계자에게 권장 사항을 방어해야 하는 경우. 개별 UX 디자이너의 편견이 영향을 미칠 가능성을 줄입니다.

결과. 얻은 결과에 대한 높은 신뢰도를 제공합니다.

전체 사용자 기반의 결과로 반영됩니다. 결과를 검증하는 명확하고 수치적인 방법을 제공합니다(예:

동일한 문제가 발생한 사용자 수). 질적 사용성 테스트 지지자들은 다음과 같이 말합니다. 질적 연구는 디자이너의 경험과 공감을 구축합니다.

사용자 중심의 창의적인 솔루션을 홍보합니다. 합리적인 추천을 하기 위해 UX 디자이너의 직관에 크게 의존합니다.

그녀가 팀에 있는 이유의 큰 부분입니다. 특히 사용성 테스트의 경우 질적 접근 방식이 덜 적합합니다.

더 적은 수의 사용자가 필요하고 정성적 연구는 공식적인 과학적 설계 및 분석(예: 통계)에 대한 지식이 필요하지 않기 때문에 양적 연구보다 비용이 많이 듭니다. 양적 연구 결과를 잘못 분석하는 것은 매우 쉽습니다.

(그러나 의도치 않게) 데이터를 사용하므로 정량적 접근 방식은 제대로 실행되지 않으면 정성적 테스트보다 실제로 더 많은 위험을 초래할 수 있습니다. 조사 결과가 수치적으로 검증되지는 않았지만 다음을 통해 검증할 수 있습니다.

정보에 입각한 근거를 사용하여 문제의 영향 가능성에 대해 전화를 걸고 사용자 스토리로 사례를 구축할 디자이너. 정성적 사용성 테스트는 공식적인 과학적 방법에 대한 교육을 받지 않은 사람들이 보다 쉽게 접근할 수 있는 접근 방식이며 디자인에 정보를 제공하기 위한 풍부한 데이터 소스를 제공합니다. 이러한 이유로 이 장의 나머지 부분에서는 정성적 테스트 설계에 중점을 둘 것입니다.

228

13장: 사용자와 디자인 테스트

"충분한" 사용자는 몇 명입니까? "사용자가 몇 명이면 충분합니까?" UX 디자이너 그룹에서 정치 집회에서 종교를 언급하는 것과 같으며 뜨거운 논쟁의 대상입니다. 또한 연구를 계획하기 위해 시작할 프레임워크가 필요하기 때문에 피할 수 없는 질문이기도 합니다. 사용하는 접근 방식(양적 또는 질적)과 관련이 있습니다. 짧은 대답을 드리자면, Jakob Nielsen이 제공한 UX 분야에서 가장 많은 합의를 얻은 것으로 보이는 지침은 다음과 같습니다. 정량적 테스트의 경우 더 많은 참가자 수를 계획하십시오. ://www.useit.com/alertbox/quantitative_testing.html). 질적 테스트의 경우 각 연구 라운드에 대해 그룹당 5~8명의 사용자가 일반적으로 충분합니다. 이상적으로는 다른 문제 아래에 "숨겨져 있거나" 의도하지 않게 새로운 디자인에 도입되었을 수 있는 문제를 발견하기 위해 한 라운드 이상의 조사가 수행됩니다(http://www.useit.com/alertbox/20000319.html 참조).

연구 계획하기 사용성 테스트를 설계할 때 초점과 범위를 제공하기 위해 초기에 답변해야 하는 몇 가지 질문이 있습니다. 이것은 종종 사용자 조사 계획이라고 하는 프로젝트 팀 및 주요 이해 관계자를 위해 작성되고 논의된 문서로 제공될 수 있습니다. 계획은 위에서 선택한 대로 접근 방식을 설명해야 합니다. 왜 테스트를 하시나요? 전체 프로젝트의 하나 이상의 목표를 기반으로 테스트 목표를 설명하는 명확한 설명을 작성하십시오. 설계 목표의 예와 프로젝트 유형에 따라 어떻게 달라지는지는 2장을 참조하십시오. 당신은 누구를 테스트하고 있습니까? 사용자 모델(6장 및 7장 참조)을 만든 후에는 테스트할 사용자를 결정하는 기준으로 사용할 수 있습니다. 아직 하지 않았다면 프로젝트 팀 및 관련 이해 관계자와 만나 사용자 그룹의 우선 순위를 지정하십시오. 이 정보는 귀하의 스크리너에게 제공됩니다("모집 및 물류"에서 논의됨). 사용성 테스트

229

또한 이 지점에서 표시할 사용자 그룹과 각 그룹에 포함할 사용자 수를 선택해야 합니다. 무엇을 테스트하고 있습니까? 테스트 대상에 대한 질문에는 다음과 같은 두 가지 상호 관련된 질문이 포함됩니다. 사이트 또는 응용 프로그램을 나타내는 데 사용할 방법은 무엇입니까? 그리고 어떤 작업을 포함할 계획입니까? 재설계할 기존 애플리케이션이 있는 경우 먼저 현재 버전에서 전체 테스트를 실행하여 해결해야 할 주요 사용성 문제를 찾을 수 있습니다. 새로운 디자인으로 작업하는 경우 스케치 또는 종이 프로토타입(예: 인쇄된 와이어프레임 패킷)을 사용하여 페이지와 같은 새로운 인터페이스 요소를 나타낼 수 있습니다. UI의 이러한 저충실도 표현을 통해 프로젝트 팀 간에 아이디어를 신속하게 생성하고 토론할 수 있으며 참가자와 함께 아이디어를 빠르게 반복할 수 있습니다(스케치 및 와이어프레임에 대한 자세한 내용은 10장 및 11장 참조). 고도의 상호작용 요소가 포함된 새로운 디자인으로 작업할 때 디자인의 탐색 흐름을 현실적으로 시뮬레이션하는 프로토타입을 만드는 것이 더 나을 수 있지만 전면적인 개발이 시작되기 전에 빠르게 만들 수 있습니다(자세한 내용은 12장 참조). 프로토타이핑). 포함하는 페이지는 선택한 작업과 밀접하게 연결됩니다. 프로토타입을 사용하여 사용자와 테스트할 계획이라면 작업의 기본 페이지와 중간 페이지 및 대체 경로를 계획해야 합니다. 각각에 대해 자세히 설명할 필요는 없지만 사용자가 해당 방향으로 이동하는 경우 응답을 계획해야 합니다. 때때로 이는 특정 경로를 사용할 수 없다고 알리고 사용자에게 이전 페이지로 돌아가 다시 시도하도록 요청하는 페이지처럼 간단할 수 있습니다. 작업의 세부 사항은 토론 가이드(아래에서 설명)에 들어가지만 포함하는 작업의 유형에 따라 범위가 크게 달라질 수 있으므로 계획 중에 목록을 요약하는 것이 좋습니다.

230

13장: 사용자와 디자인 테스트

심층 분석 스케치를 사용한 반복 설계 및 테스트에 대한 자세한 내용과 디자인 프로세스의 창의성에 대한 진정으로 영감을 주는 통찰력을 보려면 Sketching User Experiences: Getting the Design Right and the Right Design, by Bill Buxton(Morgan Kaufmann, 2007)을 읽어보세요. 종이 프로토타이핑 기술에 대한 자세한 내용은 Carolyn Snyder(Morgan Kaufmann, 2003)의 Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces를 참조하십시오.

목록이 너무 길고 우선 순위를 정하는 방법을 잘 모르는 경우 고려해야 할 몇 가지 우선 순위는 다음과 같습니다. 디자인이 일부 기존 규칙을 위반하는 영역. 당신은

"장바구니"가 아니라 "좋은 가방"이라고 부르나요? 사용자에게 명확한지 확인하는 것이 좋습니다. 디자인 결정이 정치적으로 부과되는 영역. 당신은 가질 수 있습니다

특정 디자인 방향이 옳다는 강한 느낌이 들지만 이해관계자나 프로젝트 팀의 다른 구성원 간에 많은 의견 차이가 있음을 알고 있습니다. 보는 것은 믿는 것입니다. 사용성 문제가 분실과 같은 심각한 결과를 초래할 수 있는 영역

판매 또는 최악의 경우 생명을 잃습니다(약물 투약과 관련된 건강 관리 응용 프로그램이 이에 대한 좋은 예입니다). 다음으로 사용자가 각 작업을 수행하는 동안 수집하려는 정보를 결정합니다. 어떤 정보를 수집하고 있습니까? 우리는 측정 세트가 더 작은 경향이 있는 정성적 사용성 테스트에 초점을 맞추고 있습니다. 대부분의 경우 사용자가 직면할 수 있는 문제, 사용자가 경험할 수 있는 다양한 수준의 불만 및 특정 문제의 심각성을 이해하려고 합니다. 예를 들어 게시된 스토리가 복구할 수 없는 손실을 초래하는 간헐적인 문제(모든 사용자가 경험하지는 않음)가 있을 수 있습니다. 그것은 확실히 귀하의 보고서에서 가장 우려되는 문제입니다!

사용성 테스트

231

테스트 중인 사용자 또는 테스트 라운드 전반에 걸쳐 어느 정도 관점을 얻으려면 테스트의 일부로 수집하는 것을 고려해야 할 몇 가지 측정값이 있습니다. 다시 말하지만, 더 적은 수의 사용자로 정성적 테스트를 수행하는 경우 이 숫자를 너무 멀리 가져가지 마십시오(5명의 사용자만 테스트하는 경우 평균 숫자를 계산하는 것은 의미가 없습니다). 다음 조치는 사용자에게 발생한 일부 문제의 심각도를 이해하는 데 도움이 될 수 있습니다. 성공 - 사용자가 작업을 완료할 수 있었던 정도입니다. 사용자를 살펴보는 경우 작업을 성공적으로 완료할 수 있는 사용자 수인 "성공률"을 참조할 수도 있습니다. 간단하게 들리지만 이것은 성공의 의미를 정의해야 함을 의미합니다! 덜 형식적인 테스트의 경우 사용자가 최종 상태를 달성하면 작업이 성공했다고 말할 수 있습니다(예: 편집자가 스토리를 성공적으로 승인함). 진행자에게 필요한 다양한 수준의 개입을 기록하여 보다 공식적으로 성공을 추적할 수 있습니다. 레벨 1 프롬프트: 테스트 진행자는 참가자의 질문에 응답하지만 추가 세부 정보는 제공하지 않습니다. 예를 들어 참가자가 "이 버튼일 것 같은데 클릭해야 할까요?"라고 묻습니다. 진행자는 "계속해서 시도해 보십시오."라고 응답합니다. 레벨 1 프롬프트만으로는 실패한 작업을 의미하지는 않지만 참가자가 그 시점에서 약간의 불확실성을 경험하고 있을 수 있으므로 참고하는 것이 좋습니다. (이것이 첫 번째 작업이라면 단순히 사용성 테스트에 익숙하지 않기 때문일 수도 있습니다.) 사용자가 작업을 완료하는 데 프롬프트가 필요하지 않거나 한두 개의 레벨 1 프롬프트만 필요한 경우 사용자가 소요한 시간이 귀하의 인내심 수준을 훨씬 초과했다고 생각하지 않는 한 해당 단계를 성공한 것으로 간주할 수 있습니다. 사용자. 레벨 2 프롬프트: 테스트 진행자는 참가자가 어려움을 겪고 있는 것을 보고 질문에 대한 응답으로 힌트를 제공합니다. 이 수준에는 직접 답변을 제공하는 것은 포함되지 않지만 응답은 사용자의 접근 방식에 영향을 미칠 수 있습니다. 예를 들어 진행자는 "이 페이지에 이 작업과 관련이 있다고 생각되는 다른 항목이 있습니까?"라고 말할 수 있습니다. 여기에서 작업이 실패(예: 두 번째 프롬프트에서) 또는 "어려움과 함께 성공"으로 표시되기 전에 제공될 수 있는 수준 2 프롬프트 수에 대한 제한을 설정할 수 있습니다.

232

13장: 사용자와 디자인 테스트

수준 3 프롬프트: 참가자는 좌절감에 포기했거나 실생활에서 작업에 직면했다면 포기했을 지점까지 어려움을 겪었습니다. 이 경우 퍼실리테이터는 작업의 일부에 대해 직접 답변을 제공합니다. 예를 들어 "이 이야기를 승인하려면 제출 버튼을 클릭합니다."라고 말합니다. 참가자에게 수준 3 프롬프트가 필요한 경우 작업은 일반적으로 실패로 표시됩니다. 사용자 만족도 - 물론 작업을 성공적으로 완료했지만 그에 대해 어떻게 느꼈습니까? 각 작업 후에 몇 가지 후속 질문을 포함하면(타이머를 끈 상태에서) 나중에 사용자가 얼마나 행복하거나 좌절하는지 이해할 수 있습니다. 말하기 싫어하는 사람을 만나면 이것이 그들의 영혼을 들여다볼 수 있는 주요 창구가 될 수 있습니다. 표 13.1에는 포함할 수 있는 몇 가지 작업 후 질문의 예가 나와 있습니다. 표 13.1: 13.1 사용자 표

만족도 질문에 동의하지 않음

동의하지 않는다

동의하지도 동의하지도 않음

동의하다

적극 동의

작업을 완료하는 데 예상보다 오래 걸렸습니다.

삼

작업을 완료하기 쉬웠습니다.

삼

이 작업을 완료하려고 할 때 좌절감을 느꼈습니다.

삼

사용자 만족도 질문 사용자 진술 - 이것은 메트릭이 아니지만 사용자가 자발적으로 수집하는 주요 세부 정보 집합입니다. 보고서에 사용자 인용문을 추가하는 것은 이해관계자가 데이터를 해석하는 데 그치지 않고 통찰력을 이끌어내는 인식을 이해하도록 결과에 인적 요소를 가져오는 강력한 방법입니다. 테스트 중에 진술을 질문이나 의견으로 표시할 수 있습니다. 보고서에서 이를 분할할 것입니다(뒤에 나오는 "인사이트 생성" 섹션 참조).

모집 및 물류 이제 연구의 개요가 있고 각 그룹에서 필요한 참가자 수를 알았으므로 몇 가지 테스트 일정을 잡을 시간입니다!

사용성 테스트

233

목록 생성 연구 계획을 만들 때 포함하려는 사용자 유형을 설명했습니다. 이 개요를 초점으로 사용하여 잠재적 참가자 목록을 생성할 수 있습니다. 이상적으로는 이름, 이메일 주소 및 전화번호를 찾고 있습니다. 다음은 해당 목록을 수집하기 위해 사용할 수 있는 몇 가지 소스입니다. 관련 회사 사이트의 등록된 사용자 고객 연락처 정보 관련 사이트 또는 그룹에 보낸 연구에 대한 게시물에 대한 응답

당신의 연구 주제에. 이는 Craigslist에 게시하는 것과 같이 광범위할 수도 있고 회사 업계를 중심으로 하는 토론 그룹과 같이 대상이 될 수도 있습니다. 시험과 관련된 지인들에게 보내는 이메일.

개인적으로 알고 있는 주제를 사용하면 결과가 편향될 수 있으므로 관심이 있을 수 있는 다른 사람에게 초대장을 전달하도록 요청하고 싶습니다. 이런 종류의 입소문은 잠재적인 참여자를 찾을 수 있는 좋은 방법이지만 이러한 후보자는 여전히 심사를 거쳐야 한다는 점을 명심하십시오. (당신이나 팀의 다른 사람들이 사람들을 잘 알고 있다면, 그들이 빠져나가도록 유혹할 수 있습니다.) 참가자를 사전 검증하는 짧은 설문 조사 형식의 요청

관련 사이트 또는 회사 사이트의 광고 공간

최종 참가자를 찾을 수 있습니다. 물리적 장소와 밀접한 관련이 있는 사이트의 경우 사이트에서 대부분의 심사 및 예약 작업을 수행할 수도 있습니다. 귀하를 위해 스크리너를 운영할 수 있는 제3자 채용 회사

그리고 스케줄링을 도와줍니다. 이것은 비용이 많이 드는 옵션일 수 있지만 모집하기 어려운 특정 참가자 유형을 찾고 있거나 많은 사람을 모집해야 하는 경우 프로세스의 이 부분을 아웃소싱하여 많은 시간을 절약할 수 있습니다. 일부 회사는 특정 분야(예: 의료)를 전문으로 하며 높은 참여율을 장려하는 방법에 대한 지침을 제공할 수 있습니다.

234

13장: 사용자와 디자인 테스트

여기에서 창의력을 발휘할 준비를 하십시오. 공감 능력을 사용하여 대상 사용자처럼 생각하십시오. 어디에서 그들을 찾을 수 있고 그들이 가입하도록 동기를 부여할 수 있는 것은 무엇입니까? 이 마지막 질문은 다음 주제로 이어집니다. 보상 선택 사용자 그룹 구성원이 연구에 참여하도록 동기를 부여하는 것은 무엇입니까? 그것은 돈일 수도 있고 아닐 수도 있지만 참가자들은 그들의 시간에 가치 있는 것을 원합니다. 내부 사용자를 위한 사이트에서 작업하는 경우 연구 참여를 위해 회사 시간 사용을 승인해야 하는 관리자에게 그 가치를 입증해야 합니다. 이 경우 더 나은 시스템이 자신의 그룹에 대한 혜택과 직접적으로 관련되는 방식에 초점을 맞출 수 있습니다. 잠재적인 외부 사용자와 함께 작업하는 경우 보상 방법을 결정할 때 염두에 두어야 할 몇 가지 변수는 다음과 같습니다. 청중이 얼마나 일반적입니까 아니면 구체적입니까? 널리 사용되는 전자 상거래 사이트의 경우 청중은 일반적일 가능성이 높으며 수표나 기프트 카드 형태로 더 낮은 보상 비율을 제공할 수 있습니다. 변호사가 사용하는 애플리케이션의 경우 귀하의 보상은 높은 가치가 있어야 하며 보상으로 금전 이외의 것을 사용하는 것이 더 나은 경우가 많습니다(예: 프리미엄 서비스 액세스). 그러한 경우 수표는 실제로 모욕처럼 보일 수 있습니다. 시간당 $250를 청구하는 사람은 돈을 받고 참여할 가능성이 없습니다. 고가 품목 고객과 함께 작업하는 경우 특정 청중으로 취급하고 충분한 보상을 제공하십시오. 주제가 얼마나 많은 관심을 불러일으킬 것 같습니까? 일부 참가자는 테스트 중인 영역에서 어떤 일이 일어나는지 보고 싶어 참여할 것입니다. 관심이 높은 영역이라면 추가 보상을 전혀 제공할 필요가 없을 수 있습니다. 보상은 아직 다른 사람이 볼 수 없는 것에 액세스할 수 있는 것입니다. 그러나 여기서 현실적입니다. 주제에 대해 그렇게 열광적일 수 있지만 사용자는 그럴까요? 사람들이 주로 대의에 무언가 기여하기를 원하기 때문에 참여할까요? 일부 그룹은 이타적인 목적으로 동기를 부여받으며 참여를 위한 금전 제공으로 꺼질 수 있습니다. 커뮤니티(온라인 또는 오프라인)를 개선하는 무언가를 테스트하는 경우 경험이 함께 모이는 것이라면 더 많은 참여와 더 행복한 참가자를 얻을 수 있습니다.

사용성 테스트

235

돈을 받는 것보다. 이 경우 공개적으로 인정하고 사이트가 완성되면 그들이 참여함으로써 할 수 있었던 기여를 알려줌으로써 감사를 표할 수 있습니다. 참여가 얼마나 불편할까요? 참가자가 현장을 방문해야 하는 경우 더 큰 보상을 제공할 준비를 하십시오. 집이나 사무실에서 편안하게 원격 테스트에 참여하는 경우 요구 사항이 더 적습니다. 물론 시간도 이 등식에 포함되며 사람들은 30분보다 2시간이 더 높은 보상을 기대할 것입니다.

가능한 보상 형태 귀하의 상황은 다양하지만 제안할 수 있는 몇 가지 사항은 다음과 같습니다. 일반 사용자 그룹과의 30분 원격 테스트에 $50 일반 사용자 그룹과의 1시간 대면 테스트에 $80–$120 $180 –금전적 보상에 잘 반응할 것으로 판단되는 특정 사용자 그룹과 함께 1시간 동안 테스트하는 경우 $250 3개월 동안 무료 서비스, 회사에서 만든 무료 제품(아직 모든 사람이 사용할 수 없는 제품), 독점 멤버십 예를 들어 변호사, 의사 및 영업 임원과 같이 수표에 감명을 받지 않을 것 같은 특정 사용자 그룹을 위해 6개월 동안 그룹을 유지합니다. 사용자 그룹에 동기를 부여하는 것은 무엇입니까?

스크리닝 스크리너는 잠재적 참가자를 예약하기 전에 사용할 수 있는 일종의 설문지입니다. 대표 사용자의 정의에 맞도록 합니다. 질문은 응답자가 테스트 중인 기능의 현재 사용자인지 확인하기 위한 것입니다.

ing 또는 미래의 사용자가 자신의 사용자 그룹 중 하나 이상에 적합한지 확인 해당 사용자 그룹 내에서 참가자를 적절하게 혼합하도록 돕습니다.

236

13장: 사용자와 디자인 테스트

왜곡될 수 있는 경험이 있을 수 있는 특정 응답자 제외

결과 참가자가 도착하기 전에 알아야 할 주요 세부 정보 수집

(선택 사항) 스크리너는 모집자가 전화로 읽을 수 있는 소개 스크립트를 포함해야 하며 참가자를 자격을 갖추거나(적합한 경우) 통화를 종료하는 시기에 대한 지침(적합하지 않은 경우)을 포함해야 합니다. 스크리너의 최종 사용자는 참가자를 모집하는 사람 또는 온라인 양식을 사용하여 스크리닝하는 경우 잠재적 참가자가 됩니다. 둘 다 가능하지만 일반적으로 양식이나 이메일을 사용하여 관심 있는 사람들의 목록을 수집한 다음 전화로 선별하는 것이 가장 좋습니다. 왜? 불행하게도 사람들은 누군가에게 직접 대답할 때보다 종이에 자신을 잘못 표현하기가 더 쉽고 자격이 없더라도 누군가가 연구에 참여하려고 시도하는 것이 드문 일이 아니기 때문입니다. 특히 보상이 관련된 경우! 검사자는 또한 결과에 영향을 미칠 수 있는 지식을 가진 사람들을 걸러내야 합니다. 예를 들어, 일반적인 질문은 응답자가 시장 조사 분야에서 일하는지 여부입니다. 왜냐하면 그들은 일반적으로 연구에 너무 익숙하고 결과적으로 당신에게 진정한 반응을 줄 가능성이 없기 때문입니다. 디자인 정보 공유에 대한 우려가 있는 경우 경쟁사에서 일하는 사람들을 걸러낼 수도 있습니다. 다음은 B2B 웹 주문 애플리케이션의 스크리너에서 볼 수 있는 질문의 몇 가지 예입니다. 이 경우 웹을 통해 사용하고 구매하는 데 익숙하고 스스로 그렇게 할 가능성이 있는 사용자 그룹을 대상으로 합니다. 일부 질문은 참가자를 선별하기 위한 것이고 질문 4와 같은 다른 질문은 자격을 갖춘 참가자를 올바른 사용자 그룹에 배치하는 데 더 적합합니다. 1. 귀하의 연령대는 어떻게 됩니까? [18세 이상의 연령대 혼합] a. 18세 미만

끝내다

비. 18~24 다. 25–34 라. 35–44마. 45–54 바. 55 이상

사용성 테스트

237

2. 집에서 인터넷을 얼마나 자주 사용합니까? ㅏ. 절대

끝내다

비. 한 달에 한 번 미만

끝내다

씨. 한 달에 몇 번 d. 적어도 일주일에 한 번 e. 일주일에 여러 번 f. 하루에 한 번 이상 3. 개인적으로 온라인에서 제품을 마지막으로 구매한 것이 언제입니까? ㅏ. 최근 1개월 이내 b. 1~3개월 전 c. 3~6개월 전 d. 6~12개월 전

끝내다

이자형. 12개월 이상 전

끝내다

에프. 온라인에서 개인 구매를 한 적이 없습니다.

끝내다

4. pseudocorporation.com을 마지막으로 방문한 것이 언제입니까? [그룹 A는 자주 사용하지 않거나 사용하지 않습니다. 그룹 B는 자주 사용하는 사용자]

238

ㅏ. 나는 사이트를 방문한 적이 없다

그룹 A 확인

비. 지난달 이내

그룹 B 확인

씨. 1~3개월 전

그룹 B 확인

디. 3~6개월 전

그룹 B 확인

이자형. 6~12개월 전

A 또는 B 확인

에프. 12개월 이상 전

그룹 A 확인

13장: 사용자와 디자인 테스트

당신은 해고되었습니다 Terminate는 거칠게 들리는 단어입니다. 응답자가 테스트에 적합하지 않기 때문에 통화를 종료해야 한다는 의미입니다. 당신은 응답자가 이것에 대해 기분 나빠하는 것을 원하지 않지만 그녀가 적합하지 않다는 것을 알았을 때 후속 질문을 하는 데 그녀의 시간을 낭비하지도 않을 것입니다. 이를 처리하는 방법에는 여러 가지가 있습니다. 한 가지 좋아하는 것은 단순히 그녀가 자격이 있는 그룹이 이미 채워졌다고 말하고 그녀가 관심을 가질 만한 다른 테스트가 있으면 나중에 그녀에게 연락할 수 있는지 묻는 것입니다.

공간 및 장비 계획 이 시점에서 원격 또는 대면 테스트 여부와 각 참가자에게 필요한 시간을 알 수 있습니다. 최종 결정해야 할 몇 가지 다른 결정은 다음과 같습니다. 테스트 장소: 관찰실이 있는 임대 공간, 회사 현장의 회의실 또는 잠재적 사용자가 있을 위치? 테스트할 컴퓨터 설정과 함께 2~3명이 편안하게 들어갈 수 있는 조용한 장소를 계획하십시오. 진행자 외에 필요한 직원: 예를 들어 테스트 중에 메모 작성자가 정보를 기록하도록 하여 시간을 절약하고 정확도를 높일 수 있습니다. 다른 가능성으로는 인사 담당자(들어오는 참가자를 만나고, 사람들이 기다리는 동안 설문지를 나눠주고, 참가자를 시험장 안팎으로 안내하기 위해) 및 시험 중에 문제가 발생할 경우 IT 지원을 제공할 사람이 있습니다. 테스트 녹화 방법: 다양한 방법을 사용할 수 있지만 TechSmith의 Morae 및 Camtasia Studio와 같은 소프트웨어를 사용하면 화면을 쉽게 녹화할 수 있으며 Morae에는 추가 웹캠 비디오 및 오디오 통합 기능이 있습니다.

토론 가이드 작성 마지막으로 테스트 자체에 필요한 자료를 모아야 합니다. 연구 계획에 일반적인 작업이 나열되어 있습니다. 이제 작업에 대한 실제 텍스트와 지침을 마무리해야 합니다. 여기에는 적어도 두 개의 패킷이 있습니다. 하나는 테스트 진행자용이고 다른 하나는 참가자용입니다(각 테스트마다 하나씩 포함할 수 있는 충분한 사본이 있음).

사용성 테스트

239

퍼실리테이터가 참가자에게 읽어줄 수 있는 소개 스크립트로 시작합니다. http://usability.gov/templates에서 많은 좋은 예를 볼 수 있습니다.

Surfing Usability.gov는 광범위한 사용자가 액세스할 수 있는 사이트 개발을 장려하기 위한 이니셔티브의 일환으로 미국 보건복지부가 개발한 사이트입니다. 참가자가 녹화하기 전에 서명해야 하는 비디오 동의서(Microsoft Word 형식)의 예를 포함하여 사용자 중심 설계에 도움이 되는 훌륭한 참조 자료 세트가 있습니다: http://www.usability. gov/templates/docs/release.doc

지침에는 참가자가 테스트 중인 작업을 성공적으로 완료하는 데 필요한 모든 특정 정보가 포함되어야 합니다. 작업에 많은 데이터 입력 및 개인화가 필요한 경우 사전에 몇 가지 정보를 설정하고 참가자에게 사용할 미리 결정된 데이터를 제공하십시오. 예를 들어 로그인이 관련된 경우 모든 참가자가 동일한 로그인 자격 증명 집합을 사용하게 할 수 있습니다. 쉽게 채울 수 있도록 작업 지침에 이 모든 정보가 명확하게 포함되어 있는지 확인하십시오. 다음은 토론 가이드에서 콘텐츠 편집자의 작업이 어떻게 더 구체적이 되는지에 대한 예입니다. 계획의 원래 작업은 "편집할 준비가 된 기사 찾기"입니다. 토론 가이드에서 이는 다음과 같이 됩니다. 서론 귀하의 관리자는 귀하에게 회사 웹 사이트에 기고하는 작가가 게시한 기사를 편집하고 승인하는 새로운 역할을 맡도록 요청했습니다. 기사를 승인하면 뉴스 영역의 사이트에 게시됩니다. 귀하와 세 명의 다른 편집자는 항목이 회사의 메시지와 일치하는지 확인하기 위해 항목을 승인할 것입니다. 편집 도구에 대한 다음 로그인 정보가 제공되었습니다: 사용자 이름: grobertson 비밀번호: come2gether

240

13장: 사용자와 디자인 테스트

각 작업을 소리내어 읽고 편집 도구를 사용하여 완료하십시오. 작업 1 도구에 로그인하고 편집할 준비가 된 기사를 엽니다.

위에서 볼 수 있듯이 명확한 최종 상태인 열린 기사로 끝나도록 작업을 다소 변경했습니다. 이러한 종류의 조정은 이 세부 수준으로 이동하고 성공을 측정하는 방법에 대해 생각할 때 일반적입니다. 계획 섹션에서 설명한 사용자 만족도 질문으로 각 작업을 수행할 수도 있습니다. 일반적으로 사용자가 앞을 내다보고 싶어하지 않도록 각 작업에 자체 페이지를 제공하는 것이 가장 좋습니다. 요약하면 시험 자료에는 다음이 포함되어야 합니다.

페이지 참조) 퍼실리테이터를 위한 토론 가이드, 소개 스크립트 포함 참가자를 위한 토론 가이드, 세부 작업 및 사용자 만족도

질문 전담하는 사람이 있는 경우 메모하는 형식입니다. 이것은 할 수 있습니다

테스트 소프트웨어에 내장된 로깅 도구에서 주요 정보(예: 필요한 프롬프트 유형)를 확인하기 위한 인쇄된 템플릿에 응답을 입력하기 위한 스프레드시트에 이르기까지 다양합니다. 테스트 전에 이를 설정하는 데 약간의 추가 시간을 할애하면 일관된 결과를 얻고 녹음을 검토하는 데 많은 시간을 절약할 수 있습니다. 선택적으로 설문지. 때때로 참가자들은 일찍 와서

약간의 대기 시간 - 약간의 추가 정보를 수집할 수 있는 절호의 기회입니다. 이전에 설문조사를 디자인했다면 여기에서 재사용하지 않겠습니까? 보상 방법은 종료 시 참가자에게 제공됩니다.

테스트(봉투에 든 돈, Visa 기프트 카드와 같이 널리 통용되는 기프트 카드 등). 테스트 후 아무것도 나눠주지 않는 무료 서비스와 같은 보상을 선택한 경우 참가자에게 늦어도 다음 날까지 후속 조치를 받을 것이라고 안심시키십시오. 테스트 중에 종이 프로토타이핑을 사용하는 경우 작업할 재료도 있습니다. 첫 번째 테스트를 시작하기 전에 쉽게 다룰 수 있도록 세트를 준비했는지 확인하십시오.

사용성 테스트

241

퍼실리테이터의 임무는 참가자에게 프로세스를 소개하고 초기 질문에 답한 다음 참가자가 가능한 한 자연스럽게 행동할 수 있도록 하면서 가능한 통찰력을 얻는 것입니다. 사용자에게 테스트 중에 마치 혼잣말을 하는 것처럼 크게 생각하도록 요청하십시오(그리고 조용히 작업을 시작하면 그렇게 하도록 부드럽게 상기시켜 주십시오). "소리내어 생각하기" 기술은 사용자 행동에 대한 가장 많은 통찰력을 얻는 방법입니다. 기억이 정확하지 않을 때 참가자들에게 나중에 다시 만들어 달라고 요청하는 것과 비교하여 작업 자체 중에 듣는다면 그들의 문제 해결 및 사고 과정에 대해 많은 것을 배울 수 있습니다. 또한 참가자에게 너무 빨리 "정답"을 제공하지 않도록 주의하십시오! 사용성 테스트를 수행할 때 가장 어려운 부분 중 하나는 엄선된 참가자가 작업에 대해 힘겹게 고군분투하는 것을 지켜보고 그들이 고군분투하도록 내버려 두는 것입니다. 결국, 당신은 공감하는 개인이기 때문에 아마도 이 분야에 있는 것입니다. 당신은 사람들을 돕고 싶습니다. 따라서 누군가가 점점 더 좌절하고 도움을 요청한 다음 "혼자서 시도한다면 어떻게 하시겠습니까? "라고 대답하는 것을 보는 것은 약간 가학적으로 느껴질 수 있습니다. 참가자가 일하면서 당신에게 질문을 할 때마다 대답하기 전에 몇 박자를 참으십시오. 참가자는 테스트 시작 직후에 질문을 할 가능성이 가장 높으며, 특히 옆에 앉아 작업하는 것이 어색한 경우에는 더욱 그렇습니다. 당신이 대화보다는 관찰을 위해 그곳에 있다는 것을 알게 되면 그들은 종종 당신의 존재보다 작업에 더 집중하기 시작할 것입니다. 다음은 참가자 질문 및 제안된 응답의 몇 가지 예입니다. 참가자: "이 탭인 것 같습니다. 여기로 가야 하나요?" 진행자:

"가서 해봐."

참가자: "여기로 가야 하나요?" 진행자:

"이 시점에서 그렇게 할 것이라고 생각하십니까?"

참여자: “댓글을 이렇게 쓰는 건가요?” 진행자:

고요. 그녀는 참가자에게 미소를 지으며 그의 화면을 기대에 차 바라보며 친근하고 편안한 표정을 짓습니다.

그래서 언제 개입합니까?

242

13장: 사용자와 디자인 테스트

사용자가 스스로 작업할 때 현실적으로 생각하는 것보다 이미 더 많은 노력을 기울였고 사용자가 왜 잘못된 길을 가게 되었는지 알게 되었다고 느낀다면 계속 진행할 때입니다. 특히 수행해야 할 작업이 더 많은 경우에는 더욱 그렇습니다. 그리고 당신은 그가 좌절감을 시험의 나머지 부분까지 가져가는 것을 원하지 않을 것입니다. 6장에서 우리는 사용자 인터뷰에서 유도 질문을 피하는 것의 중요성에 대해 언급했습니다. 여기에도 동일하게 적용됩니다. 자신이 디자인에 너무 가깝다고 생각하고 비판으로 인해 방어적으로 대응할 수 있다고 생각되면 메모를 하는 동안 다른 사람을 코칭하여 촉진하는 것을 고려하십시오.

결과 분석 및 제시 모든 테스트를 마쳤으며 이제 살펴볼 데이터가 산더미처럼 쌓여 있습니다. 그러나 이미 관련이 있다고 생각하는 몇 가지 주요 결과가 있으며 프로젝트 팀은 어떻게 진행되었는지 알고 싶어합니다. 팀을 위해 가장 먼저 생각나는 테이크아웃에 대한 간단한 구두 개요를 계획할 수 있습니다. 그것은 당신이 알아차린 몇 가지 경향을 말로 표현하고 차후 보고를 위한 단계를 설정하는 데 도움이 될 수 있습니다. 이것이 첫인상이며 데이터를 더 자세히 분석하려면 시간이 필요하다는 점을 전달해야 합니다. 문제가 있을 수 있는 위치를 전체적으로 파악하기 전에 여기에서 권장 사항으로 뛰어들고 싶지는 않을 것입니다. 데이터를 가지고 앉을 시간이 있으면 다음 두 가지 사항을 염두에 두고 데이터를 검토하십시오. 분석할 수 있는 시간입니다. 세부 사항에서 길을 잃고 모든 것을 포함하려고 하기 쉽습니다. 항상 그렇듯이 중요한 결과를 알아낼 때 테스트와 목표를 주시하십시오. 10시간의 테스트 녹화 시간과 전체 보고서를 작성하는 데 5일이 주어진다면 모든 테스트의 비디오를 보는 데 시간을 할애하고 싶지 않을 것입니다. 메모 작성자에게 의존하고 주로 비디오로 돌아가서 기억하는 주요 인용문이 올바르게 기록되었는지 확인하십시오. 결과가 사용되는 방식. 이것은 종종 과소평가될 수 있는 중요한 세부 사항입니다. 20페이지의 아름다운 보고서를 만들 수 있지만 그 중 많은 마일리지를 얻을 가능성이 있는 페이지는 실행 요약입니다.

사용성 테스트

243

비즈니스 이해 관계자가 세부 정보를 확인하려는 경우 보고서 자체가 결과를 전달하는 주요 방법이 될 수 있습니다. 두 가지 수준의 세부 정보(이해관계자용과 프로젝트 팀용)가 필요하다고 생각되면 더 눈에 잘 띄고 이해하기 쉬우며 우선 순위가 지정된 방식으로 주요 결과에 도달하는 보고서의 프레젠테이션 버전을 만드는 것도 고려하십시오. 자세한 내용에 관심이 있는 사용자는 전체 보고서를 참조할 수 있습니다. 문제의 우선 순위 지정 테스트가 끝나면 이해하고 우선 순위를 지정해야 할 사용성 문제 목록이 길어질 수 있습니다. 다음은 오류의 심각도를 판단하는 데 도움이 되는 몇 가지 특성입니다. 결과. 문제 발생의 부정적인 결과. 예를 들어 사용성 문제로 인해 참가자가 데이터를 손실한 경우 높은 등급이 보장됩니다. 그녀가 복잡한 양식을 작성하는 데 10분을 소비하고 실수로 그녀를 다른 페이지로 연결하는 링크를 선택했다고 가정해 보겠습니다. 그녀가 브라우저의 뒤로 버튼을 누르면 그녀의 데이터가 사라집니까? 복구 가능성. 참가자가 문제를 만난 후 복구할 수 있는 정도(예: 다른 경로를 통해 쉽게 돌아갈 수 있습니까?) 발생 빈도. 당신은 많은 사람들과 함께 일하지 않기 때문에 이것은 엄격함의 표시로 단독으로 사용되지 않습니다. 그러나 5명이 같은 실수를 해서 덜 최적의 경로로 이끌면 더 높은 우선순위를 고려해야 한다는 좋은 신호입니다. 합리적인 원인. 자주 발생하는 문제는 아니지만 귀하의 사용자 그룹에 적합한 사람이 문제를 일으킨 경우 합리적 이유가 있고 오류에 대한 명확한 원인이 있는 경우 해당 문제를 고려하여 권장 사항을 제시해야 합니다. 통찰력 생성 수집한 문제 외에도 프로젝트 팀에 귀중한 통찰력을 가져올 수 있는 사용자의 진술이 풍부할 것입니다. 6장에서 설명한 것처럼 친화도 다이어그램 연습은 이러한 진술을 수집하고 공동으로 패턴을 식별하는 훌륭한 방법입니다.

244

13장: 사용자와 디자인 테스트

다음은 사용자 진술을 분류할 수 있는 몇 가지 방법입니다(자세한 내용은 6장의 "상황에 맞는 조사" 섹션 참조). 목표 정신 모델 아이디어 및 기능 요청 좌절 해결 방법 가치 진술 기쁨 좋은 걸 놓치고 싶지 않아!) 기대(특히 놓쳤을 때)

통찰력과 권장 사항 모두 긍정적인 결과도 포함해야 합니다. 사용성 테스트 보고서는 종종 너무 부정적인 것으로 보이는데, 그 주된 이유는 연구원이 잘 진행되고 있는 것보다 수정해야 할 사항에 대한 논의를 우선시하기 때문입니다. 좋은 점에 대해 토론하는 데 시간을 투자하면 모든 사람에게 전반적인 보고서 경험이 향상됩니다. 또한 디자인 팀이 결과에 참여하는 데 도움이 되며 디자인을 더욱 개선할 수 있게 되어 기쁩니다.

권장 사항 만들기 분석을 시작하기 전에도 이미 테스트에서 발생한 문제를 해결하기 위한 몇 가지 좋은 아이디어가 머릿속에 있을 것입니다. 문제와 통찰을 파악하면서 그 과정에서 그것들을 스케치하여 잃어버리지 않도록 하십시오. 단 하나의 아이디어가 너무 일찍 이어져 더 많은 문제를 해결할 수 있는 다른 잠재적 접근 방식에 대한 관점을 흔들리지 않도록 주의하세요. 좋은 권장 사항은 가능하면 둘 이상의 문제를 해결해야 합니다. 문제를 그룹화할 수 있습니다.

문제 설명이 얼마나 상세하고 구체적인지에 따라 하나의 더 큰 권장 사항으로 함께 표시됩니다. 조기에 세부적인 설계를 피하면서 실행 가능하고 단순해야 합니다.

사용성 테스트

245

직설적이지만 거만하지 않은 언어를 사용하십시오. 전수

비판은 어려운 일입니다. 특히 테스트한 디자인에 직접 관여한 사람들에게는 더욱 그렇습니다. 문제를 과소평가하지 말고, 당신의 말이 건설적이고 정중하게 느껴져야 한다는 것을 명심하세요. 권장 사항은 시스템과 마찬가지로 최종 사용자를 대상으로 해야 합니다. 보고서를 마무리하면서 원래 목표를 달성했는지, 보고서를 사용할 다양한 사람들(이해관계자, 디자이너, 개발자)에게 결과를 가장 잘 제공할 수 있는 방법이 무엇인지 되돌아보고 자문해 보십시오. 개발자 이야기가 나와서 말인데, 이제 그들을 다시 전면에 내세울 때입니다. 다음 장에서는 디자인에서 개발로, 그리고 그 이상으로 전환할 때 염두에 두어야 할 사항을 다룰 것입니다.

246

13장: 사용자와 디자인 테스트

전환: 설계에서 개발로 그리고 그 너머로 우리는 여기서 어디로 갈까요? 프로젝트의 정의 및 설계 단계가 끝났습니다. 이제 뭐? 우수한 사용자 경험 디자인 프로세스는 결코 끝나지 않습니다. 그렇게 많은 정의와 디자인을 거친 후에 최종 프로젝트 결과물이 디자인한 사용자 경험이 되도록 하기 위해 어떻게 계속 참여하고 있습니까? 그리고 거기에서 어디로 가나요? 러스 웅거

247

이것이 끝입니다... ...책의. 가장 마지막 챕터입니다. 그러나 표면적으로는 사용자 경험 디자인 프로세스의 끝이 아닙니다. 프로젝트의 모든 이전 단계를 거치고 나면 작업이 완료되었으며 더 이상 기여할 것이 없다고 생각할 수 있습니다. 많은 경우에 UX 디자인 노력은 어딘가에 있는 누군가의 프로젝트 계획에 대한 작업으로 끝나며 작업 제품이 나머지 팀에게 전달된 후에는 항상 다른 프로젝트로 뒤섞이게 됩니다. 그 문을 닫고 새로운 것을 시작할 시간이지? 매우 잘못되었습니다! 최상의 사용자 경험 디자인이 생성되도록 하기 위해 여전히 많은 일을 할 수 있습니다.

시각적 디자인, 개발 및 품질 보증 경우에 따라 프로젝트 기반 작업 산출물을 받는 디자인 또는 개발 팀과 원활하게 작업할 수 있습니다. 때로는 다운스트림 작업 파트너가 질문에 답하고, 의견을 제공하고, 작업 중인 일부 설계 개념에 대해 도움을 주기 위해 귀하에게 의존합니다. (이것은 프로토타이핑처럼 들릴 수도 있습니다!) 이러한 작업 환경에서 사용자 경험 디자인은 이미 수용되고 있으며 팀은 이러한 컨설팅 작업을 수행할 시간을 줄 수 있는 선견지명이 있었을 것입니다. 그러나 많은 조직에서 사용자 경험 디자이너, 정보 설계자, 인터랙션 디자이너 등의 역할은 여전히 매우 생소합니다. 이러한 역할을 관리하는 방법이 명확하지 않을 수 있으며 참여 정도에 대한 결정은 사용자 경험 디자인을 완전히 이해하지 못하는 사람에게 떨어질 수 있습니다. 지속적으로 참여하는 방법을 찾는 것은 귀하에게 달려 있습니다.

248

14장: 전환: 설계에서 개발 및 그 이상으로

다음은 몇 가지 제안 사항입니다. 1. 그들에게 이 책을 한 권 사주세요. 2. 부끄러워하지 마세요. 3. 이 장의 나머지 부분을 읽고 참여하고 유용할 수 있는 기회를 찾으십시오. 4. 참여를 요청하고 귀하의 요청을 변호할 준비를 하십시오. 시각 디자인 또는 개발 팀이 회사와 해당 프로젝트의 왕이라는 것을 알 수 있는 다른 경우가 있으며 참여를 유지하는 것이 어려울 수 있습니다. 작업을 검토하고 규정 준수를 보장하기 위해 벽을 허무는 자신을 발견할 수 있습니다. 항상 그런 것은 아니지만 발생합니다. Behavior(www.behaviordesign.com)의 창립 파트너인 Christopher Fahey는 이 문제를 극복하는 데 익숙합니다. 그는 다음과 같은 조언을 합니다. 일부 조직은 엄격하게 구획화되어 있습니다. 초기 디자인 단계가 완료된 후 프로젝트 개발에 계속 참여하려면 시각적 디자인 및 개발 팀에 피드백 및 수정을 제공할 기회를 적극적으로 요구해야 합니다. 그들은 종종 단순히 당신에게 거기에 있으라고 요청할 생각조차 하지 않을 것입니다. 이상적으로는 프로젝트의 계획 및 예산 책정 단계에서 이 작업을 수행합니다. 그렇지 않은 경우 후속 개발 중에 디자인이 저하되지 않도록 문자 그대로 서비스를 자원해야 할 수 있습니다. 한 가지 요령은 단순히 비공식적으로라도 품질 보증 팀에 추가해 달라고 요청하는 것입니다. 버그 추적 도구. 그런 다음 개발자가 매일 확인하는 동일한 버그 수정 대기열에 비판과 편차를 추가할 수 있습니다.

물론 많은 프로젝트에는 품질 보증 팀의 사치가 없습니다. 완벽한 세상에서 모든 프로젝트에는 그러한 팀이 있을 것입니다. 그러나 실제로 QA가 항상 가능한 것은 아닙니다. 때로는 개발자가 개발하면서 스스로 QA를 수행하기도 합니다. 움츠러들게 만드는 것 외에도 이 사실을 알면 개발자와 협력하기 위해 더 열심히 노력해야 합니다.

시각적 디자인, 개발 및 품질 보증

249

협상의 기술 협상의 기술은 사용자 경험 디자이너로서의 역할에서 중요한 측면이 될 수 있습니다. 시각 디자이너 및 개발자와 같은 다운스트림 작업 파트너는 사용자 경험의 주요 부분에 어떤 영향을 미치는지 깨닫지 못한 채 작업에 대한 변경 사항을 자유롭게 사용할 수 있습니다. 누군가 "할 수 없다"고 말하는 경우 플랜 B를 제시할 준비가 되어 있어야 합니다. 훌륭한 협상 기술은 디자인 결정을 방어하는 데 도움이 됩니다(이는 완료) 사용자 경험이 완료될 수 있음을 다른 사람들에게 확신시킵니다. 또는 이러한 기술은 파트너와 협력하여 가능한 한 많은 사람의 요구를 충족하는 만족스러운 플랜 B 접근 방식을 만드는 데 도움이 됩니다. 협상에 대한 추가 통찰력은 Roger Fisher, William L. Ury 및 Bruce Patton(Penguin, 1991)의 Get to Yes: Negotiating Agreement Without Giving In(Penguin, 1991) 및 Selling to the VP of No, Dave Gray(XPLANE Corp. , 2003).

많은 소기업에서 특히 그러합니다. QA는 사치입니다. QA는 "모든 사람이 수행하지만 특히 개발자가 수행합니다"라고 Ascend Realty Solutions(www .ascendrealtysolutions.com)의 개발 책임자이자 책임자인 Troy Lucht는 말합니다. 모두가 참여를 시도하고 원하지만 테스트 스크립트 작성 전용 리소스가 없으면 가능한 마지막 순간까지 개발이 수행될 때 사람들에게 무엇을 테스트해야 하는지 알리는 것이 불가능할 수 있습니다. 대부분의 경우 사내 디자이너는 저와 마찬가지로 응용 프로그램을 잘 아는 사람이므로 더 많은 정보에 입각한 피드백을 제공할 수 있습니다. 믹스에 사용자 경험 디자이너를 추가하면 우리 소규모 팀의 작업이 정말 마무리될 것입니다.

사용자 경험 디자인 작업 제품에 테스트 스크립트 생성이 포함되지 않을 수 있지만 경우에 따라 생성한 와이어프레임 및 주석에 대해 테스트하여 모든 요소가 고려되고 정의된 모든 클릭 유도 문안이 올바르게 작동하는지 확인할 수 있습니다. 이 상황이 완벽하지는 않지만 QA가 존재하지 않을 때 유용할 수 있는 접근 방식입니다. 여기서 중요한 점은 사용자 경험 디자인이 작업 제품을 뒤집고 지식 이전을 수행했다고 해서 끝나는 것이 아니라는 것입니다. 귀하의 역할은 일시적으로 컨설팅 성격을 더 많이 맡을 수 있지만 아직 끝나지 않았습니다.

250

14장: 전환: 설계에서 개발 및 그 이상으로

사용자와 디자인 테스트(다시) 사용자 테스트를 이미 수행하지 않았습니까? 바라건대 이 질문에 예라고 대답할 수 있지만 항상 그런 것은 아닙니다. 불행하게도 이 특정 테스트 단계는 시작하기 전에 실제 사용자와 함께 설계 및 개발된 최종 사이트를 테스트하도록 지정되어 있습니다. 이를 통해 웹 사이트를 마지막으로 살펴보고 QA 테스트 중에 간과했을 수 있는 마지막 순간의 버그와 오류를 찾을 수 있습니다. 대상 사용자 집합을 식별한 후에는 위험이 높거나 사이트의 이전 반복에서 문제가 있을 수 있는 모든 시나리오에 대해 웹 사이트를 테스트할 수 있습니다. 이 테스트 라운드는 사이트를 시작할 준비가 되었는지 여부를 결정하는 데 필요한 정보를 제공할 수 있습니다. 이 테스트 중에 중요한 문제가 발견되면 업데이트하고 다시 테스트하는 것이 중요할 수 있습니다.

10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … 발사! “당신이 그것을 짓는다면 그들은 올 것입니다. …” 그 이론은 많이 언급되었고 거의 그만큼 자주 반증되었습니다. 가장 아름답고 만족스러우며 사용 가능한 응용 프로그램을 만들어 세상에 출시하고 두 달 후에 거의 아무도 그것을 채택하지 않는다는 것을 알게 될 수 있습니다. 무엇을 제공합니까? 사용자 채택은 목표로 삼고 있는 사용자 기반이 사이트 또는 애플리케이션을 사용하는 정도입니다. 사용자가 새 사이트를 찾을 수 있도록 검색 엔진 최적화(8장)의 모범 사례를 따르면 일부 채택 문제를 피할 수 있습니다. 사용자 채택은 또한 좋은 사용자 경험 디자인이 프로젝트가 끝난 후에도 중단되지 않거나 작업 중인 프로젝트로 제한된다는 것을 의미합니다. 마케팅, 고객 지원, 홍보 및 교육 팀이 사용자 채택에 종종 영향을 미치는 세 가지 요소를 지원함으로써 원활한 배포 및 사이트 또는 프로젝트에 대한 사용자 기반을 보장하도록 도울 수 있습니다. 개인 이점

10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … 발사!

251

지원 네트워크 의견

각각에 대해 차례로 자세히 살펴보겠습니다.

Personal Advantage 사용자에게 대답해야 할 가장 중요한 질문 중 하나는 "나에게 도움이 되는 것은 무엇입니까?"입니다. 귀하의 사이트가 훌륭하더라도 특정 유형의 사용자(또는 귀하가 식별한 페르소나 중 하나)에게 제공하는 고유한 이점을 신속하게 설명할 수 없다면 사용자 참여에 어려움을 겪을 수 있습니다. 몇 가지 이점은 직접적입니다. "이 카메라 기능을 사용하면 버튼을 한 번만 클릭하면 온라인 계정에 사진을 게시할 수 있습니다." 일부는 간접적입니다. "이 작업표 도구를 사용하면 회사에서 각 프로젝트에 소요되는 시간을 보다 쉽게 추적할 수 있습니다." 사용자에 대한 통찰력을 얻기 위해 귀중한 시간을 보냈습니다. 이제 그 통찰력을 사용하여 마케팅 부서가 메시지를 맞춤화하도록 돕습니다.

지원 사용자가 사이트에 대한 도움이 필요할 때 어떻게 얻습니까? 뛰어난 사용자 경험 디자인 노력이 제공하려고 하는 상황별 지원 외에도 이 질문에 대한 답변에는 교육 및 고객 지원도 포함됩니다. 사용자가 온라인 교육 대신 강의실 교육에 더 잘 반응할 수 있다고 생각하십니까? 일부 사용자는 교육을 건너뛰고 사이트 자체 내에서 필요한 모든 것을 갖기를 기대합니까? 실시간 채팅이 고객 지원을 위해 사용자에게 중요한 옵션입니까, 아니면 전화 및 이메일 지원에 만족합니까? 지원 노력은 까다로우며 사용자를 이해하면 고객 지원 및 교육 부서를 효과적으로 도울 수 있습니다.

252

14장: 전환: 설계에서 개발 및 그 이상으로

네트워크 의견 입소문은 주변에서 가장 중요한 영향 요인입니다. 고객의 회사와 현재 웹 사이트는 대상 사용자 그룹 내에서 어떤 종류의 평판을 가지고 있습니까? 여기에 대한 대답이 긍정적이라고 해도 노력이 필요하지 않다는 의미는 아닙니다. 평판에 있어 유지 관리는 항상 중요합니다. 다음 섹션으로 건너뛰기 위한 핑계로 긍정적인 응답을 사용하지 마십시오. 유지 관리에 관련된 노력이 상당할 필요는 없지만 평판 급락에서 회복하는 데 필요한 노력은 엄청날 수 있습니다. 약간의 TLC는 먼 길을 갈 수 있으므로 계속 읽으십시오. 대답이 부정적이면 인식을 개선하기 위해 진지한 노력을 기울여야 합니다. 사용자 커뮤니티에 연락하여 영향력 있는 사람이 누구인지, 그들이 선호하는 의사소통 방법, 청중에게 어떤 영향을 미치는지 파악한 다음 참여를 유도해야 할 수 있습니다. 소셜 네트워킹을 통해 사용자를 참여시키고 클라이언트, 회사 및 웹 사이트에 대한 의견에 영향을 미치는 방법에는 여러 가지가 있습니다. 고객이 이러한 커뮤니티에 참여할 기회를 식별하고 긍정적인 방향으로 이끌 수 있도록 도와주세요. 이 세 가지 요소가 모두 충족되고도 사용량이 여전히 낮은 경우 경쟁업체가 사용자의 요구를 충족하기 위해 수행하는 방법과 작업을 고려하십시오. 제품 또는 사이트를 어떻게 차별화할 수 있습니까?

출시 후 활동 지금은 우리가 살고 있는 흥미로운 시대입니다. 많은 회사가 자체적으로 또는 제품을 "베타" 상태로 출시하고 있습니다. 베타 출시는 일반적으로 필터링되지 않은 실제 사용자가 버그, 오류, 충돌 또는 기타 문제를 식별하는 데 도움이 되는 웹 사이트의 실시간 테스트 대상임을 의미합니다. 한때 베타는 일반적으로 개발자에게만 제공되었지만 이제는 사용자 커뮤니티 전체에 베타를 공개하는 것이 일반적인 관행이 되었습니다. 베타 단계 동안 사용자가 가질 수 있는 모든 문제를 기록하고 보고하도록 통신 방법을 설정하는 것이 필수적입니다. 발생하는 모든 유형의 시스템 오작동을 기록하고 프로젝트에 제공해야 합니다.

출시 후 활동

253

팀. 또한 사용자가 직면한 문제를 프로젝트 팀의 해당 구성원에게 보고할 수 있는 메커니즘이 있어야 합니다. 이러한 종류의 커뮤니케이션이 이루어지지 않으면, 즉 사용자 경험 디자이너, 비주얼 디자이너 및 개발자가 종종 엄격하고 빠르게 진행되는 베타 단계에서 무슨 일이 벌어지고 있는지 알지 못한다면 웹 사이트는 업데이트되지 않고 사용자에게 재배포될 수 있습니다. 대부분의 전략이 실행되었습니다.

시작 후 분석 사이트를 시작한 후 가장 먼저 해야 할 일 중 하나는 사이트 사용에 대한 데이터를 축적하기 시작하는 것입니다. 가장 좋은 소스는 사이트의 로그 파일입니다. 불행히도 사용자 경험 디자이너는 이 정보를 받거나 검토할 수 있는 목록의 맨 위에 있지 않을 수 있으므로 사이트 호스팅을 담당하는 사람을 찾아 귀하의 협상 기술을 적용하십시오. 웹 사이트 분석을 통해 사이트 방문자에 대한 통찰력을 얻을 수 있습니다. 무엇보다도 새 사이트 방문자가 누구인지, 반복 사이트 방문자가 누구인지 페이지 보기 수 페이지 보기 기간 페이지 깊이 방문자가 사이트를 나가는 위치(페이지) 세션 기간 광고 노출 사용된 검색어, 결과 및 다시 -검색

이 정보는 사이트에서 문제가 있는 부분을 강조 표시하여 사용자가 문제를 겪고 있는 부분을 이해하는 데 도움이 될 수 있습니다. 분석이 무미건조하고 숫자가 많은 것처럼 보일 수 있지만 데이터와 통찰력은 출시 후 테스트를 수행할 때 적절한 질문을 모으는 데 도움이 될 것입니다. 참고 웹 사이트 분석에 대한 자세한 내용은 Avinash Kaushik의 Web Analytics: An Hour a Day(Sybex, 2007)에서 시작하는 것이 좋습니다.

254

14장: 전환: 설계에서 개발 및 그 이상으로

사용자와 함께 실행 후 설계 테스트(다시, 다시) 웹 사이트 분석에서 데이터를 축적하고 고객 지원 또는 사용자와 상호 작용하는 다른 부서에서 정보를 수집한 후 사용자. 즉, 수집한 데이터를 사용하여 사이트 사용자에게 질문할 새로운 일련의 질문을 만들고 13장에서 배운 기술을 사용하십시오. 이 테스트 라운드의 이점 중 하나는 다음과 같은 기회가 있다는 것입니다. 이전에 함께 작업한 동일한 사용자 배치를 테스트하여 웹 사이트를 시작하고 더 많이 사용한 후에 의견이 변경되었는지 확인합니다. 이는 매우 유용할 수 있습니다. 동일한 사용자 그룹(또는 그 일부)을 다시 테스트하는 경우 원래 질문 중 일부(기능에 대한 의견, 특정 작업을 달성하는 능력 등)를 다시 질문하고 시간이 지남에 따라 응답. 이러한 변동 가능성은 사이트에서 개선할 새로운 영역을 발견하고 이전 라운드를 기반으로 사용자의 학습 곡선에 대한 통찰력을 얻는 데 도움이 될 수 있습니다. 추가 이점으로 응답의 차이를 분석하면 이전에 고려하지 않은 새로운 질문을 식별하는 데 도움이 될 수도 있습니다.

모두 끝났죠? 아니요.

처음부터 다시 시작하는 것처럼... 분석 데이터 수집 및 연구 데이터로 디자인 테스트를 통해 웹 사이트에 도움이 될 향상 및 개선 목록을 작성하기 시작할 수 있습니다. 이를 완전히 취합한 후에는 권장 사항을 기반으로 새 제안(3장)을 작성할 수 있습니다. 이 제안은 완전히 새로운 프로젝트로 이어질 수 있으며, 새로운 프로젝트 목표(4장) 및 비즈니스 요구 사항(5장)을 정의하는 단계로 되돌아갈 수 있습니다. 당신은 할 수 있습니다

다시 시작하는 것처럼…

255

그런 다음 추가 연구(6장), 새로 식별된 대상에 대한 페르소나 생성(7장), SEO 향상(8장), 새 사이트 맵 및 작업 흐름 업데이트 또는 생성(10장), 새 와이어프레임 업데이트 또는 생성, 주석(11장), 추가 프로토타이핑 시작(12장), 사용자와 함께 더 많은 디자인 테스트(13장)… 아이디어를 얻습니다. 프로젝트는 죽지 않아야 합니다. 사용자 경험 디자인을 지속적으로 개선하기 위한 새로운 프로젝트의 발판이 되어야 합니다.

256

14장: 전환: 설계에서 개발 및 그 이상으로

인덱스 HTML 프로토타입에서 사용하는 절대 경로 213 승인 및 승인(제안 포함) 53–54 ACSI(American Customer Satisfaction Index) 103 활동, 계획 162–164 적응 경로 189–190 웹 사이트에서 연필과 종이 사용 168 추가 비용 및 수수료(제안 포함) 50 Adobe Acrobat PDF 프로토타이핑 도구, 기능 214–215 Adobe Illustrator 웹 사이트 167 Adobe InDesign 웹 사이트 167 지지자, 우선 순위 150–151, 154 기능 충돌에 적용되는 유사성 다이어그램 160–161 단계 99–100 사용성 테스트에서 사용 244 애자일 접근법 개요 65 AIGA 웹 사이트의 63–64 리소스 51 Ajax, 문제 132 Align Interactive 웹 사이트 217 alt 속성, 사용 139 American Customer Satisfaction Index(ACSI) 103 분석 도구 가용성 24 254 주석의 이점 189–190 및 와이어프레임용 187개 도구 개요 186–187, 193–194, 201 Aquent 인재 에이전시 웹 사이트 51 화살표 및 커넥터, 정의 170 Ascend Reality Solutions 웹 사이트 250 Ash, Tim 16 Ashton, Jonathan 143 Ask .com, 제안서 47–48을 포함하여 128개의 가정으로 수행된 검색

속성 비교 90 우선 순위 지정 및 정의 215 웹 사이트의 Axure RP 프로토타이핑 도구 기능 167

89–91

B Babyhold 웹 사이트 118 BabyNames 웹 사이트 118 균형, UX 디자인 달성 6–7 Balsamiq Mockups 프로토타이핑 도구, 216 Baty, Steve 12, 95 Behavior 웹 사이트 249 베타 출시, 253–254 청구율 정의, 51 검은 모자 결정 정의된 130–131 대 흰색 모자 141–142 블로그 기능, 사이트 맵 166, 191 Blue Flavor 웹 사이트 167 Blueprint CSS 웹 사이트 167 바디 랭귀지, 포커스 그룹에서 해석 106 봇, 설명 129개 브랜드 존재 사이트 설명 13개 기능 중 11개 예 13–14 브랜드 전략가/관리자에 대한 12–13 목표, 26–27 Brooks의 역할, Mark 200–201 건물 소유권, 183을 위한 시스템 Buley, Leah 189–190, 201 비즈니스 옹호자의 관심사 154 대 개발 및 사용자 옹호자 155 27–28의 비즈니스 분석 역할 188 비즈니스 요구 사항에서 와이어프레임 사용 73 참조 요구 사항 수집 명확화 68–69 통합 82–84 휴리스틱 분석 수행 70–73 회의 계획 생성 78–79

색인

257

비즈니스 요구 사항(계속) 153에 대한 워크시트 작성 정의 68 83의 예 75-76 책임 수집 76-77 이해 관계자 수집 Global Cruises 홈페이지 195-196 개발 지지자에 의한 상속 157 아이디어 청취 81 83-84 사이의 충돌 확인 우선순위 지정 151–152 효율적인 회의 진행 80–81 와이어프레임 189 정의된 비즈니스 이해관계자 75 Buxton, Bill 231

C 달력 도구, 217, 219 캠페인의 기능 프로토타입. 마케팅 캠페인 사이트 참조 카드 정렬 폐쇄 정렬 110 설명 93 그룹 정렬 110 개요 107–108 테스트 실행 수행 109 프로세스 108–110 지침 제공 109 원격 정렬 110 클라이언트, 와이어프레임 사용 188 클로킹, 설명 131–132 복제 142 개요 138 의도하지 않은 콜라주 방지 138 소액금융 사례 223–224 의사소통, 우선순위 지정의 중요성 160 기업에 SWOT 분석 적용 61–62 경쟁자 비교 61 기업 문화 계층 구조 36–37 34–35 물류 37

258

색인

보상, 사용자 그룹 235, 241 경쟁자 결정, 61 개념 탐색 비교. 222-224개의 잠재적 함정 222가지 목적의 221가지 조건, 정의된 170 충돌, 우선순위 지정 중 관리 158-162 연결, 엉성함 171 커넥터 및 화살표, 정의된 170 합의 충돌, 우선순위 지정에서 관리 160 소비자, 5에 영향 138-139에 대한 콘텐츠 모범 사례 135-136의 중요성 138 콘텐츠 제작자, 188 콘텐츠 관리 시스템의 와이어프레임 사용, 133-134 콘텐츠 매트릭스 개요, 173개 콘텐츠 소스 사이트에 번호 지정 시스템 적용 16-17의 11가지 기능 설명 17 관련 목표 17 비즈니스 분석가 사용 28 카드 정렬 사용 108 콘텐츠 전략가, 역할 28–29 상황적 디자인, 리소스 101 상황적 조회 설명 92 정보 98에서 얻은 정보 98 프로세스 98–99 사용 99– 101 카피라이터, 역할 29–30 Coroflot 웹 사이트 51 제안에 포함된 비용 및 수수료(추가) 50 크롤러 기능 131 클로킹을 통한 감지 132 설명 129 크리에이티브 커먼즈 웹 사이트 50

D 점선은 170개의 결정 지점, 정의된 169개의 정의 및 설계 단계가 있는 조건을 나타내며 제안서 48-49를 포함하여 145개의 산출물 간에 겹칩니다. 브랜드 존재 사이트의 제품 디자인 목표 13 콘텐츠 소스 사이트 17 전자 상거래 사이트 19 e-러닝 애플리케이션 20 마케팅 캠페인 사이트 15–16 설정 10 소셜 네트워킹 애플리케이션 21 작업 기반 애플리케이션 18–19 디자인 참조 실수 페이지 번호 매기기 부족 173–174 잘못 정렬된 개체 172 잘못 배치된 텍스트 172–173 엉성한 연결 171 고르지 않은 간격의 개체 172 디자인, 개선 227 개발자가 와이어프레임 사용에서 프로토타입을 얻음 188 개발 옹호자 대 비즈니스 및 사용자 옹호자 155 154개 목표 및 책임 157개 요구 사항 상속 157–158 156개 개발 팀의 158개 품질 참여, 249개 디지털 자산에 피드백 제공, 138개 디지털 경험 최적화, 5–6개 디지털 프로토타이핑 설계. HTML 대 WYSIWYG 편집기 209-214 와이어프레임 대 실제 프로토타입 207-209 타임라인에 필요한 리소스 209 디지털 웹 매거진 웹 사이트 167

디렉토리 구조, 134개의 토론 가이드의 중요성, 사용성 테스트를 위한 작성 239–241 문서, 162–164개의 도메인 계획, 134개의 도어웨이 페이지의 키워드 포함, 142개의 점 개요, 선호도 다이어그램에 사용 161 Dreamweaver CS4, 209–의 라이브 뷰 기능 210 중복 콘텐츠, 방지 138 동적 URL, 콘텐츠 관리 시스템에서 방지 133

전자상거래 사이트, 19개 교육 중심 마이크로사이트의 디자인 목표, 15개 e-러닝 애플리케이션의 예, 20개의 감정 대 논리에 대한 디자인 목표 7 PURITE 프로세스의 활성화 섹션 46 장비, 사용성 테스트 계획 239 Evans, Will 122, 123 , 181, 197–201 경험, 유형 대 디지털 4–5

F Fahey, Christopher 249 Favreau, Jean Marc 40은 제안 50 Finck, Nick 167 Fireworks CS4 프로토타이핑 도구, 215–216 Flash의 기능, 130–132 Flash의 기능 및 Flash Catalyst 프로토타이핑 도구, 216 Flash 콘텐츠의 기능, 정적 레이어에 포함 131 105–106에 대한 포커스 그룹 토론 형식 설명 93 106에서 신체 언어 해석 106 조정 107 105 프로세스 –107 104–105 바닥글을 사용하는 소액 금융 예제 223에서 사용, 196 설계

색인

259

바닥글 링크, 프론트엔드 개발자의 링크 인기도 140, 펀딩 모델의 역할 31, 소액 금융에 적용 222

G Garrett, Jesse James 168 Global Cruises, 195–201 Google 분석 도구용 홈 페이지 디자인 24 PageRank 시스템 139 웹마스터를 위한 품질 지침 128 그리드에서 수행하는 142 검색, 애플리케이션에서 사용 172 그룹 토론 형식 105–106 설명 93 신체 언어 해석 106에서 105-107의 조정 107 프로세스에서 104-105를 사용하는 소액 금융 사례 223에서 사용

H Hadden, Jon 217–219 헤더/탐색, 195 헤더 메타 태그 설계, 137 휴리스틱 분석 가능 요구 사항 수집에 대한 이점 73 70–71 개요 71 단계에 대한 근거 72–73 계층 구조, 회사 프로젝트에 미치는 영향 36–37 Hinton, Andrew 177 Hofstede, Geert 36 홈페이지 디자인 192 Global Cruises용 디자인 195–201 197–200용 와이어프레임 디자인 194의 예 212 링크의 HTML 프로토타입 140개의 HTML 프로토타입 인기도 213–214의 코드 분석 210의 오타 확인 210–212 생성

260

색인

I 아이디어, 통합 82–84 기능 아이디어 및 시각화 145–147 Illustrator 웹 사이트 167 이미지 맵, HTML 프로토타입에서 사용 213 이미지 태그, HTML 프로토타입에서 사용 213 InDesign 웹 사이트 167 인덱스 페이지, 분리 137–138 인덱싱 사이트 131 무한 루프 , 콘텐츠 관리 시스템에서 133–134 정보 피하기, 다른 역할과 균형을 이루는 17 정보 설계자 찾기 248–249 역할 22–23, 25 Information Architecture Institute 웹 사이트 51, 167 지침, 유용성 테스트를 위해 마무리 239–241 기타 역할 248–249 역할 23, 25 인터뷰. 사용자 인터뷰 참조.

J JavaScript, jQuery 웹 사이트의 문제 214

132–133

K Keynote 프로토타이핑 도구, 사이트 맵에 포함된 214개 키의 기능 175개 키워드 연구 도구, 135개 키워드 기반 검색의 가용성, 도메인을 포함하여 135개 키워드의 동작 URL 구조에서 사용하는 136개에 대한 134개 명명 규칙 134–135 Knemeyer, Dirk 12

L은 사이트를 시작했고, 254개의 왼쪽 내비게이션 링크의 시작 후 분석, 사이트 맵을 포함하여 217-218개의 범례에 대한 프로토타입 175

라이선스 저작물, 정의 49–50 링크 앵커 텍스트 메타 태그, 설명 137 링크 인기 분포 139–140 설명 139 바닥글 링크 140 콘텐츠 내 교차 링크 141 조작 143 링크 스팸 143 사용자 참가자 목록, 생성 234–235 라이브 뷰 , Dreamweaver CS4에서 사용 209 논리 대 감정 7 물류, 회사 프로젝트에 미치는 영향 37 사용성 테스트의 물류 단계 233–239 Lucht, Troy 250

M 마케팅 캠페인 사이트는 15-16개 시장에 대한 14개 목표의 14가지 기능에 대한 11가지 예를 설명했으며, 26-27 Melzer, James와 관계 구축 182 Messagefirst 페르소나 사례 연구 115 웹 사이트 219 메타 설명 태그, 설명 137 메타 키워드 태그 설명 136-137 142개의 메타 태그가 포함된 스팸, 136–137 방법론의 가용성, 62 소액 금융의 중요성, 정의된 222 마이크로사이트, 정의된 15 Microsoft PowerPoint 웹 사이트 167 Microsoft Visio 웹 사이트 167 실수 페이지 번호 지정 부족 173–174 잘못 정렬된 개체 172 잘못 배치된 텍스트 172– 173개의 엉성한 연결 171개의 고르지 않은 간격의 물체 172개의 수정된 접근, 64-65개의 움직임을 따라 170개의 MSN을 묘사, 128명이 수행한 검색

N 이름, 페르소나 제공 118 협상, 250 네트워크 의견 기술, 사용자 채택에 미치는 영향 253 Nicolle 페르소나, 설명 115–116 Nielsen, Jakob 71 nofollow 링크 속성, 140 noindex 메타 태그 사용, 설명 137

SWOT 분석을 적용하는 O 목표 61–62 퍼지 대 솔리드 58–60 중요도 57–58 UX 디자이너의 입력 60–62 측정 58, 60 객체가 적절하게 연결 171 계산 그리드 사이 172 오정렬 172 고르지 않은 간격 172 관찰, 휴리스틱 분석을 위한 72–73 OmniGraffle 프로토타이핑 도구의 기능 215 웹 사이트 167 OpenOffice Draw 웹 사이트 167 OptimalSort 웹 사이트 109 개요(제안 포함) 44–45 소유권 및 권리(제안 포함) 49–50

P 페이지 번호 매기기, 173–174 페이지 제목 메타 태그 부족, 136 PageRank 시스템 설명, 139–140 페이지 설명. 사이트 복제 142-143 정의 168 개별 색인 생성 137-138 페이지 스택, 정의 169 종이와 연필, 와이어프레임에 사용 189-190, 201 "종이 문화" 이해 37

색인

261

종이 프로토타이핑 206–207 217–218 HTML의 예 209 내비게이션 개념 218 수동적 관찰, 정의된 99 경로, 작업 흐름에서 식별 180 제안서 포함 52–53 연필과 종이, 와이어프레임에 사용 189–190, 201 페르소나 나이 119 사례 연구 115 정의 113 교육 수준 120 클라이언트에 대한 진입 또는 트리거 포인트 120 정보 찾기 114 포함된 정보 116 위치 119 사용 최대화 125 모바일 편안함 수준 121 클라이언트, 브랜드, 또는 프로젝트 121 이름 지정 118 직업 119 오프라인 활동 120 온라인 활동 120 개요 마스터 시트 122 개인 인용 120 사진 117–118 근거 113–114 급여 또는 급여 범위 120 사회적 안정 수준 121 대상 청중 123 대상 그룹 124 대상 대상 개인 124 기술적 편안함 수준 121 유형 113 사용자 목표 121 사진 소스, 페르소나 획득 117 포스트잇 노트, 친화도 다이어그램에 사용 161 출시 후 디자인 테스트 255 테스트 참조; 사용성 테스트 단계 전원 거리, 정의 36 PowerPoint 프로토타이핑 도구, 기능 214

262

색인

PowerPoint 웹 사이트 167 PR(PageRank), 설명 139–140 PURITE 프로세스 준비 섹션 45 가격 책정, 프로젝트 구조화 51–52 사용성 테스트에 적용되는 우선 순위 프로세스 244–245 역할 균형 조정 158–162 프로세스 흐름 중 충돌, 181–182 제품의 예, 5의 성공. 인도물 참조 프로젝트 접근 방식 애자일 63–64 제안서 45–47에 포함된 66의 중요성 62–63 폭포수 63 프로젝트 방향에 대한 수정된 64–65 단계 , 160 프로젝트 관리에 대한 정렬 부족, SWOT 분석을 적용하는 188 프로젝트 목표에서 와이어프레임 사용 61–62 퍼지 대 솔리드 58–60 중요도 57–58 UX 디자이너의 60–62 측정 58, 60 프로젝트 개요, 포함 제안서 51-52 프로젝트 요구 사항을 포함한 제안서 44-45 프로젝트 가격 책정, 프로젝트 스폰서 관련 단계 69 프로젝트 팀 정의 75 프로젝트 조건 정의 80 프로젝트 모범 사례 도표 191 회사 연혁이 34-35에 미치는 영향 181–182 제안 구성 요소의 프로세스 흐름 확인 및 승인 53–54 추가 비용 및 수수료 50 가정 47–48 산출물 48–49 소유권 및 권리 49–50 지불 일정 52–53

프로젝트 접근 방식 45–47 프로젝트 개요 44–45 프로젝트 가격 책정 51–52 개정 내역 44 작업 범위 47 작업 명세서 54–55 제목 페이지 42–43 제안, 중요성 40–41 프로토타입 219 응용 프로그램의 경제성 캘린더 도구 219 217, 219 와이어프레임을 WYSIWYG 편집기로 만들기 210 완료 219 피드백 메커니즘으로 217–219의 209–214 예제 219 반복 테스트를 위한 219 목표 217 개발자로부터 얻은 217 와이어프레임 대 사실적인 207–209 프로토타이핑. 205 종이 206–207 프로토타이핑 도구의 205–206 개요에 대한 디지털 프로토타이핑 모범 사례도 참조하십시오. 청교도 프로세스 45–46

Q 질적 연구, 사용성 테스트에 적용 227–229 정성적 사용성 테스트, 231–232 품질 보증 문서에 대한 정보 수집, 249에 참여하는 250 대신 174 품질 보증 팀에 번호 지정 시스템 적용

품질 보증, 정량적 연구를 위한 와이어프레임 사용 188개, 사용성 테스트에 적용 227–229개의 질문지(토론 가이드 포함) 241개 질문. 활동 계획 스크리너 162–164 사용자 그룹 보상 235–236 문서 계획 162–164 포커스 그룹 105 스토리보드 148 설문 조사 102 사용성 테스트 242 사용자 인터뷰 97 사용자 만족도 233

R Random Name Generator 웹 사이트 118 권장 사항, 사용성 테스트를 위한 생성 245–246 사용성 테스트 모집 단계 233–239 리디렉션, 135 상대 경로 설정, HTML 프로토타입에서 사용 213 PURITE 프로세스의 렌더링 섹션 46 요구 사항, 정의된 66 요구 사항 수집, 단축 74 참조 비즈니스 요구 사항 요구 사항 프로세스, 장려 74 연구, 사용성 테스트 계획 229–233 연구 기법 카드 정렬 93, 107–110 상황별 질문 92, 98–101 포커스 그룹 93, 104–107 페르소나 121 설문 조사 92, 101– 104 사용성 테스트 93, 110–111 사용자 인터뷰 92, 95–97 리소스. 참조 웹 사이트 리소스 친화도 다이어그램 161 민첩한 접근 방식 65 분석 254 바디 랭귀지 106 컨텍스트 디자인 101 Google 128 HTML(HyperText Markup Language) 214

색인

263

리소스(계속) 반복 설계 231 협상 250 프로토타이핑 접근 방식 217 소셜 네트워킹 애플리케이션 20 도구 167 사용성 테스트 231 책임, 개요 75–76 개정 내역(제안 포함) 44 우선순위 프로세스에서 역할 균형 조정 154 결합 및 전환 156 관리 248–249

S 샘플 크기, 사용성 테스트 236-239에서 사용하는 제안서 47 스크리너를 포함하여 정의된 227 작업 범위. 질문 스크립트 내비게이션, 132–133 검색 동작 문제, 135 검색 엔진 최적화 시작 가이드 129 검색 엔진 이해, 129 검색 결과의 진화, 매월 142 검색에 영향, 128 섹션 헤더와 관련된 통계, 137 Seiden, Josh 허용 113 SEO(검색 엔진 최적화) 정의 127 SEO 방법에 대한 127–128 리소스의 134 중요성에 대한 UX의 영향, 흰색 모자 대 검은 모자 141–142 SEO 전문가, 제안을 포함하여 188 승인 및 승인에 의한 와이어프레임 사용 53–54 사이트 분석, 24 사이트 맵을 위한 도구 블로그 기능에 대한 175–176의 고급 예 166, 191 177 정의 166의 틀 깨기

264

색인

173개의 간단한 예에서 번호 매기기 구조를 생략하고 138개를 사용하는 작업 흐름 166과 178개 사이트 유형의 작업 흐름을 사용하여 11개 사이트를 식별하는 카드 정렬을 사용합니다. 색인 페이지 참조 131 29–30 식스업 템플릿에 텍스트 작성, 190 Slingthought 웹 사이트 217 소셜 네트워킹 애플리케이션 설명 21 사회보장국의 인기 아기 이름에 대한 20 디자인 목표 118 소프트웨어 사용성 측정 인벤토리(SUMI) 103 SOW(서명 작업), 콘텐츠 54–55 공간, 사용성 테스트 계획 239 메타 키워드를 사용한 스팸 142 Spencer, Donna 17, 109 spider, 설명 129 Spool, Jared 125 SRA International Inc. 웹 사이트 182 이해 관계자 정의 75 수집 76–77 듣기 81개의 정적 레이어, Flash 콘텐츠를 131개의 스티커 도트에 포함, 유사도 다이어그램 161 Stock.XCHNG 웹 사이트 117 스토리보드 작성, 147–150개의 강점과 약점 처리, 이해 61 SUMI(Software Usability Measurement Inventory) 103 지원 네트워크, 구축 32– 33. 참조 UX 디자인 역할 설문 조사 설명 92 개요 101 프로세스의 102–104 대 사용자 인터뷰 102

SWFobject, 131 스윔 레인 사용, 182–184 SWOT 분석의 예, 프로젝트 목표 61–62에 적용

T 태그. 113을 설명하는 메타 태그 대상 사용자를 참조하십시오. 번호 매기기 시스템을 173에 적용하는 사용자 작업 흐름도 참조하십시오. 응용 프로그램 사이트는 비즈니스 분석가를 사용하여 18–19에 대한 11가지 기능 및 목표를 설명했습니다. 사용성 테스트 239 테스트 자료, 사용성 테스트를 위한 작성 241 PURITE 프로세스의 테스트 섹션 46 테스트, 사용성 대 사용자 수용 226. 출시 후 디자인 테스트도 참조하십시오. 사용성 테스트 단계 텍스트 사용성 테스트를 위해 마무리 239–241 사이트에 172–173의 잘못된 배치 29–30 제안서 포함 제목 페이지 42–43 제목 태그, HTML 프로토타입에서 사용 213 도구, 167–168의 가용성

U UAT(사용자 수용 테스트), 목적 226 PURITE 프로세스 섹션 이해 45

URL 경로, 콘텐츠 관리 시스템에서 회피 133 콘텐츠 관리 시스템에서 회피하는 URL 구조 134 사용성 테스트에서 키워드 사용 134-135 사용성 테스트에 대한 접근 방식 선택 227-228 설명 93 사용성 테스트 단계 110-111 개요 236-239. 출시 후 디자인 테스트도 참조하십시오. 테스트 결과 분석 및 제시 243–245 접근 방식 선택 227–228 권장 사항 생성 245–246 평가 250 촉진 242–243 연구 계획 229–233 모집 및 물류 233–239 토론 가이드 작성 239–241 Usability.gov 240 네트워크의 사용자 채택 영향 개인 이익에 대한 253 영향에 대한 의견 252 사용자 옹호에 대한 지원 제공 252 사용자 옹호 역할 가정 150-151 네트워크 구축 32-33 대 비즈니스 및 개발 옹호 155 우려 154 사용자 속성 비교 90 우선순위 지정 및 정의 89-91 사용자 행동 , 227 사용자 경험(UX)에 대한 컨텍스트를 얻습니다. 사용자 인터페이스 엔지니어링 웹 사이트 125 사용자 인터뷰 설명 92 인터뷰 요령 97 프로세스 95-96 대 설문 조사 102

색인

265

사용자 모델, 91 사용자 연구 활동에서 설계 93–94 완료 111 계획 수행을 위한 94 단계 86 기법 92 사용자 연구 계획, 개발 229–233 사용자 연구원, 역할 23–25 사용자 만족도 결정 233 측정 도구 103 사용성 분류 사용자 진술 테스트 245 233 사용자 성공 평가, 232-233 사용자 결정. 또한 사용성 테스트를 위해 번호를 선택하는 대상 사용자를 참조하십시오. 네트워크 브랜드 전략가/담당자 지원 26–27 비즈니스 분석가 27–28 선택 31 콘텐츠 전략가 28–29 카피라이터 29–30 프런트 엔드 개발자 31 정보 설계자 22–23 인터랙션 디자이너 23 책임 25 사용자 연구원 23–24 비주얼 디자이너 30-31명의 UX 디자이너가 다른 역할과 균형을 잡습니다. 248-249 프로젝트 목표에 대한 156개의 의견에 공감합니다.

V 유효성 검사, 초기 191 가치 제안 추구, 15 제시

266

색인

Visio 프로토타이핑 도구, 215 Visio 웹 사이트 167 시각 디자인 팀의 기능, 와이어프레임 203 생성에 참여하는 249 시각 디자이너에게 피드백 제공 30-31 역할 30-31 188 시각 디자인의 와이어프레임 사용. 174개의 목업에 번호 매기기 시스템을 적용하는 개념 탐색 와이어프레임의 224개 200–201 시각적 어휘 정의 조건 170 커넥터 및 화살표 170 결정 지점 169 페이지 168–169 페이지 스택 169 기능 시각화 및 아이디어 145–147 어휘, 비즈니스 요구 사항 공유 80 -81

W WAMMI(웹 사이트 분석 및 측정 인벤토리) 103 Warfel, Todd Zaki 115, 124, 217, 219 수정된 폭포수 접근 방식 63명의 웹마스터의 65단계, 142명의 웹마스터/사이트 소유자를 위한 품질 지침 도움말 129 웹사이트 분석 및 측정 인벤토리(WAMMI) 103 웹 -사이트 리소스 28. 참조 리소스 ACSI(American Customer Satisfaction Index) 103 적응 경로 168 Adobe Illustrator 167 Adobe InDesign 167 AIGA 51 Align Interactive 217 Aquent 탤런트 에이전시 51 Ascend Reality Solutions 250 Axure RP Pro 167 Babyhold 118 BabyNames 118 Behavior 249

Blue Flavor 167 Blueprint CSS 167 "Brand Experience and the Web," 12 Brooks, Mark 201 카드 정렬 스프레드시트 109–110 Coroflot 51 Creative Commons 50 Digital Web Magazine 167 도어웨이 페이지 142 Evans, Will 181 정적 콘텐츠를 찾기 위한 Google 코드 131 Hadden , Jon 219 휴리스틱 분석 71 HTML 프로토타이핑 214 Illustrator 167 이미지 맵 213–214 InDesign 167 Information Architecture Institute 51, 167 정보 검색 17 jQuery 214 키워드 연구 도구 135 마케팅 캠페인 사이트 16 Messagefirst 219 Microsoft PowerPoint 167 Microsoft Visio 167 페르소나 이름 118 OmniGraffle 167 OpenOffice Draw 167 OptimalSort 109 페르소나 유형 113 사진 리소스 117 PowerPoint 167 임의 이름 생성기 118 검색 엔진 최적화 시작 가이드 129 SEO(검색 엔진 최적화) 143 Slingthought 217 사회 보장국의 인기 아기 이름 118 SRA International Inc. 182 SUMI(Software Measurement Inventory) ) 103 도구 167 사용성 테스트 스크립트 240 Usability.gov 240

사용자 인터페이스 엔지니어링 125 사용자 만족도 측정 도구 103 UX 디자인 접근 방식 24 UX 조직 8 UX 연구 95 Visio 167 WAMMI(Website Analysis and MeasureMent Inventory) 103 웹마스터/사이트 소유자 도움말 129 WebSort 109 WebTrends 24 Yahoo! 인터페이스 라이브러리 웹 사이트 214 WebSort 웹 사이트 109 WebTrends 웹 사이트 24 흰색 모자 대 검은 모자 141–142 화이트보드, 149 와이어프레임 및 주석에 대한 스토리보드 186–187, 193–194, 201 번호 매기기 시스템 적용 173 프로토타입으로 변경 201 접근 방식 210 비교 및 대조 200 만들기 189, 198–199 홈 페이지 197–200을 반복 연습으로 디자인 201 192–193에 대한 고객의 의견 받기 186–187 개요 제시 202–203 대 사실적인 프로토타입 207–209 시작 192–193, 201 as "생각하는 장치", 189-190명의 사용자를 위한 198개의 도구 200-201개의 고용 작업의 188개의 시각적 디자인, 정의된 49개의 워크플로우, 스토리보드 149개의 워크시트, 비즈니스 요구 사항을 위해 생성 153개의 WYSIWYG 편집기, 209-214개의 프로토타입 생성

Y Yahoo, 128 Yahoo! 인터페이스 라이브러리 웹 사이트 214

색인

(Video) 손쉬운 Ux 페르소나 매핑 - 지금 시작하기 위한 무료 다운로드 가이드 받기

267

이 책을 45일 동안 무료로 온라인으로 만나보세요! 그리고 Safari Books Online의 무료 평가판에 등록하여 수천 가지 이상의 책에 액세스할 수 있습니다! 이 책을 구입하면 Safari Books Online에서 45일 동안 즉시 온라인으로 검색할 수 있습니다! 거기에 있는 동안 Safari Books Online의 주문형 디지털 라이브러리와 무료 평가판 제안(별도의 가입 프로세스)을 확인하십시오. Safari Books Online 구독자는 수천 권의 기술, 창의적 및 비즈니스 서적, 교육용 비디오 및 세계 유수의 출판사에서 제공하는 기사를 이용할 수 있습니다.

www.peachpit.com/safarienabled를 방문하여 코드 FJGSLZG를 입력하여 지금 사용해 보십시오.

UX 디자인 프로젝트 가이드 - PDF 무료 다운로드 (2023)

Videos

References