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의 상표입니다. 저작권 © 2009 Russ Unger 및 Carolyn Chandler 인수 편집자: Michael J. Nolan 프로젝트 편집자: Becca Freed 프로덕션 편집자: Tracey Croom 개발 편집자: Linda Laflamme 카피 편집자: Leslie Tilley 교정: Suzie Nasol 작곡가: Danielle Foster Indexer: Valerie Perry Mimi Heft Cover 프로덕션: 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 겸 사용자 인터페이스 엔지니어링 창립 이사

UX 디자인에 대해 알아야 할 모든 것을 알려주는 책이 있습니까? 아니요. 당신을 가장 잘 이끌어 줄 책이 있습니까? 지금은. 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 이 책은 가족, 친구, 동료, 그리고 처음 몇 권의 출판물이 쓰여지기 전에는 저에게 완전히 낯선 사람이었던 수많은 사람들의 지원 없이는 결코 완성에 가까워지지 못했을 것입니다. 극단적인 결점을 가진 괴짜와 고의로 고의로 결혼한 아름다운 아내 니콜은 이 책을 쓰는 대부분의 시간 동안 육아 의무를 두 배로 늘렸습니다. 우리 딸 Sydney와 Avery는 종종 거의 혼수 상태에 빠진 아버지를 찌르고 재촉하여 아버지가 춤추고 노래하고 Spore를 연주하게 했습니다. 나도 모르게 집에서 신생아와 함께 책을 쓰는 것이 그렇게 큰 도전이 아닐 것이라고 생각했습니다. 나는 빨리 다르게 배웠다. 그리고 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은 우리를 위해 SEO에 대한 전체 장을 썼습니다. 조나단과 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), Chapter 7; Steve "Doc" Baty, (www.meld.com.au), 3장, 11장, 14장 및 "A Short Guide to Meetings"; Mark Brooks(www.markpbrooks.com), 3장 및 11장; Leah Buley(www.adaptivepath.com), 11장; 데이브 칼슨(www.deech.com), 11장; Will Evans(www.semanticfoundry.com), 7장, 10장 및 11장; Christopher Fahey(www.behaviordesign.com), 14장; 닉 핀크(www.nickfinck.com), 10장; Jesse James Garrett(www.adaptivepath.com), 10장; 오스틴 고벨라(www.grafofini.com), 11장; Jon Hadden(www.jonhadden.com), 12장; 휘트니 헤스(www.whitneyhess.com), 11장; Andrew Hinton(www.inkblurt.com)의 10장; Gabby Hon(www.staywiththegroup.com), 3장 및 11장; Kaleem Khan(www.uxjournal.com), "A Short Guide to Meetings"; 14장 Ross Kimbarovsky(www.crowdspring.com); 리비아 라바테(www.livlab.com), 7장; Michael Leis(www.michaelleis.com), 11장; Troy Lucht(www.ascendrealtysolutions.com), 14장; 제임스 멜저(www.jamesmelzer.com), 10장; 매튜 밀란(www.normativethinking.com), 7장; Chris Miller(www.hundredfathom.com/blog), "A Short 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 Short Guide to Meetings"; Josh Seiden(www.joshuaseiden.com), 7장; 조나단 스눅(www.snook.ca), 12장; Joe Sokohl(www.sokohl.com), 12장 및 "A Short Guide to Meetings"; Samantha Soma(www.sisoma.com), “간단한 안내서

뷔

감사해요

회의”; Donna Spencer(www.maadmob.net), 7장; Jared M. Spool(www.uie.com), 7장; Keith Tatum(www.slingthought.com), 12장; Todd Zaki Warfel(www.messagefirst.com), 7장, 12장, 14장. Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau, Hugh Forrest에게도 감사드립니다. 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는 우리를 엄청나게 도와준 많은 사람들에게 감사를 표했습니다. 나는 우리가 그에게 던질 수있는 조잡한 형태로 모든 장을 읽었고 여전히 아침의 짧은 시간 (그의 시간)에 열정적으로 들렸던 Steve Baty 이외의 모든 이름을 반복하지 않을 것입니다. John Geletka는 또한 여러 분야를 넘나드는 불꽃과 관점으로 사려 깊은 피드백과 흥미로운 토론을 제공했습니다. 그리고 물론 Peachpit 팀; 나는 Linda Laflamme에게서 첫 장을 되찾은 것을 결코 잊지 못할 것입니다. 그것은 예쁘지 않았습니다 (그는 좋은 속도로 제안을 전달했지만). 그는 참을성있게

감사해요

vii

편집 과정을 안내해 주었고 흐름을 다듬는 데 도움을 주었습니다. 원래는 전체 길이의 책을 쓰는 것보다 개별 백서를 작성하는 데 더 적합했습니다. 이제는 동료들과의 일상적인 대화에 전환을 추가하는 제 자신을 발견했습니다! 말하자면... 크리스틴 모텐슨(Christine Mortensen), 일명 모티(Morty)는 비주얼 범죄의 제 파트너였습니다. 내 챕터의 아이콘과 차트는 그의 노력의 결과입니다. 그와 나는 챕터 마감일을 맞추려고 노력하면서 동시에 많은 동일한 클라이언트 프로젝트에서 작업했기 때문에 얼마나 열심히 일했는지 압니다. Morty는 시각적 디자인과 인터랙션 디자인 모두에 확고하게 발을 디디는 방법을 알고 있는 비주얼 디자이너 중 한 명으로, 프로젝트에서 모든 사람과 즐겁게 협업하고 개념에 생명을 불어넣습니다. 그는 정직하고 품질에 중점을 두어 함께 일하는 것을 기쁘게 생각하며 그를 파트너로 둔 것은 영광이었습니다. 지난 몇 달 동안 큰 도움을 주신 Manifest Digital의 모든 분들께도 큰 감사를 드립니다. Jim Jacoby는 비즈니스 통찰력과 UX 관점의 특별한 조화를 그의 트레이드마크인 Zen과 같은 차분함으로 가져왔습니다. Jason Ulaszek은 UX 업계에서 내가 아는 가장 열정적인 사람 중 한 명이며 도구와 기술에 대한 끝없는 지식을 가지고 있습니다. 나는 그가 모든 것을 위한 공간을 어디에 두는지 전혀 모릅니다! Brett Gilbert와 Jen O'Brien은 또한 UX 디자이너와 함께 일하는 많은 역할 중 일부에 귀중한 기여를 했습니다. 또한 "책"의 진행 상황에 대한 지속적인 참조를 통해 영감을 주고 인내해 준 Manifest UX 팀 구성원인 Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne, 그리고 산티아고 루이즈. 당신은 함께 일할 수 있는 끊임없는 기쁨입니다. 매일 나는 당신의 유머와 이해에 감사합니다. 귀하의 경험을 공유하고 제가 사랑하는 UX 커뮤니티의 적극적인 구성원이 되어 주신 Interaction Design Association의 동료들에게 감사드립니다. 특히 시카고 챕터를 발전시키는 데 중요한 역할을 했으며 똑똑한 사람들의 활기찬 네트워크를 성장시킬 새로운 방법을 끊임없이 찾고 있는 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 검색 엔진 최적화 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 검색 엔진 최적화가 중요한 이유는 무엇입니까? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 중요한 기본 리소스 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

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

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

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

xvi

소개

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

그런 다음 반드시 읽어야 합니다…

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

1장: UXD:n 사람들

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

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

효과적인 회의, 명확한 목표 및 이해하기 쉬운 수락 지점으로 일을 올바르게 시작하십시오.

온라인 챕터: 회의에 대한 간략한 가이드 4장: 프로젝트 목표 및 접근 방식

명확하고 비즈니스 이해 관계자 및 사용자가 쉽게 우선 순위를 지정할 수 있는 프로젝트 요구 사항을 정의합니다.

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

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

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

도구와 기술을 선택하고 활용하여 프로젝트 팀에 시각적 아이디어를 신속하게 제공

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

사용자와 검색 엔진이 귀하의 사이트를 쉽게 찾고 검색하는지 확인하십시오.

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

개발이 시작될 때 프로젝트 팀과 커뮤니케이션하고 디자인을 개발합니다.

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

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

소개

xvii

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

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

xviii

소개

귀하의 필요에 맞게 프로세스를 조정할 수 있도록 다른 사람들로부터. 자신에게 맞는 것을 찾으면 공유하세요! 알려주세요!

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

초대된 서핑 참조는 읽는 데 5~30분이 소요되는 더 짧은 기능(일반적으로 온라인)입니다.

Snorklaus Snorkkel 초대 대상자는 긴 온라인 기사, 백서 또는 읽는 데 한 시간 또는 주말이 걸리는 짧은 책입니다.

Deep Diving Called With a Diver's Helmet은 읽는 데 아마 한 주말 이상 걸릴 긴 책입니다. 그들은 당신에게 주제에 대한 철저한 범위를 제공합니다.

소개

xix

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

UXD의 타오 호기심이 열정과 공감을 만나다 중요한 것은 질문을 멈추지 않는 것입니다. 호기심에는 나름의 이유가 있습니다. 영원과 삶의 신비와 경이로운 실재 구조를 숙고할 때 두려워할 수 없습니다. 매일 이 신비를 조금이라도 이해하려고 노력하면 충분합니다. 알버트 아인슈타인

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

열정과 목적은 함께 간다. 당신이 당신의 목적을 발견할 때, 당신은 보통 그것이 당신이 극도로 열정적이라는 것을 알게 됩니다. 스티브 파블리나

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

케이

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

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

루쿠 1: UXD:n 사람들

이 거의 변함없는 어린아이 같은 호기심을 "우리가 하는 일을 하는 것"에 대한 비할 데 없는 열정과 다른 사람들이 어떻게 느끼는지에 대한 감각과 결합할 때, 자신의 마음을 편안하게 말하고 질문하고, 해결책을 공유하고 잘못되는 것, 이 모든 것이 옳은 것의 이름으로 이루어집니다. UX 디자인 커뮤니티에 오신 것을 환영합니다.

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

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

이러한 요소에는 사용자가 만질 수 있는 것(예: 유형의 제품 및 포장), 들을 수 있는 것(광고 및 경고음), 심지어 냄새(샌드위치 가게에서 갓 구운 빵 냄새)까지 포함됩니다. 여기에는 디지털 인터페이스(웹사이트 및 모바일 앱)와 물론 사람(고객 서비스 담당자, 판매원, 친구 및 가족)과 같이 사용자가 다른 방식으로 상호작용할 수 있는 것들이 포함됩니다. 최근 몇 년 동안 가장 흥미로운 발전 중 하나는 이러한 다양한 감각 요소를 보다 풍부하고 통합된 경험으로 결합하는 기능입니다. Smell-o-vision은 아직 미래와는 거리가 멀지만 그렇지 않으면 제품이 여전히 전통적인 선을 흐리게 합니다.

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

삼

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

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

루쿠 1: UXD:n 사람들

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

그림 1.2 온라인 리뷰는 주요 소비자 영향 요인입니다.

우리의 초점 보시다시피 UX 디자인의 범위는 광범위하고 성장하고 있습니다. 이 책에서는 디지털 경험, 특히 웹 사이트 및 소프트웨어 애플리케이션과 같은 대화형 미디어를 디자인하는 데 중점을 둔 프로젝트에 중점을 둡니다. 성공하려면 이러한 제품에 대한 사용자 경험 디자인에서 프로젝트의 비즈니스 목표, 제품 사용자의 요구 사항 및 제품 기능의 기능에 영향을 미치는 모든 제약 조건(예: 프로젝트의 기술 제한 또는 제한 사항)을 고려해야 합니다. 예산 또는 시간 제한).

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

새로운 영양 바의 무료 샘플이 마라톤에서 제공되었습니다.

문 손잡이

신발 한 켤레의 포장

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

구체적인 휴대폰 문자 메시지 기능

고객 서비스 전화 통화

개인

사회의

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

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

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

루쿠 1: UXD:n 사람들

이러한 균형을 이루려면 공감 능력이 높아야 합니다. 즉, 잠재적인 제품 사용자의 세계에 몰입하여 그들의 요구 사항과 동기를 이해할 수 있는 능력입니다. 사용자 경험 디자이너는 이러한 이해를 달성하기 위해 연구를 수행하고(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:n 사람들

프로젝트 요구 사항, 역할 및 문화에 대한 프로젝트 생태계 디자인 완전히 새로운 프로젝트를 시작하고 있습니까? 아니면 그 중간에 있습니까? 어느 쪽이든 잠시 시간을 내어 프로젝트의 역동성과 컨텍스트, 즉 귀하와 나머지 프로젝트 팀에 영향을 미치는 사항에 대해 생각해 보십시오. 어떤 유형의 사이트 또는 앱이 연결되어 있습니까? 어떤 역할과 기술이 필요합니까? 기업문화란? 이러한 질문에 답하면 프로젝트를 정의하고 궁극적으로 성공을 위해 필요한 도구와 기술을 정의하는 데 도움이 됩니다. 캐롤린 챈들러

이자형

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

사이트 유형 식별 한 유형의 사이트 간에 흑백 차이는 없지만 사이트의 초점과 기능에는 상대적인 차이가 있습니다. 이러한 유사점과 차이점을 이해하면 스스로 디자인 목표를 설정하는 데 도움이 될 수 있습니다. 이들은 일반적으로 가지고 있는 문제입니다.

해결(예: "회사의 비즈니스 모델 설명") 또는 속성(예: "고객에 대한 회사의 응답성 입증")을 사이트의 시각적 디자인 및 인터랙션 디자인에서 나타냅니다.

2장: 프로젝트 생태계

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

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

귀하의 사이트는 다음 네 가지 유형 중 하나와 밀접하게 관련되어 있을 수 있습니다.

브랜드 존재 – 제한된 시간 동안 회사와 일반 대중(제품 또는 서비스에 관심이 있는 모든 사람) 간의 관계를 촉진하는 상시 온라인 플랫폼 콘텐츠 소스 – 여러 유형의 미디어(기사, 문서, 비디오, 사진, 자습서) 사용자에게 정보를 제공하거나 참여시키거나 즐겁게 하는 것이 목적입니다. 작업 기반 응용 프로그램은 사용자가 중요한 작업 또는 워크플로를 수행할 수 있도록 하는 도구 또는 도구 모음입니다.

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

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

사이트 유형 식별

Dirk Knemeyer는 그의 기사 "브랜드 경험과 웹"에서 몇 가지 훌륭한 브랜드 정의를 제시합니다. 브랜드는 사람들이 회사, 제품 또는 사람과 맺는 지적 및 감정적 연관성을 나타냅니다. . 우리 모두. 브랜딩의 과학은 사람들의 마음을 계획하고 영향을 미치는 것, 즉 브랜드를 구축하는 것입니다.

서핑 회사 브랜드에 대한 고객의 경험과 브랜드 구축을 위한 회사의 노력 간의 차이점에 대한 자세한 내용은 "브랜드 경험과 웹" 기사에서 Dirk Knemeyer의 설명을 참조하십시오. www.digital-web.com/articles/brand_experience_and_the_web . 사이트의 UX 디자인이 개인의 브랜드 경험에 어떻게 영향을 미칠 수 있는지에 대한 훌륭한 논의는 Steve Baty의 기사 "사용자 경험 디자인의 브랜드 경험"(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의 "정보를 찾는 네 가지 모드 및 정보를 디자인하는 방법"을 읽어보십시오.

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

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

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

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

항목(예: 스프레드시트 또는 인쇄물) 비즈니스 내에서 중요한 작업 흐름을 지원하는 웹 도구 또는 응용 프로그램입니다.

비즈니스(예: IT 지원 팀용 티켓 관리 애플리케이션 또는 콜 센터용 고객 추적 애플리케이션) 개인 데이터에 액세스하고 관리할 수 있는 웹 사이트

(플리커처럼)

작업 기반 응용 프로그램의 기본 목표는 사용자가 자신의 요구와 궁극적으로 고객의 비즈니스 목표를 충족하는 일련의 작업을 완료할 수 있도록 하는 것입니다. 작업 기반 응용 프로그램의 설계 목표 대부분의 작업 기반 응용 프로그램은 사용자가 다른 곳에서는 할 수 없는 일을 할 수 있도록 허용해야 합니다.

더 잘하기 위해("더 나은"은 더 효율적이고 효과적으로, 더 큰 만족도를 의미하거나 더 편리함을 의미할 수 있음) 쉽게 접근할 수 있는 지침과 시각적 우선 순위로 초보 사용자를 지원합니다.

주요 작업 정의 중급 및 고급 사용자의 바로 가기 기능 사용 지원

사용자 부하를 줄이고 시스템 리소스를 최상의 방법으로 활용

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

2장: 프로젝트 생태계

필요한 변화 정도를 계획하고 고려하십시오.

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

전자 상거래 사이트 전자 상거래 사이트는 주로 전자 상거래를 목적으로 하는 사이트가 자체 브랜드를 보유하고 콘텐츠(일반적으로 제품 정보 또는 제품 사용 방법에 대한 설명)를 제공해야 하므로 네 가지 프로젝트 유형의 요소를 모두 포함할 수 있습니다. 작업을 용이하게 합니다(검색, 비교, 리뷰 작성, 체크아웃). 마케팅 캠페인은 종종 이러한 사이트와 밀접하게 연결되어 있으며 조직 내 여러 마케팅 팀이 포함될 수 있습니다. 전자 상거래 사이트의 일반적인 추가 디자인 목표에는 표준이 아닌 경우 사이트 디자인 설명이 포함됩니다. 온라인 마켓플레이스처럼

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

비교에서 구매까지, 유용한 콘텐츠와 기능. 교차 판매 및 상향 판매 경험 포인트 활용

주의를 산만하게 하지 않고 눈길을 끄는 방식으로 제안을 배치합니다. 구매 시점에서 커뮤니케이션 흐름 생성

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

E-Learning 애플리케이션 E-Learning 애플리케이션은 콘텐츠 소스와 작업 기반 애플리케이션 사이의 교차점입니다. 수업 내용을 생성해야 하며, 이를 위해서는 종종 팀에서 다룰 주제에 대해 학습 전문가와 주제 전문가(주제 전문가)의 역할을 추가해야 합니다. 이 제품은 사용자가 일반적으로 수업 과정을 따르고 진행 상황을 모니터링하거나 관련 주제를 조사해야 할 수도 있다는 점에서 작업 기반입니다. 일부 실용적인 수업에서는 과제를 완료해야 할 수도 있습니다. 일반적인 설계 목표에는 과정을 시작하는 데 필요한 기본 정보를 이해하는 것이 포함됩니다.

누구에게 전달되는지. 속도에 맞는 관리 가능한 청크로 콘텐츠 제공

이해. 실습 학습을 시뮬레이션하는 활동에 학습자를 참여시킵니다. 성과와 진행 상황을 전달하고 필요에 따라 제안합니다.

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

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

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

2장: 프로젝트 생태계

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

주요 기능(예: 사진 공유, 비디오 공유 및 채팅)을 지원합니다. 네트워크가 속해 있음을 확인하여 사이트의 무결성을 보호합니다.

자신의 정보를 관리하고 부적절한 행동에 대응하는 방법을 알고 있습니다. 지역사회의 힘을 활용하고 보여줌

인기있는 기능 및 리뷰와 같은 활동적인 회원에게만 가능합니다. 프로젝트 중에 작업할 수 있는 사이트 또는 응용 프로그램의 유형을 식별하는 것은 첫 번째 단계에 불과합니다. 다음으로, 종종 요구되는 다양한 역할과 프로젝트 유형에 따라 이들의 참여가 어떻게 달라질 수 있는지 고려해야 합니다.

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

모욕 전화하지 마십시오

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

2장: 프로젝트 생태계

프로젝트 팀의 다른 구성원이 대표하는 경우 프로젝트 시작 시 협력에 대해 논의하십시오.

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

User Researcher User Researcher의 역할은 사용자와의 조사를 통해 생성되거나 검증된 데이터를 기반으로 최종 사용자의 요구에 대한 통찰력을 제공하는 것입니다. 다양한 활동이 사용자 조사 범주에 속할 수 있으며 프로젝트 타임라인의 여러 지점에서 발생할 수 있습니다. (사용자 인터뷰, 설문 조사 및 사용성 테스트와 같은 일반적인 기술에 대한 설명은 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 Louis Rosenfeld의 "Evangelizing User Experience Design on Ten Dollars a Day": 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와 같은 애플리케이션에서 빠르게 만들 수 있지만 실제 데이터(예: 사용자가 방금 양식에 입력한 계정 정보)가 필요한 완전한 기능의 프로토타입은 가까운 시간에 완료해야 합니다. 미래. 배경 개발 팀원과의 협력. 이 모든 역할에 대해 걱정하십니까? 아주 작은 프로젝트 또는 아주 작은 회사에서 작업하는 경우가 아니면 모든 작업을 혼자서 수행하지는 않을 것입니다. 가장 중요한 것은 작업 중인 특정 프로젝트에서 필요에 따라 수행할 수 있는 역할과 수행하려는 역할을 이해하는 것입니다. 다른 곳에서는 클라이언트 회사 내에서 네트워크를 구축하거나 필요에 따라 추가 인력을 추천하여 프로젝트 팀에서 필요한 지원을 받을 수 있습니다. 이를 수행할 수 있는 방법에 대해 잠시 이야기해 봅시다.

모욕 전화하지 마십시오

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

충분히 명백하다. 주요 결함 영역에서 자신을 교육하십시오 – 새로운 책임이 있는 경우

재능은 다루기 쉬우며 그것에 전념할 시간이 있습니다. 회사 내에서 지원 네트워크를 구축하여 주요 상황에서 도움을 받으세요.

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

연락 창구 역할을 할 수 있는 부서. 비주얼 디자이너와 콘텐츠 전략가를 위한 리소스가 될 수도 있습니다. 시각 디자인 및 콘텐츠 전략을 위한 파트너도 찾을 수 있습니다.

프로그램이나 제품 관리, 또는 R&D, 운영 또는 기업 전략에서 비즈니스 분석가와 제품 관리자를 자주 찾습니다. IT 또는 엔지니어링 부서는 종종 사용자 인터페이스를 위한 최선의 선택입니다.

사이트의 분석 도구에서 정보에 액세스하고 정보를 얻는 데 도움을 줄 수 있는 개발자 및 다른 사람.

2장: 프로젝트 생태계

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

회사 문화 이해 문화는 유리잔에 Alka-Seltzer를 떨어뜨리는 것과 약간 비슷합니다. 눈에 보이지는 않지만 뭔가 하고 있습니다. -Hans Magnus Enzensberger

회사의 문화는 모든 영역, 비즈니스 단위 또는 부서에서 일관되지 않을 수 있지만 일반적으로 자신과 작업 중인 프로젝트에 영향을 미치는 주요 특성을 식별할 수 있습니다. 다음은 프로젝트를 계획하고 잠재적으로 까다로운 정치적 상황을 탐색할 때 염두에 두어야 할 몇 가지 고려 사항입니다.

회사 문화 이해

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

성공했고, 무엇이 그렇게 만든 것 같습니까? 실패한 것으로 보이는(또는 특히 고통스러웠던) 과거 프로젝트는 무엇이며 왜 실패했습니까? 이러한 질문을 하면(직접적으로 또는 더 미묘하고 대화적인 방식으로) 응답자가 성공을 정의하는 방법, 프로젝트에 대한 잠재적 위험, 이 프로젝트에 가져온 편견이나 기대 등 몇 가지 사항을 이해하는 데 도움이 될 수 있습니다. , 뿐만 아니라 잘 작동하는 접근 방식. 회사에서 디자이너와 협력하여 출판했습니까?

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

끝내지 않고 비정상적으로 긴 시간이 어떻게 보입니까?

2장: 프로젝트 생태계

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

UX 디자이너? 이것은 복합적인 축복일 수 있습니다. 반면에 당신은 디자인 요구를 이해하고 그 격차를 메우기 위해 노력한 팀을 상대하고 있습니다. 반면에 프로젝트의 사용자 경험 목표를 충족하지 않는다고 생각되는 템플릿이 제공될 수 있습니다. 이는 민감한 탐색 상황일 수 있습니다. 존경하는 멘토나 도움이 되는 컨설턴트의 어조로 그러한 디자인을 만든 사람에게 접근하는 것이 종종 가장 좋습니다. 먼저 디자인의 좋은 점을 지적한 다음 사용자 경험 목표에 대해 논의하고 다른 접근 방식으로 더 잘 달성할 수 있는 방법을 논의합니다. 크리에이터는 지원 네트워크의 귀중한 구성원일 가능성이 높으므로 여기에서 다리를 불태우는 것이 아니라 열정을 유지하기 위해 협력하여 역할을 재정의하는 것이 중요합니다. 리드 스폰서 또는 프로젝트 관리자가 특히 불안해 보입니까?

프로젝트에 대해? 여기에는 여러 가지 이유가 있을 수 있으며, 특히 위의 요인 중 하나가 관련된 경우에 그러합니다. 불안은 또한 시장 압력에 의해 야기될 수 있으며, 이해하는 것이 유용할 것입니다. 예를 들어 회사의 주가가 하락했습니까? 특정 경쟁자가 최근 놀라운 진전을 이루었습니까? 회사가 수익성이 없습니까? 다시 말하지만, 이러한 상황이 반드시 프로젝트를 진행해서는 안 된다는 의미는 아닙니다. 결국, 처음부터 프로젝트에 자금이 지원되는 경우가 많습니다. 그러나 회사가 청구서를 지불할 수 없는 것에 대해 심각한 우려가 있는 경우에는 그 위험을 고려해야 합니다.

회사 문화 이해

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

권력 거리는 "... 조직 및 기관(예: 가족)의 덜 강력한 구성원이 권력이 불공평하게 분배되는 것을 받아들이고 기대하는 정도입니다. 이것은 불평등(더 많음과 적음)을 나타내지만 위에서가 아니라 아래에서 정의됩니다. 그것은 제안합니다. 사회의 불평등은 지지자 편과 지도자 편에 똑같이 있다는 것을." Geert Hofstede 문화 차원 www.geert-hofstede.com

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

2장: 프로젝트 생태계

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

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

회사 문화 이해

통합 이제 프로젝트 영역을 살펴보았으므로 프로젝트 에코시스템, 즉 작업할 환경(회사 문화), 모두가 참여하게 될 전반적인 작업(예: 디자인할 사이트 유형) 및 상호 작용할 사람들(역할 및 책임 포함). 이 정보는 프로젝트에서 자신의 역할을 파악하고 비즈니스에 착수할 준비를 할 때 유용합니다. 프리랜서나 하청업체로 일하는 경우 프로젝트에서 수행한 작업에 대한 제안서를 작성하기 위한 기반을 제공합니다(UX 제안서에 대한 다음 장 참조). 더 큰 팀의 구성원으로 일하고 제안서 작성에 직접 관여하지 않는 경우 프로젝트 시작(팀의 첫 번째 회의)에 새로운 지식을 가져올 수 있습니다. 좋은 회의를 구성하기 위한 기본 지침은 온라인 장 "간단한 회의 안내"를 참조하고, 프로젝트를 시작할 때 묻는 질문에 바로 접근하려면 4장, "프로젝트 목표"를 참조하십시오. 접근하고."

2장: 프로젝트 생태계

삼

컨설턴트 및 프리랜서를 위한 제안 자신의 사업을 운영하는 사람들을 위한 가이드 프로젝트 및 클라이언트 기대치를 관리하는 것은 충분히 어려울 수 있지만 올바른 계약이 없으면 당황할 수 있습니다. 당신이 수행하는 모든 프로젝트의 끝. 제안 및 구인 광고는 귀하의 비즈니스와 귀하 자신을 재정 및 법적 문제로부터 보호하는 데 필수적입니다. 프로젝트와 악수를 승인했으면 충분한 시간을 들여 관계 조건과 고객의 지불 일정을 정의하는 계약서 초안을 작성해야 합니다. 러스 웅거

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

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

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

제안서 만들기 프로젝트를 받으면 제안서를 작성할 차례입니다. 제안서가 빨리 승인되고 서명될수록 작업을 더 빨리 시작할 수 있고 가장 중요한 작업에 대한 보수를 받을 수 있습니다. 좋은 제안서의 핵심 구성 요소는 제목 페이지입니다. 버전 기록 프로젝트 개요 프로젝트 접근 방식

제안서 작성

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

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

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

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

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

고객은 자신이 누구인지 알고 있습니다. 회사 로고 사용 허가를 요청하는 것은 수고와 노력을 기울일 가치가 없으며 실수로 잘못 사용할 경우 잠재적인 불편을 감수할 가치도 없습니다. 비용은 프로젝트의 다른 부분이 본문에서 식별되고 비용 정보가 지불 일정으로 편리하게 연결될 때 가장 잘 이해됩니다. 프로젝트의 참조 번호를 고려해야 합니다. 많은 회사에서 전혀 사용하지 않습니다. 그러나 일부 정부 기관은 이 특정 항목에 의존하는 것으로 알려져 있으며 제목 페이지에 해당 항목이 없으면 제안이 거부될 수 있습니다.

그림 3.1 예제 제안서의 제목 페이지

그림 3.1은 (가상) 고객 로고를 사용했습니다. 권한이 부여되지 않았거나 관계가 성립되지 않은 경우 클라이언트 회사의 로고를 표시해서는 안됩니다.

제안서 작성

버전 기록 버전 기록은 제안 자체의 일부이며 원래 버전 이후 제안을 업데이트한 횟수를 식별하는 데 사용됩니다. 일반적으로 독자에게 변경 사항에 대한 아이디어를 제공하기 위해 버전 번호, 날짜, 작성자 및 버전과 관련된 설명(예: 수정됨)을 제공하는 것이 가장 좋습니다(표 3.1). 표 3.1 개정

버전 이력 테이블의 예 SECTION

설명

공급자

날짜

원본 문서

REU

2009년 1월 8일

가정

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

REU

2009년 1월 11일

1.0 1.1

고객이 제안서에 서명한 다음 추가 수정을 요청하는 경우가 있습니다. 클라이언트를 계속 사용하고 이러한 변경을 수행하기로 결정한 경우 문서를 버전 1.x에서 버전 2.0으로 업그레이드할 기회를 가져야 합니다. 기본적으로 클라이언트가 제안을 수락하고 양 당사자가 조건에 동의하면 작업을 시작할 준비가 된 것입니다. 따라서 추가 변경 요청 시 매우 신중하게 검토해야 합니다. 이렇게 하면 비용이 여전히 합리적이고 양 당사자가 변경 사항과 프로젝트를 다시 시작할 시점(필요한 경우)을 명확하게 이해할 수 있습니다. 또한 버전 기록에서 버전이 완전히 새로운 버전을 구성하는 이유에 대한 적절한 설명을 항상 제공해야 합니다.

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

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

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

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

제안서 작성

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

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

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

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

문서를 업데이트하거나 프로젝트 가격을 다시 실행할 필요가 없도록 고객에게 전달할 수 있는 산출물만 포함해야 합니다.

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

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

제안서 작성

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

납품 납품은 귀하가 작성하여 고객에게 전달하는 작업 제품입니다. 이 섹션은 고객에게 프로젝트 중에 귀하에게 기대할 수 있는 작업 결과물 유형을 알려줄 수 있는 기회입니다. 프로젝트가 끝날 무렵 상태 보고를 별도로 처리하는 것이 좋지만 프로젝트의 이 부분에 추가할 수 있습니다. 작업 산출물이 생산되지 않은 경우에도 포함될 수 있는 작업 산출물에 대한 설명을 제공하십시오. 이것은 정상이 아니거나 "[전달할 유형]에 대한 제안에 대해 읽었지만 여기에서는 볼 수 없습니다"라는 웜 캔을 열 가능성이 있는 것처럼 보일 수 있지만 한 마디만 하면 오 , 모든 차이를 만들 수 있습니다. 산출물 [귀사의 회사 이름]은(는) 프로젝트 동안 다양한 산출물을 제공합니다. [Customer Company Name]에 대한 다음 배송을 확인했습니다.

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

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

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

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

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

추가 비용 및 수수료 고객이 프로젝트 가격 책정 시 외부 리소스를 고려하는지 여부를 이해하는 것이 중요합니다. 예를 들어 일부 프로젝트는 공급업체로부터 스톡 사진을 구매해야 할 수 있습니다. 이미지를 구매하고(적절한 사용 권한 포함) 지불의 일부로 포함하거나, 고객에게 지불해야 할 추가 비용으로 이미지 구매를 명확하게 식별할 수 있습니다. 고객에게 알리고 싶은 서비스를 제공할 수도 있습니다. 이러한 서비스를 광고할 수 있는 좋은 기회입니다. 다음은 추가 비용 및 수수료 처리 방법의 예입니다. 추가 비용 및 수수료 외부 리소스(예: 콘텐츠, 이미지, 글꼴 등)가 필요한 경우 [고객 회사 이름]에 식별, 승인 및 청구서를 발행해야 합니다. 또한 [회사 이름]은(는) 매우 낮은 간접비로 고객에게 호스팅 서비스를 제공할 수 있습니다. 구성 가능한 웹 기반 이메일을 포함한 호스팅 서비스를 월 $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]의 견적은 비용과 필요 측면에서 유연성을 허용합니다. 등급은 다음과 같습니다. 등급 1 [귀하의 회사 이름]은 대화형 콘텐츠 없이 [고객 회사 이름]에 대해 [프로젝트]를 평가했습니다…

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

지불 일정 모든 프리랜서 프로젝트는 작업 시작 전에 선불로 50%를 지불하고 프로젝트 완료 후 50%를 지불한다는 신화가 떠돌고 있습니다. 이 신화를 폭로해야 합니다 – 지금! 이것은 사업을 하는 방법이 아니며 업무를 수행하는 동안 시기 적절하고 일관된 수입을 보장하지 않습니다. 변경 주문 프로세스를 통해 작업하는 대신 프로젝트를 완료하고 비용을 받고 싶다는 이유만으로 고객을 위해 변경해야 하는 상황에 처하고 싶지 않을 것입니다. 미리 결정된 시간에 송장을 보내는 것부터 이정표를 기준으로 한 지불에 이르기까지 다양한 방법으로 프로젝트 가격을 책정할 수 있습니다. 더 현명한 접근 방식은 정기적이고 상세한 송장을 사용하여 프로젝트를 반복 지불 일정으로 조정하는 것입니다. 이 접근 방식은 또한 클라이언트가 완료된 작업과 프로젝트에 남아 있는 작업에 대한 명확한 이해를 제공해야 합니다. 다음 예는 작업에 대한 지불을 구성하는 한 가지 방법입니다. 지불 일정 [회사 이름] 일반적인 지불 일정은 시작하기 전에 프로젝트 총 예상 비용의 XX%를 받는 것입니다. [회사 이름]은(는) 매월 1일과 15일에 인보이스를 보냅니다. 지불은 14일 이내에 전액 지불되어야 합니다. 프로젝트가 완료되면 [회사 이름]은(는) 모든 작업 제품을 [고객 회사 이름]에 전달합니다. 자료가 만족스럽게 수락되면 [귀하의 회사 이름]은(는) 보관인의 초과 지불액을 환불하거나 [귀사의 회사 이름]은(는) 보관인이 부담하지 않는 금액에 대한 최종 청구서를 제공합니다. 참고: [프로젝트]가 진행 없이 14일 이상 보류된 경우 [회사 이름]은(는) 보류에 포함되지 않은 모든 비용에 대한 최종 청구서를 제공하고 프로젝트가 다시 열리면 먼저 거부할 권리를 갖습니다.

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

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

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

제안서 작성

보증인: [귀하의 회사 이름]의 공식 대리인.

[고객사명]

게시자: ________________________________________

작성자: _________________________________

작성자:_______________________________

제목: ___________________________________

제목: ______________________________

날짜: __________________________

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

작업 명세서 작업 명세서(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 Tognazzi의 디자인 원칙 목록(www.asktog.com/basics/firstPrinciples.html)을 참조합니다. 사이트의 주제에 익숙해지면 특히 둘 이상의 사이트를 분석하는 경우 원하는 경우 몇 가지를 추가할 수 있습니다. 목록이 관리 가능한 크기인지 확인하십시오(예: 8-12). 너무 많은 휴리스틱은 당신과 당신의 독자들에게 기술을 번거롭게 만들 수 있습니다. 3. 사이트의 우선 순위가 지정된 영역을 살펴보고 휴리스틱을 잘 따르는 영역과 무시하는 영역을 식별합니다. 각 관찰에는 다음 정보가 포함되어야 합니다. 일반적인 관찰. 발견에 대한 간략한 설명. 이상적으로는 보고서를 통해 사람들을 안내할 때 빠르게 참조할 수 있도록 번호가 매겨져 있습니다. 빠른 설명. 관찰의 맥락을 설명하는 한두 개의 단락(예: 문제를 관찰한 특정 프로세스의 지점). 충격 등급. 이 등급은 문제 관찰에 대해 높음, 중간 또는 낮을 수 있으며 사이트에서 잘한 것을 공유하는 경우 긍정적인 관찰일 수 있습니다. 일반적으로 큰 문제는 많은 사용자가 특정 작업에서 실패하거나

5장: 비즈니스 요구 사항

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

큰 관심사

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

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

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

현재 상태 이해

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

5장: 비즈니스 요구 사항

대체로 책임 영역 비즈니스 요구 사항 수집에는 일반적으로 아이디어를 수집하기 위해 주요 비즈니스 이해 관계자와 프로젝트 팀원을 인터뷰하는 것이 포함됩니다. 비즈니스 이해 관계자는 회사 내에서 프로젝트의 성공에 비즈니스 지향적인 기여를 하거나 해당 주제에 대한 전문 지식을 가진 사람 또는 둘 다입니다. 이 사람들은 프로젝트에 전임으로 참여하지는 않지만 프로세스의 주요 지점에 참여해야 하며 요구 사항 수집이 그 중 하나입니다. 그들은 또한 (말하자면) 하루 일과를 가지고 있기 때문에 그들의 시간은 소중하고 미리 계획하지 않으면 종종 얻기가 어렵다는 것을 기억하십시오. 프로젝트의 자금 조달자(또는 스폰서)는 프로젝트의 성공에 직접적인 책임이 있는 비즈니스 이해관계자이며, 종종 관리자와 같이 회사에서 상대적으로 높은 수준에 있습니다. 그는 프로젝트의 수명 주기 동안 매일 프로젝트에 참여하지는 않지만 요구 사항을 수집하고 비즈니스 이해 관계자의 높은 참여를 보장하는 데 적극적으로 참여할 가능성이 높습니다. 후원자는 일부 또는 모든 세션에 참석할 수도 있습니다. 프로젝트 그룹에는 지속적인 리소스로 프로젝트에 공식적으로 할당된 사람들이 있습니다. 그들은 프로젝트 관리자, UX 디자이너, 비즈니스 분석가, 기술 이사, 비주얼 디자이너, QA 관리자 등으로 참여할 수 있습니다. 프로젝트의 규모에 따라 이것이 주요 역할일 수 있습니다. 프로젝트 팀 자체 내에서 요구 사항 수집 중 책임이 명확하지 않은 경우가 많습니다. 조기에 부채를 결정하는 데 시간을 들이면 효율적인 징수 프로세스를 보장할 수 있습니다. 다음은 요구사항 수집 중에 각 팀 구성원이 지게 될 특정 책임을 정의할 때 물어봐야 할 몇 가지 질문입니다. 올바른 활동을 수집하고 일정을 잡는 일을 주로 담당하는 사람은 누구입니까?

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

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

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

나중에 누가 누구를 따라합니까? 기술 팀의 누군가가 모든 회의에 참석합니까?

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

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

정보가 사이트에 표시되어야 하는 마케팅 캠페인)

5장: 비즈니스 요구 사항

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

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

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

주요 제품 및 서비스 채용 목표를 달성하기 위한 인적 자원 PR, 투자자 및 미디어에 알리기 위해 개발해야 하는 기타 관계를 담당하는 모든 그룹

파트너 또는 공급업체와의 관계와 같이 프로젝트의 일부로 디자인에 영향을 미칩니다. 포함되어야 하는 사람을 선택할 때 프로젝트 스폰서와 참여 그룹에 익숙한 프로젝트 팀원에게 올바른 사람을 선택하는 데 도움을 요청하십시오. 사람들. 좋은 대화를 촉발하는 그룹을 만듭니다. 이를 수행하는 올바른 방법은 없지만 한 가지 일반적인 방법은 다음과 같이 부서별로 이해 관계자를 그룹화하는 것입니다. 마케팅(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장: 비즈니스 요구 사항

상호 작용하는 역할(예: 구직자 대 고객 또는 상호 작용)

텐트 생산자 대 공급업체) 1차 납품 널리 참조됨(운영 정보

데이터, 와이어프레임, 사이트맵) 및 차이점에 대한 간략한 설명 서로 다른 데이터 수준 간의 차이점(예: 클래스)

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

아이디어를 듣고 요구사항에 대해 알아보십시오. 이해관계자는 요구사항으로 보이는 진술을 할 수 있습니다. 예를 들어 보겠습니다. 비즈니스 옹호자

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

비

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

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

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

완료 우선 순위 지정 및 모니터링을 위한 별도의 작업 단위로 작동

아이디어에서 요구 사항으로 이동하기 시작할 때 기술 책임자(또는 프로젝트 개발 팀을 대표할 수 있는 다른 사람)가 참여하여 나중에 우선 순위를 정할 때 필요한 작업량을 측정하는 데 도움이 되는 질문을 하도록 합니다. 전담 QA 팀 구성원이 있는 경우 요구 사항을 통합하는 데 도움이 되는 매우 상세한 질문을 할 수도 있습니다. 추적 아이디어의 요구 사항을 구체화하려면 추적이 얼마나 정확해야 하는지와 같은 질문을 하십시오. 추적 데이터에 포함되어야 하는 정보는 무엇입니까? ~을 위한

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

5장: 비즈니스 요구 사항

그런 다음 프로젝트 스폰서와 함께 요구 사항을 검토하여 선택이 비즈니스에 적합한지 확인합니다. 표 5.1에는 모니터링 아이디어와 관련될 수 있는 요구 사항과 이를 고려하는 방법이 나열되어 있습니다. 표 5.1

비즈니스 요구 사항의 예

ALUE

주문 추적

삼

주문 추적

요구 사항

비즈니스 요구 사항

주문 추적 가능

셀프 서비스 장려

추적 코드 입력

배달 중 (지원

온라인

혜택)

사용자는 패키지를 추적할 수 있습니다.

혁신을 효과적으로 보여주다

트럭을 따라 GPS로 나이

빠른 배송(경쟁력

또는 비행기

혜택)

사용자는 지난 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장에서 만든 목표를 기억하십시오. 또한 선택을 안내하는 데 도움이 될 것입니다. 이 예는 속성의 우선순위를 가장 잘 보여줍니다. 주식, 옵션 및 선물의 온라인 거래를 위한 도구를 제공하는 회사와 협력한다고 가정해 보겠습니다. 이 회사는 온라인에서 주식을 직접 거래하는 비전문가를 참여시키고 옵션 및 선물과 같은 새로운 유형의 제품 거래를 시도하도록 권장하는 것이 전략의 일부라고 결정했습니다. 회사는 사용하기 쉽고 안전한 환경에서 실습을 원하는 사람들을 대상으로 하는 거래 도구를 제공함으로써 이를 수행할 계획입니다. 비즈니스 이해 관계자와 속성을 논의할 때 개인이 이러한 도구를 사용하는 방법에 다음이 가장 큰 영향을 미치는 것으로 나타날 수 있습니다. 현재 거래 빈도, 특히 직접 온라인 거래 빈도.

(예: 분기에 한 번, 하루에 한 번, 하루에 여러 번). 캐주얼하게만 거래하는 사람들(예: 한 달에 한 번)은 새로운 것을 시도하는 것에 대해 진지하지 않을 수 있는 반면, 풀타임으로 거래하는 사람들은 새로운 거래자를 겨냥한 도구에서 많은 가치를 찾지 못할 수 있습니다. 그러나 활동적인 시간제 트레이더는 회사의 도구에 매우 관심이 있을 수 있습니다. 판매된 제품 유형의 수: 주식만 또는 공유, 옵션 및

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

전문성 수준(예: 거래 지식

자귀). 이것은 튜토리얼과 어휘를 통해 그들이 얼마나 많은 도움이 필요한지 결정하는 데 도움이 됩니다. 기술 능력 수준(예: 쇼핑 지식

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

높은

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

풀타임 제품 전문가

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

직접 거래 빈도

"부업" 트레이더

추가 수입 가맹점

활동적인 연구원

장기 투자자

열려 있는

아마추어

열려 있는

높은

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

6장: 사용자 연구

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

이 사용자 모델은 다양한 유형의 사용자를 논의하는 높은 수준의 방법을 제공합니다. 이는 최종 모델이 아니며 사용자 그룹을 독점적으로 나타내지 않습니다(사용자는 주식의 장기 투자자일 수 있으며 옵션 또는 선물의 다른 기회를 적극적으로 탐색할 수도 있습니다). 그러나 다양한 사용자 그룹에 대한 이해와 그들이 사이트를 사용하도록 동기를 부여하는 방법을 표현하기 시작합니다. 중요한 기능에 대한 이 논의는 연구를 위해 사용자를 모집할 때 집중할 기능을 결정하는 데에도 도움이 됩니다. 거래 빈도가 중요하고 기본 목표가 현재 중간 빈도를 가진 사람들을 포함하는 것이라고 결정한 경우 중간 빈도의 의미(예: 일주일에 1~3회)를 정의하고 그에 따라 연구 참가자를 모집해야 합니다. 연구에 대해 이야기할 때 사용자를 프로젝트에 참여시키는 데 사용할 수 있는 기술에 대해 이야기합니다.

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

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

연구 기법의 선택

표 6.1

일반적인 사용자 조사 기법

활동

그것이 무엇인가

유용할 때

도전

일반적인 시간*

사용자 인터뷰

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

사용자는 액세스할 수 있지만 액세스 유형(직접 방문, 전화 등)은 다양합니다.

명확한 의견을 얻습니다. 특히 인터뷰가 원격으로 진행되는 경우 태도와 상황에 대한 데이터를 수집하는 것이 어려울 수 있습니다.

12회 면접 2~4주 : 기획 1주일, 면접 1~2주, 결과 정리 1주일

상황 조사

참가자와 함께 현장을 방문하여 정상적인 일상 환경에서 어떻게 작동하는지 관찰하고 학습합니다.

Access to Access 프로젝트 팀은 참가자에 대한 정보가 거의 없습니다. 대상 사용자에게 이동합니다. 사용자가 고유한 환경에서 작업하면 보안, 정신 문제(예: 병원)가 발생할 수 있습니다. 자산 및 손상된 사용자는 밀접하게 작동합니다. 상당히 복잡한 애플리케이션의 비즈니스에서는 실행 또는 워크플로우를 수행합니다. 평일에 방문하면 더 쉬울 수 있습니다.

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주.

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

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

시험 응시 형식 결정.

* 일반적인 시간 프레임은 사용자 시점에서 자주 요구되는 시간을 나타냅니다. 기본값은 2~6~8개의 사용자 그룹입니다(사용자 수가 더 많아야 하는 설문 조사 제외). 여기에는 선별 설문지 작성 후 1~2주가 소요될 수 있는 모집 시간은 포함되지 않습니다.

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

두 개 이상의 활동을 설계하거나 여러 번 수행하는 하나의 활동(예: 설계 테스트, 결과에 따라 변경, 새 설계 재테스트). 조직의 아무도 사용자 조사에 익숙하지 않고 약간의 저항이 있는 경우 한 라운드의 조사를 제안하고 귀하, 프로젝트 팀 및 비즈니스에 가장 큰 가치를 추가할 것이라고 생각하는 기술을 선택하는 것이 좋습니다. 이해 관계자. 연구 결과를 얻으면 프로젝트 팀은 그것이 수반하는 것과 프로젝트가 어떻게 이익을 얻을 수 있는지 더 잘 이해할 것입니다. 그러면 나중에 필요한 경우 더 많은 연구를 포함해야 할 강력한 이유가 있습니다. 최소 2회 이상의 조사를 할 여지가 있는 경우 정의 단계 또는 디자인 단계 초기에 1회를 포함하여 사용자를 더 잘 이해하는 것이 좋습니다. 그런 다음 디자인을 확인하기 위해 개발을 시작하기 전에 한 번 더 포함합니다. 예를 들어 작업 기반 애플리케이션에서 디자인 전에 사용자 인터뷰를 수행한 다음 프로세스 후반에 프로토타입의 사용성 테스트를 수행할 수 있습니다. 또는 콘텐츠 소스의 경우 상황별 조회로 시작한 다음 카드 정렬 연습을 포함할 수 있습니다.

연구를 계획할 때 고려해야 할 사항 연구 기법을 계획할 때 다음 사항을 고려하십시오. 연구를 수행하는 이유: 조사를 통해 무엇을 배우고 싶은지 참여 대상: 위에서 언급한 기본 사용자 그룹 참가자 확보 방법: 참여할 사람 모집 (즉, 대상 그룹에 속하는지 확인하기 위해 질문하기) 참가자들에게 보상하는 방법 필요한 공간과 장비 다루는 것: 우선 순위 주제 데이터 수집 방법: 관련된 사람들의 수와 그들이 사용하는 도구 Chapter 13 UX 디자이너를 위한 가장 일반적인 기술 중 하나인 사용성 테스트에 대한 자세한 내용의 일부로 이러한 모든 측면을 다룹니다.

6장: 사용자 연구

참고 작업 기반 응용 프로그램 및 콘텐츠 소스에 대한 자세한 내용은 2장을 참조하십시오.

Surfer Steve Baty는 다양한 방법과 개발 단계, 데이터 요구 사항 및 사용자 연구 유연성에 따라 방법을 선택하는 방법을 설명하는 기사를 작성했습니다. Steve Baty, UXmatters: http://uxmatters.com/MT/archives/000287.php의 "Bite-Sized UX Research"라고 합니다.

이러한 각 기술과 일반적으로 사용되는 방식을 살펴보겠습니다.

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

연구 기법의 선택

참가자가 인지하는 회사의 브랜드 예를 들어 다루는 주제 범주에 대한 태도(con-

텐트 소스), 설계할 프로세스(작업 기반 애플리케이션의 경우) 또는 마케팅 방법(마케팅 캠페인의 경우) 사용자를 귀하의 사이트로 유도하는 공통 목표 또는 요구 사항 또는

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

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

지금까지 사용자 그룹으로 구성되었습니다. 예를 들어 임시 사용자 모델을 만들 때 논의한 변수가 실제로 사용자가 사이트를 경험하는 방식에 영향을 미치는 것 같습니다. 두 명 이상의 사람이 인터뷰를 진행하는 경우 인터뷰의 일관성을 유지하기 위해 질문 목록과 소개 스크립트를 작성하는 것이 좋습니다. 원하는 인터뷰 구조를 미리 선택하십시오. 공식적인 보고서를 작성하려는 경우 질문 순서가 크게 다르지 않고 각 질문에 몇 가지 추가 사항이 표시되는 높은 수준의 구조를 원할 것입니다. 풍부한 정보가 일관성보다 더 중요한 경우 질문 목록으로 시작하지만 대화가 면접관이 더 흥미로운 의견을 탐색하기 위해 질문을 하는 자연스러운 경로를 따르도록 하는 반구조화된 인터뷰를 선택할 수 있습니다(프로빙이라고 함). ). 인터뷰 시간은 다를 수 있습니다. 45-60분은 종종 최고의 촬영 거리입니다. 참여자를 지치게 하지 않으면서 관계를 구축하고 다양한 문제를 다룰 수 있는 충분한 시간을 제공합니다. 사용자 인터뷰는 7장에서 논의된 페르소나를 작성하는 데 사용할 수 있는 풍부한 정보를 제공합니다.

6장: 사용자 연구

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

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

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

그리고 후자가 의사보다 낫다고 생각하는 이유는 무엇입니까? 여기에는 몇 가지 문제가 있습니다. 하나의 진술에 두 가지 질문을 하고 참여자에게 암묵적인 의견을 강요합니다. 더 나은 질문은 다음과 같습니다. 가장 최근에 PseudoCorporation.com을 방문한 것에 대해 알려주십시오. 왜 거기에 갔습니까? 당신의 방문에 대해 무엇을 기억합니까?

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

연구 기법의 선택

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

그들이 얼마나(또는 적게) 사생활을 가지고 있는지, 얼마나 자주 방해를 받는지, 그들이 전화기와 종이를 어떻게 사용하는지(손에 들고 다니는 인쇄물이나 메모에 특히 주의를 기울이십시오). 그들은 키보드에 대해 마우스를 사용하기를 원합니다. 이것은 큰 차이를 만들 수 있습니다

특히 많은 데이터 입력이 필요한 도구를 디자인하는 경우 디자인 선택 사항입니다. 다른 사람들과 공동 작업 및 공동 작업을 수행하는 방법

자원. 예를 들어, 한 컴퓨터를 여러 사람이 사용하는 경우 로그인 디자인 및 보안 기능에 영향을 미칩니다. 온라인과 오프라인 모두에서 사용하는 다른 도구입니다. 사람들이 종이를 사용하는 방법

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

6장: 사용자 연구

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

연구 기법의 선택

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

패턴은 여러 가지 방법으로 만들 수 있으므로 스스로 형성되도록 하는 것이 가장 좋습니다. 그러나 다음은 표시될 수 있는 범주 유형의 몇 가지 예입니다. 여기에 포함된 설명의 종류도 포함됩니다. 정신 모델(사용자가 어떻게 행동하는지 보여주는 어설션 포함

외부 경험을 내부 사고에 매핑): "나는 이 온라인 도구를 내가 많이 참조하지만 가지고 다니고 싶지 않은 것에 대한 포트폴리오로 사용합니다." 아이디어 및 기능 요청: "실행 취소 기능이 있으면 좋겠습니다.

실수로 전체 폴더를 이동했는데 삭제하는 데 너무 오래 걸립니다." 좌절감: "이 헬프 데스크에 문의하고 싶지만 절반은 그렇지 않습니다.

문제가 뭔지 알아."

100

6장: 사용자 연구

해결 방법: “이 작업을 수행하는 데 시간이 너무 오래 걸려서 인쇄를 마칩니다.

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

변화는 그것을 가져가지 않는다!"

심해 잠수 컨텍스트 연구의 핵심 리소스는 Hugh Beyer와 Karen Holtzblatt(Morgan Kaufmann, 1997)의 컨텍스트 디자인입니다. 이 책에는 친화도 플로팅과 같은 기술을 사용하여 결과를 해석하는 방법에 대한 자세한 정보도 포함되어 있습니다. 멘탈 모델과 이를 이해하는 방법에 대한 자세한 내용은 Indi Young의 저서 Mental Models: Aligning Design Strategy with User Behavior(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

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

특정 수의 참가자에 도달할 때까지 또는 특정 마감일에 도달할 때까지 중 먼저 도래하는 시점까지 설문조사를 실행할 수 있습니다. 데이터를 수집하고 분석하기 위해 어떤 도구를 사용합니까?

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

포커스 그룹 포커스 그룹은 대상 청중 내에서 서로 다른 사람들을 모으고 그들과의 대화를 촉진합니다. 공통 목표에는 이전 경험, 관련 요구 사항, 느낌, 태도 및 개선 아이디어와 같은 조직 또는 브랜드와 관련된 주제에 대한 의견 도출이 포함됩니다. 포커스 그룹은 다양한 목적을 위한 좋은 기술입니다. 다양한 사용자의 이야기를 듣는 것입니다. 공개 토론은 문제를 제기하는 좋은 방법입니다.

우리 모두의 이야기꾼을 꺼내십시오. 포커스 그룹이 잘 진행되면 개인은 서로의 이야기와 아이디어를 기반으로 구축하고 보다 구조화된 개인 인터뷰에서는 할 수 없는 상황을 회상합니다. 그룹 형식과 에너지는 사람들에게 이러한 이야기를 기억하고 공유할 시간을 줄 수 있습니다. 경험의 의미 있는 차이를 이해합니다. 대부분의 사람들은 자연

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

디자이너는 종종 팀에서 직접 또는 작업 프로세스나 좌절에 대해 듣고 새로운 기능이나 디자인에 대한 훌륭한 아이디어를 얻습니다. 이해관계자의 아이디어와 마찬가지로 핵심 요구 사항(4장 참조)을 다시 추적하여 고려하도록 합니다. 협력 프로세스의 여러 측면을 이해합니다. 당신이있는 경우

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

104

6장: 사용자 연구

사람들이 어떻게 상호 작용하는지에 대해. 예를 들어 인트라넷과 같은 콘텐츠 소스로 작업하는 경우 콘텐츠 제작자, 편집자 및 콘텐츠 사용자를 모아 프로세스를 개선할 수 있는 영역을 식별하는 것이 유용할 수 있습니다. UX 연구에서 포커스 그룹의 사용에 대해 많은 논의가 있습니다. 이것은 사용성 테스트에 좋은 기술이 아니며(사용자는 대부분 그룹이 아닌 혼자 작업하기 때문에) 때로는 그룹 설정이 참가자 진술에 과도하게 영향을 미칠 수 있습니다. 그러나 포커스 그룹을 잘 계획하고 관리하면 계획 단계에서 가치 있는 많은 통찰력을 얻을 수 있습니다. 13장에서는 개념 테스트와 관련하여 이에 대해 자세히 설명합니다. 기본 프로세스 포커스 그룹 질문을 작성할 때 사용자 인터뷰 질문을 작성할 때 사용하는 것과 동일한 팁을 고려하십시오(앞에서 논의됨). "PseudoCorporation.com에 마지막으로 방문한 일에 대해 말해주세요. 왜 거기에 갔습니까?"와 같은 쉬운 질문부터 시작하세요. 참가자들이 귀하, 서로, 그리고 주제에 익숙해지면 그룹 중간에 브레인스토밍 질문을 저장하십시오. 각 주제에 대한 시간 블록을 설정하고 이를 고수하십시오. 대화가 쉽게 시작되고 시간이 훌쩍 갑니다! 시간이 걱정된다면 가장 중요한 질문을 주제 목록의 중간에 배치하세요. 사람들이 행동에 익숙해진 후, 하지만 마지막에 발생할 수 있는 잠재적인 시간 낭비가 발생하기 전에 말입니다. 포커스 그룹의 물류 대부분은 사용성 테스트와 동일합니다. (선별, 모집 및 일정에 대한 제안은 13장을 참조하십시오.) 포커스 그룹과의 주된 차이점은 참가자들이 서로 쉽게 상호 작용할 수 있도록 테이블이 있는 더 큰 방이 필요하다는 것입니다. 1-2시간 그룹 세션에서 6-8명의 사진을 찍습니다. 모두가 서로의 이름을 부를 수 있도록 각 사람에게 이름표나 장소 카드를 줍니다. 토론 자체의 형식에는 다음과 같은 핵심 사항에 대한 소개가 포함되어야 합니다. 진행자로서의 역할과 이를 통해 얻고자 하는 것.

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

연구 기법의 선택

105

참가자가 참여하도록 선택된 이유(예: "당신은 모두

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

기밀성의 관점에서. 중재자로서 당신은 그들의 의견을 듣고

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

하나의 주제를 논의하여 모든 주제를 다룰 수 있는지 확인하십시오. 그런 다음 이것은 종종 일종의 아이스 브레이커 질문을 포함하는 그룹 구성원에 대한 소개 라운드로 바뀔 수 있습니다. 귀하의 목표는 짧은 이야기만 하더라도 모든 사람이 첫 번째 질문에 대해 이야기하게 하는 것입니다. 한 사람부터 시작하여 테이블을 둘러보거나 사람들이 자연스럽게 응답하게 한 다음 아직 응답하지 않은 사람들의 이름을 부르도록 할 수 있습니다. 종종 처음 몇 가지 질문에 대해 테이블을 돌아다녀야 하며 그룹이 준비되었다고 느끼면 몸짓 언어를 사용하여 모든 사람에게 질문을 열 수 있습니다.

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

아직 응답하지 않은 사람에게 전화를 걸 때 상대방이 이해하지 못하거나 최신 정보를 듣지 않은 경우 다시 질문하십시오.

106

6장: 사용자 연구

토론에서 몇 가지 진술. 또한 의견의 차이가 두 사람 사이의 불일치처럼 보이지 않게 하십시오. "밥, 아직 소식이 없어요. 크리스가 방금 한 말에 대해 어떻게 생각하세요?" 그러나 (Bob을 바라보며): "Bob, 당신은 어떻습니까? Pseudo Corporation의 고객 서비스에 대한 귀하의 경험은 어떻습니까?" 중재자는 대화의 흐름을 제어하고 가상 마이크를 전달합니다. 눈맞춤, 말의 양, 팔의 움직임 및 몸의 방향을 사용하여 통제력을 유지합니다. 대부분의 사람들은 당신의 바디 랭귀지를 잘 알고 있으며 누군가가 대화를 주도하고 있다면 이러한 단서가 유용한 신호가 될 수 있습니다. 지나치게 목소리를 내는 참여자가 이러한 단서를 알아차리지 못하는 경우 "좋아요. 이 아이디어를 다른 사람들에게 공개하고 싶습니다. 다른 사람도 테레사와 같은 문제에 직면한 적이 있습니까? 언제 새롭고 더 큰 주제로 이동하여 사람들이 다음 주제에 대해 마음을 비울 수 있도록 이전 토론이 끝났고 새로운 토론이 곧 시작된다는 것을 구두로 나타냅니다. 시계와 몸의 방향을 바꾸면 토론이 끝나야 한다는 신호가 될 수 있습니다. 다른 모든 활동과 마찬가지로 시간을 내어 준 것에 대해 그룹에 감사해야 합니다. 팀과 결과를 공유하는 것은 일반적으로 두 가지 방법으로 이루어집니다. 주요 주제를 다루거나 관련 범주로 그룹화하여 상황에 맞는 연구를 수행합니다. 친화도 다이어그램은 프로젝트 팀을 설명하기 위해 서로 다른 경향과 태도를 함께 가져오는 또 다른 효과적인 방법이 될 수 있습니다.

카드 분류 카드 분류 활동에서 참가자(혼자 또는 소그룹으로 작업)는 카드에 인쇄된 물건을 주고 그들이 의미가 있다고 생각하는 그룹으로 분류하도록 요청합니다. 미리 주어진 범주로 그룹화하거나(폐쇄 정렬이라고 함) 자체 그룹을 만들고 각 그룹에 이름을 지정합니다(개방 정렬이라고 함). 카드 분류 라운드가 끝날 무렵에는 사람들이 분류하는 방식에서 공통적인 패턴과 일반적인 혼란 또는 불일치를 보기 시작해야 합니다.

연구 기법의 선택

107

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

공통 콘텐츠 소스인 회사의 인트라넷에서 작업 중이라고 가정해 보겠습니다. 많은 인트라넷은 정보를 소유한 부서별로 정보를 분류하여 인적 자원, 운영, 법무, 마케팅 등으로 이동하는 경향이 있습니다. 장기 근속 직원의 경우 각 부서의 책임을 배우고 정보를 찾을 수 있는 위치에 대한 이해를 구축했기 때문에 이는 명백한 문제가 아닐 수 있습니다. 그러나 신입 사원이나 일반적으로 참조하지 않는 정보가 필요한 사람의 경우 둘 이상의 부서에 속할 수 있는(또는 어느 부서에도 속하지 않는 것처럼 보이는) 정보를 찾기 어려울 수 있습니다. 예를 들어, 신입 사원과의 계약 체결 정책은 어디에서 찾을 수 있습니까? 법이나 인적 자원에 속할 수 있습니다. 카드 정렬을 사용하면 잠재적인 사용자가 부서 라인에 관계없이 정보를 분류하는 일반적인 패턴을 찾을 수 있습니다. 기본 프로세스 카드 정렬에 포함할 항목을 수집합니다. 40-60은 일반적으로 좋은 범위입니다. 잠재적으로 많은 수의 카드 데크를 만들 수 있을 만큼 충분히 필요하지만 참가자가 옵션에 압도당하거나 결과를 분석해야 할 때 압도당할 정도는 아닙니다. 이해하기 쉽고 불필요한 전문 용어가 포함되지 않은 항목을 선택하십시오. 사용자 그룹이 알 것 같은 관련 용어를 포함할 수 있지만 너무 많은 내부자 용어는 피하십시오. 판매 촉진을 위한 "SUCCESS 캠페인"과 같은 회사 고유의 용어나 약어를 너무 많이 사용하는 경우 공통 정보 계층 구조를 구축하는 것이 아니라 회사 마케팅 및 커뮤니케이션의 효과를 테스트하는 것입니다. 인트라넷의 예에서 휴가 정책, 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세의 인증된 손 치료사 "Nicolle"과 큐브를 공유하면 그녀에게 잘 작동하는 경험을 제공해야 한다는 강박감을 느끼기 시작합니다. 그것이 도움이 된다면 잠잘 때 인쇄된 사본을 가지고 다니고 삼투의 요정이 페이지에서 베개를 통해 잠자는 잠재의식으로 공감을 전달하도록 하세요. 페르소나의 목적은 귀하, 귀하의 팀 및/또는 귀하의 고객이 의사 결정의 갈림길에 도달했을 때 발생할 수 있는 혼란을 제거하도록 돕는 것입니다.

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

페르소나 만들기 청중을 식별하고 페르소나를 지원하기 위한 데이터를 수집했으면 다음 단계는 종이에 펜을 놓고 생명을 불어넣는 것입니다. 생성해야 하는 페르소나의 수는 다양합니다. 일반적으로 최소값은 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이 "작성"한 것이 아니라 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

올바른 이미지를 찾는 것은 주의하지 않으면 시간 낭비일 수 있습니다. 다른 모든 방법이 실패하면(또는 시간과 예산이 있는 경우) 귀하의 것을 얻으십시오! 이름 간단히 말해서 얼굴에 이름을 부여해야 합니다. 당신이 사용하는 사진은 연구 데이터와 성격 특성의 조합을 인간화하며, 이름은 대화 중에 모두가 당신을 지칭하는 이름이 될 것입니다. Nico는 "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

당신이 만드는 대부분의 사람들의 분모. 대부분의 경우 이러한 선택적 콘텐츠 요소 중 일부를 핵심 페르소나에 연결합니다. 페르소나에 가치를 더할 수 있는 선택적 콘텐츠에는 교육 수준이 포함됩니다. 교육 수준을 아는 것이 도움이 될 수 있습니다.

일부 관습에 대한 자세한 정보. 학사 학위를 가진 사람은 석사 학위를 가진 사람보다 구매 습관과 브랜드 인식이 크게 다를 수 있으며, 이 지식은 그 사람이 인식되는 방식에 영향을 미칠 수 있습니다. 급여 또는 등급. 돈은 말하며 많은 경우에 그 액수는

개인의 소득은 생활 수준과 가처분 소득에 상당한 영향을 미칩니다. 이 정보는 특정 부 수준을 대상으로 할 때 중요한 정보를 제공할 수 있습니다. 개인적인 인용. 당신의 사람이 주장할 모토는 무엇입니까?

소유하다? 때때로 이것은 당신의 성격의 핵심 사고방식에 대한 빠른 개요를 제공할 수 있습니다. 온라인 운영. 까다로울 수 있습니다. 돈을 쓰는 방법은 많다

그들의 시간 온라인. 어떤 사람들은 청구서를 지불하고, 어떤 사람들은 블로그와 소셜 네트워킹에 매우 열중하고, 어떤 사람들은 자신의 컴퓨터를 작업을 수행해야 할 때 켜지는 장치로 사용합니다. 많은 프로젝트에 일부 온라인 구성 요소가 있기 때문에 이 요소는 약간의 판단입니다. 그림을 그리려면 연구에 의존해야 합니다. 오프라인 작업. 당신의 성격은 취미가 있습니까? 여분이 있습니까

귀하의 개인이 온라인 상태가 아닐 때의 삶에 대한 정보? 이 요소는 네트워킹만큼 까다로울 수 있으며 성격에 영향을 미치는 데 그만큼 중요할 수 있습니다. 클라이언트, 브랜드 또는 프로젝트의 핵심 진입점 또는 시작점입니다. 종종 중요하다

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

120

7장: 사람

기술적 편안함 수준. 그 사람은 PC나 Mac을 사용합니까? 그는

당신은 전혀 컴퓨터를 소유하고 있습니까? 그는 인스턴트 메시징, Flickr를 사용하거나 블로그를 작성합니까? 그는 이 활동에 매우 만족합니까 아니면 혼란스럽습니까? 초보자를 겨냥한 아주 간단한 솔루션이 그에게 도움이 될까요? MP3 플레이어나 다른 휴대용 장치가 있습니까? 그는 DVR, AppleTV 또는 주문형 프로그램을 사용하여 TV를 시청합니까? 목록은 무기한 계속될 수 있습니다. 그리고 앞으로. 클라이언트, 브랜드 또는 프로젝트에 따라 이러한 개념과 다른 많은 개념을 인식하는 것이 중요할 수 있습니다. 사회적 편안함 수준. 소셜 미디어 및 소셜 네트워킹의 성장을 고려

작업할 때 해당 공간에서 작업하는 방식을 매우 정확하게 식별하는 것이 중요할 수 있습니다. 트위터 계정이 있나요? 그렇다면 그의 추종자는 몇 명입니까? 그는 얼마나 활동적입니까? 그는 지도자입니까? 그는 MySpace, Facebook, LinkedIn 또는 기타 애그리게이터나 온라인 커뮤니티를 사용합니까? 모바일 편안함 수준. 모바일 기기의 사용이 늘어나면서

전반적으로 사람들이 모바일 공간에서 자신을 찾는 방법을 고려하는 것이 중요합니다. 동기는 고객, 브랜드 또는 프로젝트에서 사용됩니다. 경우에 따라

개인이 클라이언트, 브랜드 또는 프로젝트를 사용하려는 이유를 포함합니다. 재킷에 헤드폰 코드가 계속 엉키고 머리에서 찢어진다면 새 헤드폰을 고려해야 할 좋은 이유가 될 수 있습니다. 연구 데이터를 기반으로 한 실제 시나리오는 성격을 통합하기 위한 주요 동기를 식별하는 데 도움이 될 수 있습니다. 사용자 목표. 그 사람이 무엇을 바라는지 파악하고 싶을 수도 있습니다.

클라이언트, 브랜드 또는 프로젝트를 사용하여 달성합니다. 이를 통해 개인의 컨트롤 사용에 대한 통찰력을 얻을 수 있습니다. 시작하기 위한 데이터 포인트일 뿐입니다. 당신은 당신의 성격을 구조화하고 그것을 무한한 수의 방식으로 제시할 수 있습니다. 페르소나의 세계에 대해 자세히 알아보고 싶다면 Steve Mulder와 Ziv Yaar가 저술한 The User Is Always Right: A Practical Guide to Creation and Using Personas Online(New Riders, 2006)에서 시작하는 것이 좋습니다.

사람의 창조

121

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

상품명

브랜드 소비자에 대해 알아보기

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

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

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

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

시작

연구 시작

경험 쌓기

"영구 초심자"

"$)*&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는 첫 번째 Brandi e-뉴스레터를 발견합니다. "Pizza, as easy as 1, 2, 3." 완벽합니다 - 그녀의 아이들은 피자를 좋아하고 그녀는 보통 아이들에게 냉동 피자를 사줍니다. 그가 직접 피자를 만들 수 있는지 알아보도록 영감을 준 "Pizza for Beginners"에 대한 링크가 있습니다. 링크는 그를 "Pizza Wizard"라는 페퍼로니 피자 레시피로 안내합니다. 그는 조리법을 스캔하고 그것이 아주 간단하다는 것을 알게 됩니다. 단 25분, 4가지 재료. 그는 자신이 가지고 있는 것을 보기 위해 부엌을 확인합니다. 그는 페퍼로니나 피자 소스가 없지만 "피자 마법사"는 잘 갖춰져 있는 부엌에 있는 소시지와 토마토 소스로 대체할 것을 제안합니다. 그리고 완벽합니다! 쿠폰 링크가 있습니다. Neena는 레시피 메뉴를 인쇄하고 필요한 몇 가지 항목을 추가한 다음 매장으로 향합니다. 상점에서 돌아온 후 Alice가 시작됩니다. 그는 반죽을 열고 재료를 추가하는 방법에 대한 단계별 지침을 봅니다. 각 단계 옆에는 그림이 있습니다. 이해하고 따라하기 쉽습니다. 그는 먼저 토핑을 요리해야 할지 고민하지만 피자 FAQ가 그에 대한 답을 제공합니다.

상황에 맞게 타겟팅된 추가 정보 대부분의 타겟팅된 뉴스레터 레시피 마법사 더 나은 쿠폰 통합 식사 계획 "끝내세요" 태도는 주로 준비된 음식을 기반으로 하며 상대적으로 적은 수의 추가된 신선한 과일과 야채가 요리보다 레시피를 탐색하는 데 더 많은 시간을 소비합니다.

그림 7.4 대상 청중의 페르소나(가로 방향). 페르소나에 대한 이 상세 보기에는 더 넓은 범위의 데이터가 포함되며 사용자의 목표, 요구 및 행동에 대한 보다 포괄적인 보기를 제공합니다. 모두 더 큰 에코시스템을 기준으로 설정됩니다. 윌 에반스의 의례.

그림 7.5 대상 개요 및 대상 청중의 성격(초상화). 왼쪽의 대상 개요는 높은 수준의 요약 정보를 제공하고 세 사람이 상호 작용하고 연결하는 브랜드를 보여줍니다. 오른쪽의 자세한 설명은 개인의 개요와 전기, 행동 및 동기에 대한 정보를 제공합니다.

고급인

123

폴과 헬렌 "무엇이든 넣을 수 있습니다. 얼마나 들어갈지 잘 모르겠습니다."

5 4

Helen의 어머니는 몇 주 전에 돌아가셨고 그들은 지금 막 집을 비우고 있습니다. 그들은 집을 팔 계획이지만 먼저 청소를 꽤 해야 합니다. 집은 또한 메인 욕실에서 개조가 필요합니다.

삼

- of de 지하실은 헬렌의 어머니가 지난 수십 년 동안 수집한 물건들로 가득 차 있습니다. 그는 아무것도 버리지 않았습니다. 그는 지난 20년 동안의 신문과 타임지를 가지고 있습니다. Helen이 지키고 싶은 몇 가지가 있습니다. 대부분의 옷-"콜과 가구는 굿윌에 기부됩니다. 안타깝게도 그의 어머니의 글은 대부분 물과 곰팡이에 의해 망가졌습니다. 그녀는 페인트 통도 가지고 있지만 폴과 헬렌은 페인트에 납이 포함되어 있는지 또는 아니다.

2 1

디

~에 대한

아인

Ex led pe grie nc e C on Pric ve e Senior tunc pe sp Ree Mpued ult type Timtion C on eline t Main ss ajoer r L Size ifes D E ecven lutte t Year Re rding Waste Rate in Buars ds ine 가격 ja O Rec am nlin ycli ne ac g 카운트

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

나이: 24-65세

라이프 사이클 1월

칠월

12월

월

1.0 라이프 이벤트

주요 기능 Ŕ Ŕ

가족 공간 구매 또는 소규모 개조 작업(예: 욕실)과 같은 단일 이벤트. 쓰레기통 구매 경험이 거의 없습니다.

목표 Ŕ Ŕ Ŕ Ŕ Ŕ

빨리 쓰레기통을 구하세요. 그들이 좋아하지 않거나 기부하지 않는 물건을 제거하십시오. 그 과정에서 재산을 파괴하지 마십시오. 못생긴 쓰레기통을 피하십시오. 폐기물 용기가 가득 차면 신속하게 제거하십시오.

좌절과 고충 Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

질문 Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Ŕ ŕ

필요 시 가능 가격 매도인이 찾은 그대로 임차함 필요한 용기 크기의 가용성 연락 후 설치 및 수거 속도 일정 및 결제를 위한 온라인 계정 사용 시간 장비 품질 및 청결도 친숙한 브랜드

Ŕ ŕ ŕ ŕ

초기 스티커 충격 프로세스를 모름 그들이 무엇을 모르는지 모름 공급업체 간의 사과 대 사과 비교

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

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

모든 거래의 질

아만다 스톤

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

삼

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

라이프 사이클

주요 기능 Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

여러 프로그램 관리 중대형 기업 평균 볼륨(한 번에 50-2000+ 주문) 하나의 역할을 공유하는 여러 사람 70/30 빠른 지불 및 관리자 확인 매주 또는 격월 연중 보고에 매우 관심이 있음 프로그램을 보고할 의향이 있음 Excel을 많이 사용함 사용자 인터페이스를 위한 맞춤형 내부 시스템

목표 Ŕ Ŕ Ŕ Ŕ

현재 시스템에 통합. 직원에게 빠르고 쉽게 급여를 지급할 수 있습니다. 비용(주로 시간). 가이드 도움말.

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

Ac FT N c ou P n C a r t Zod Rene quest E Ad asy s min y Check R c e p x or r re n rting tB al Peance Cu op stoms soft System Excel

엔씨

1월

인플루언서

빠르고 쉽게 직원에게 급여를 지급합니다. Ŕ 중복 작업을 방지합니다. Ŕ 현재 잔액을 확인하여 송금이 필요한지 알 수 있습니다. Ŕ 이벤트를 주별, 격월별, 월별, 분기별, 연간으로 추적합니다.

리에

예에

아야

그만큼

dg ja ow Kn

크니

등

~에 대한

h n

디

그는 Account Zone을 매우 정기적으로 사용합니다(일주일에 며칠). 그리고 여러 프로그램을 운영하다 보니 1년 내내 꽤 활발하게 활동한다.

활동 및 관심

텍

나이: 28-55세

이자형

지식

아인

Account Zone은 그가 새 카드를 발급하고 프로그램 참가자에게 신속하게 지급되도록 하는 데 정말 도움이 됩니다. 그가 부족한 한 가지는 상황이 어떻게 진행되고 있는지 보기 위해 그가 실행하는 모든 프로그램뿐만 아니라 개별 프로그램을 살펴보는 능력입니다. 그의 클라이언트는 프로그램의 작동을 모니터링하기를 원합니다. 그는 현재 Excel에서 추적하고 있습니다. 결국 그는 고객에게 Excel 파일을 보내거나 때로는 파일을 내보내 멋진 차트가 포함된 PowerPoint를 보냅니다. Account Zone에서 개별 프로그램과 여러 프로그램에 대해 보고할 수 있다면 정말 멋질 것입니다.

칠월

Ŕ ŕ ŕ ŕ ŕ

아르 자형

월

실망과 고충

질문 -

12월

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

그림 7.7 대상 청중의 개별 성격. 이 페르소나는 강력한 데이터 기반 모델입니다. 일상 생활의 이야기는 내러티브이지만 나머지는 디자인 체크리스트로 표시됩니다. 다이어그램은 작은 공간에 많은 양의 정보를 전달하는 데 사용됩니다. 토드 자키 워펠의 의례.

124

7장: 사람

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

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

Jared의 요점은 간단합니다. 대상 고객을 관찰하고, 학습한 연구를 추가하고, 모든 것을 세그먼트로 통합함으로써 팀을 유지하고 최고의 팀을 구축하는 일종의 공감을 유발하는 페르소나를 생성할 수 있어야 합니다. 잠재적인 애플리케이션, 웹사이트 또는 제품. 하지만 하루가 끝나면 당신의 페르소나는 산타클로스와 매우 흡사합니다. 사람들이 그들을 믿는 한 그들은 가치가 있습니다.

개인적인 최종 생각

125

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

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

사이트 콘텐츠 및 최적화된 단어와 관련된 모든 키워드 질문의 인프라, 기술 및 조직 원칙에 영향을 미칠 수 있습니다.

검색 엔진은 링크 또는 링크 인기도를 확인합니다 – 귀하를 가리키는 링크의 수와 품질

다른 사이트의 사이트와 사이트 내 링크의 조직 구조 이 세 영역을 분리하고 UX 디자이너의 관점에서 살펴봄으로써 향후 최적화 문제에 더 잘 대비할 수 있습니다.

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

SEO 소개

127

Hitwise(www.hitwise.com)는 Google과 그 계열사(AOL 및 YouTube 포함)가 2008년 11월 미국에서 검색의 거의 72%를 차지하면서 전 세계 검색의 가장 큰 점유율을 차지한다고 보고합니다. Yahoo는 거의 2위입니다. 18퍼센트. , 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 지출에 대해 35-1 ROI를 달성하는 것을 보았습니다. 스폰서 목록의 트래픽에 대해 검색 엔진 회사에 비용을 지불하지만 유기적 트래픽에 투자하지 않는다면 기회의 약 10%로 자신을 제한하는 것입니다. 자신의 검색 행동에 대해 생각해 보십시오. 검색 결과에서 하나 또는 두 개 이상의 유료 스폰서 목록을 마지막으로 클릭한 때는 언제입니까? SEO가 중요한 이유와 SEO가 유지되는 이유에 대한 논의는 여러 장에서 계속될 수 있습니다. Google은 아무데도 가지 않고 올라가고 있으며 효과적인 양방향 마케팅에는 유능한 구현의 일부로 검색 엔진 최적화가 포함되어야 한다고 말하는 것으로 충분합니다.

128

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

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

www.google.com/support/webmasters/bin/ answer.py?hl=fi&answer=35291 웹마스터/사이트 소유자를 위한 지침: 웹마스터 지침: 품질 지침:

www.google.com/support/webmasters/bin/ answer.py?hl=fi&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 파일을 보고 이러한 리소스에 포함된 텍스트와 링크를 찾는 검색 엔진의 기능이 향상되었습니다. 이 콘텐츠는 인덱싱되지만 All-Flash 자산이 검색 결과에서 상위권을 차지하는 것을 본 적이 있습니까? 검색 엔진이 Flash와 완전히 호환되도록 개방하는 것은 위험하기 때문에 아마 그렇게 하지 않을 것입니다. SWF 객체에 포함된 모든 링크와 텍스트 내용이 검색 엔진에 완전히 표시된다고 가정합니다. 비윤리적인(또는 "검은 모자") 옵티마이저가 렌더링 시 개체의 텍스트 레이어에 사과를 배치하는 것을 방지하는 요소

130

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

브라우저를 통해 완전히 조립된 콘텐츠를 보는 인간 사용자를 위한 오렌지? Flash 콘텐츠를 완전히 번역하지 않고 어떻게 직접 링크를 만들 수 있습니까? 이러한 근본적인 취약점은 검색 엔진이 "이것은 말의 사진입니다."라는 텍스트 없이 이미지가 말의 사진임을 알 수 있는 일정 수준의 인공 지능에 도달할 때까지 남아 있습니다. 검색 엔진과 호환되는 Flash 웹 사이트를 디자인하려면 Flash 콘텐츠를 복사하는 정적 콘텐츠 레이어를 추가해야 합니다. 현재로서는 검색 엔진의 요구 사항을 무시하고 정적 콘텐츠 계층이 사용성 요구 사항을 준수하는 핵심입니다. 검색 엔진을 전화 접속 연결을 통해 또는 스크린 리더를 사용하여 온라인 콘텐츠를 보는 사람으로 생각하십시오. 이 사람들은 가장 낮은 공통 분모일 수 있으며 웹 개발 전략이 이 극소수의 인간 사용자를 할인하고 있을 가능성이 있습니다. 그러나 이 소수의 사람들을 강등시키면 사이트의 가장 중요한 두 방문자인 GoogleBot과 Yahoo Slurp도 강등됩니다. 이들은 주요 검색 엔진이 귀하의 사이트를 색인화할 수 있도록 하는 크롤러이기 때문입니다. 텍스트 단어나 스파이더 링크가 검색 엔진에 표시되지 않으면 의미 있는 검색 결과를 통해 콘텐츠를 찾을 수 없습니다. 정적 계층은 여러 가지 방법으로 만들 수 있습니다. 검색 엔진 요구 사항을 준수하려면 정적 콘텐츠 레이어가 Flash 콘텐츠를 미러링해야 합니다. 이것은 Flash에서 사용되는 것과 다른 것을 검색 엔진에 보여줄 기회가 아닙니다. 만약 그렇게 한다면, 당신은 게임의 정신을 깨뜨리고 분명히 어두운 면에 서게 됩니다. Flash 콘텐츠를 정적 레이어에 포함하는 이상적인 방법은 Flash와 정적 콘텐츠가 모두 동일한 URL에 있을 수 있도록 SWF객체를 사용하는 것입니다. 이를 통해 검색 엔진은 정적 콘텐츠를 찾고 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은 초기 페이지 로드 후 세션을 확장할 수 없고 스크립트를 활성화할 마우스나 외부 에이전트가 없기 때문에 사용자가 활성화한 오프 페이지 콘텐츠는 텍스트 콘텐츠가 미리 로드된 셸에 포함되지 않는 한 표시되지 않습니다. . UX 디자이너의 임무는 페이지 없는 디자인을 구축하는 데 필요한 3D 모델링에 모든 텍스트와 링크가 페이지 셸에 미리 로드되어야 한다는 요구 사항도 포함하는지 확인하는 것입니다. 다른 모든 것과 훌륭한 디자인은 보이지 않습니다. 스크립트 탐색 가장 일반적인 최적화 문제 중 하나는 사이트 탐색의 핵심에 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에 "301 영구적으로 이동됨" 상태 코드를 지정하고 하나의 URL로 리디렉션하는 것이 좋습니다. 이전 URL에서 새 URL로의 일대일 기준입니다. 301 리디렉션은 검색 엔진용으로 허용되는 유일한 리디렉션입니다.

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

134

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

하나의 파일 이름에 너무 많은 키워드를 사용하지 마십시오. 다음과 같이 선택하십시오: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. 또한 http://question에 대한 리디렉션을 구성했는지 확인하십시오. fi 주소 301로 이동했습니다. http://www.site-in-question.com으로 영구적으로 리디렉션됩니다. 사이트가 www 주소가 있든 없든 살아남을 수 있다면 검색 엔진(특히 Yahoo)은 두 URL의 콘텐츠를 인덱싱하여 실수로 복사할 수 있도록 전체 사이트를 엽니다. 이러한 현상은 일반적으로 www 주소가 없는 사이트에 제3자가 링크를 걸어 해당 사이트에 동적 링크 구조가 포함되어 있을 때 확산됩니다.

콘텐츠: 과거(현재)와 미래의 왕 콘텐츠 제작은 남의 일이지만, 사이트 아키텍처에서 만드는 토대는 검색 엔진에 적합한 콘텐츠를 제공하는 것과 관련이 많습니다. 키워드 기반 검색과 마찬가지로 콘텐츠를 보려는 사람들의 실제 검색 행동을 이해해야 합니다. 검색 엔진은 사용자가 키워드를 입력하여 해당 단어와 다소 관련이 있는 콘텐츠에 연결하는 데 의존하기 때문에 여전히 매우 "원시적"입니다. 올바른 구문을 선택하는 것은 사이트가 올바른 컨텍스트와 관련이 있는지 여부에 전적으로 달려 있습니다. 완벽한 세상에서 SEO 파트너는 프레이밍 프로세스를 시작하고 함께 작업하기 전에 일련의 키워드 문구 대상을 제공합니다. 귀하의 프로세스에 자격을 갖춘 파트너가 포함되지 않은 경우 Google AdWords의 키워드 조사 도구(https://adwords.google.fi/select/KeywordToolExternal)에 대해 읽고 사람들을 조사하는 실제 검색 행동에 대해 조금 연구하십시오. 당신의 수업. 그런 다음 이 피드를 사용하여 잠재 고객이 검색하는 구문을 파악하고 사이트 전체에서 필요에 따라 해당 구문을 사용하십시오. 검색 엔진은 사이트를 분석할 때 여러 곳에서 키워드를 찾습니다. 최적화는 올바른 단어가 올바른 위치에 있는지 확인하는 것을 기반으로 합니다. UX 디자인 프로세스에서 키워드의 역할을 이해함으로써 미래의 성공을 가능하게 하는 데 필요한 프레임워크를 만듭니다.

내용: 한때(그리고 현재)와 미래의 왕

135

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

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

메타데이터, 제목 및 키워드 메타데이터의 기본 문제로 돌아가기 전에 이 장에서 여기까지 왔다는 것은 매우 중요합니다. 수많은 메타 태그를 사용할 수 있지만 나머지는 모두 스팸에 취약하기 때문에 실제로 큰 영향을 미치는 것은 몇 개에 불과합니다. 관련 태그는 다음과 같습니다. 페이지 제목. 아니니 참고하세요태그하지만

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

스팸에 매우 취약하기 때문입니다. 예외는 Google 애드센스 신디케이션이 메타 키워드 태그를 살펴보고 이것이 야후에 세 번째 방식으로 영향을 미친다는 점입니다. 메타 키워드

136

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

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

메타 설명은 각 페이지마다 고유합니다. 이 설명은 바로 해당 페이지의 내용에 대한 요약입니다. 150-160 마르크 정도 팔지 말고 말하십시오. 이 콘텐츠는 검색 엔진이 페이지 링크 아래에 표시할 가능성이 높기 때문에 중요합니다. 페이지에 메타 설명이 없는 경우 검색 엔진은 검색된 키워드가 포함된 텍스트 또는 기타 콘텐츠의 일부를 찾아 결과에 표시합니다. 메타 설명은 SEO보다 유용성에 관한 것이므로 모든 페이지에 태그가 올바르게 지정되었는지 확인하세요. "NOINDEX" 설명 필드. 포함하고 싶지 않은 페이지가 있는 경우

검색 엔진 결과에서 NOINDEX 콘텐츠 설명 필드를 사용하십시오. 크롤링하려는 페이지에 실수로 이 태그가 포함되지 않도록 하십시오. 헤드라인. 검색 엔진은 제목 등을 인식합니다.

스팸을 보내지 않는 한 인플루언서로서. 설명적이고 해당 페이지에 대한 관련 키워드를 포함하는 섹션 제목을 허용해야 합니다. 앵커 텍스트를 연결합니다. 링크의 앵커 텍스트는 무엇에 중요한 영향을 미칩니 까?

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

머리 분할 왼손잡이용과 오른손잡이 골판지에 대해 별도로 색인된 페이지를 갖는 것이 유리합니다. 이 수준의 정밀도는 귀하의 페이지가 전설적인 롱테일 검색과 밀접하게 일치할 수 있는 더 나은 기회를 제공합니다. 한 가지만 다루는 페이지에는

내용: 한때(그리고 현재)와 미래의 왕

137

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

사이트맵 사용 최근 몇 년 동안 기존 사이트맵 페이지를 버리는 것이 인기를 끌었습니다. 이것은 유용성과 SEO 측면에서 실수입니다. 모든 웹사이트에 사이트맵이 필요하다는 사실을 확인하세요. 멋지지 않을 수도 있지만 필요합니다. /sitemap.xml 및 /sitemap.txt에 사이트맵 파일도 포함합니다. 이 구조가 사이트 순위를 향상시키지는 않지만 검색 엔진이 디렉토리 구조를 이해하고 새롭고 업데이트된 콘텐츠를 찾는 데 도움이 됩니다.

콘텐츠를 최신 상태로 유지 웹 사이트의 콘텐츠를 지속적으로 업데이트하는 것은 검색 결과에서 최고의 순위를 달성하고 유지하는 핵심 요소입니다. 이는 전체 사이트의 콘텐츠를 항상 편집한다는 의미는 아닙니다. 이는 사이트가 지속적으로 성장해야 함을 의미합니다. 컨텐츠를 쉽고 직관적으로 추가할 수 있는 디렉토리 구조를 구축하고 시간이 지남에 따라 사이트가 성장할 것으로 예상합니다.

기타 콘텐츠 문제 콘텐츠가 풍부한 사이트의 사용자 경험을 처리하는 데 있어 기본적인 과제는 콘텐츠 복제 또는 복제를 방지하는 것입니다. 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가 사이트를 기반으로 배포하기 때문에 이해하는 것이 중요합니다. 링크 계층 구조에서. 및 디렉토리 구조. 일반적으로 홈페이지의 PageRank가 5인 경우 기본 섹션 페이지의 PR은 4, 보조 페이지의 PR은 3, 세 번째 페이지의 PR은 2여야 합니다.

링크 추천 설명

139

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

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

140

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

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

시스템 게임 SEO가 재미가 아니라 일이라고 누가 말합니까? 검색 엔진은 웹사이트 소유자에게 실제 달러를 기부할 수 있으며 특정 환경에서는 어떤 대가를 치르더라도 최상위 순위를 달성할 수 있는 실질적인 방법이 있습니다. 적지 않은 SEO가 고객을 이용하여 단기적으로는 긍정적인 결과를 가져올 수 있지만 시간이 지남에 따라 재앙적인 영향을 미칠 수 있는 잘못된 기술에 대해 많은 돈을 청구했습니다. 수년 동안 최상의 결과를 찾는 웹마스터는 다양한 최적화 기술을 사용해 왔습니다. 검색 엔진 기술의 핵심 진화 중 하나는 시스템을 조작하기 위해 발견된 영리한 방법을 개발하는 것입니다. 검색 엔진의 관점에서 깨끗하고 관련성이 높은 결과는 모든 쿼리의 상단에서 사용자의 관심사를 제공합니다. 많은 SEO의 관점에서 볼 때 모든 것이 사랑과 SEO에 공평합니다.

화이트 햇 대 블랙 햇 SEO 방법을 "화이트 햇" 또는 "블랙 햇"으로 특징짓는 것은 쉽고 재미있지만 어느 것이 무엇인지 구분하는 것은 훨씬 더 어렵습니다. 많은 화이트 햇 옵티마이저는 특정 기술 관리, 콘텐츠 및 링크 조작 및 기타 접근 방식을 단순히 금지한다고 공개적으로 강력하게 말하는 순수주의자입니다. Black Hats는 이를 부정행위와 무관한 경연대회로 보고 있습니다. 그들의 접근 방식은 고양이와 쥐의 게임과 비슷합니다. 고양이는 모든 카드를 쥐고 쥐는 심각한 돈을 벌 수 있습니다. 위험을 감수하고 승리하면 보상이 커집니다. 그러나 검색 엔진이 사용자에게 도달하면(거의

시스템 게임

141

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

메타 키워드를 사용한 스팸 많은 "스푸핑" 기술은 UX 원칙을 기반으로 합니다. 시스템을 조작하는 초기 방법은 메타 키워드 스터핑이었습니다. 기본적으로 사이트 콘텐츠가 오렌지에 관한 것일 때 수백 번의 사과 발생으로 메타 키워드를 채우는 것입니다. 메타 키워드 접근 방식은 초기 웹의 분류 체계를 지원하기 위해 만들어졌습니다. 모든 키워드 스팸으로 인해 웹 페이지의 이 부분은 검색 순위에 거의 영향을 미치지 않습니다. 검색 엔진은 이 기술을 쉽게 감지하고 이를 중심으로 신속하게 설계할 수 있었습니다. 차세대 스팸은 해독하기가 조금 더 어려웠고 UX 문제에도 뿌리를 두고 있었습니다.

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

142

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

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

링크 스패밍 최근 게임 시스템은 최신 웹 검색 엔진 작동 방식의 핵심인 링크 인기도 조작에 중점을 두었습니다. 위에서 언급했듯이 검색 엔진은 다른 곳에서 해당 페이지로 연결되는 링크의 수와 품질을 분석하여 특정 웹 콘텐츠의 중요성을 결정합니다. SEO는 오해의 소지가 있는 리디렉션, 하위 도메인의 남용, 사이트의 모든 페이지를 "/index.html" 및 다양한 기타 미묘한 메커니즘으로 만들어 퍼즐의 이 부분을 조작하기 위해 노력했습니다.

몇 가지 최종 생각 이것이 SEO 문제에 대한 첫 번째 연구인지 의심스럽습니다. 지금쯤이면 사이트의 아키텍처 및 관련 문제가 검색 엔진 성능에 얼마나 영향을 미치는지 분명해졌습니다. 현재 검색 환경은 단순한 분류 또는 구조에서 크게 도약한 것입니다. 사려 깊은 SEO는 양질의 사용자 경험에서 시작됩니다. 웹사이트의 아키텍처는 검색 엔진의 성공으로 이어지거나 즉각적인 실패에 대비할 수 있는 수명 주기의 중요한 지점입니다. 검색 엔진 최적화는 끝나지 않는 전략이지만 양질의 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 사이트에 새 작업을 게시해야 하는 경우입니다. 이 시나리오의 경우 이해 관계자 인터뷰를 수행했으며 고용 프로세스가 주로 한 사람에 의해 실행된다는 사실을 알게 되었다고 가정해 보겠습니다. 채용 담당자와 함께 일하는 HR 부서의 Jeff라고 하겠습니다. 148

9장: 전환: 정의에서 계획으로

Jeff는 현재 작업 설명에 매우 익숙합니다. 새로운 것이 필요할 때 그는 일반적으로 새 직위의 잠재적인 관리자가 그에게 일자리를 보내달라고 요청하는 것을 알아차립니다. 그 후 Jeff와 관리자(Emily라고 부름) 간의 공동 작업 프로세스는 작업 설명을 작성하고 게시하는 것입니다. 그림 9.1은 이 시나리오의 스토리보드가 어떻게 생겼는지 보여줍니다. 이미지는 여기에서 만들 수 있는 스토리보드의 한 부분만 보여줍니다. 시나리오를 일찍 시작하여 Emily가 거쳐야 했던 합격 과정을 보여주거나 구직자가 일자리를 찾고 지원하는 모습을 보여주기 위해 스토리보드를 계속 진행할 수 있습니다. 여기서 주목해야 할 중요한 점은 이러한 종류의 스토리보드를 사용하면 귀하와 귀하의 프로젝트 팀이 워크플로우를 일련의 페이지 이상으로 볼 수 있다는 것입니다. 그것은 인간적인 요소와 맥락을 가져옵니다. 그리고 페르소나(Jeff)의 인간적 요소가 없다면 팀은 시작하기 위해 기존 작업 설명에 기능을 포함할 생각을 하지 않았을 수 있습니다. 비록 우리 모두가 시간을 절약하고 필요한 모든 것을 포함하도록 하기 위해 그렇게 했지만 말입니다.

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

아이디어 및 시각화 기능

149

스토리보드와 다른 유형의 스케치(예: 사용자 흐름 및 개념적 프레임워크)를 사용할 때 기억해야 할 한 가지는 기본적으로 브레인스토밍 도구로 사용된다는 것입니다. 몇 가지 훌륭한 아이디어가 연습에서 나오겠지만 이 스케치는 세부 계획을 위한 것이 아닙니다. 이 사실은 초안 형식(프로토타입 형식과 반대)에서 분명할 수 있지만, 초안에서도 시각화된 기능을 보면 때때로 최종 제품에 존재할 것이라는 기대로 이어질 수 있으므로 비즈니스 이해 관계자에게 여전히 유의해야 합니다. 여기에서 또 다른 위험은 참가자가 무언가가 페이지에 있어야 하는지 아니면 팝업에 있어야 하는지와 같은 UI 요소에 대한 토론에서 곁길로 갈 수 있다는 것입니다. 이러한 종류의 문제는 종종 시나리오가 해결해야 하는 더 큰 문제보다 해결하기가 더 쉽거나 더 친숙하기 때문에 이러한 세부적인 논의에 들어가기가 매우 쉽습니다. 참가자들에게 작업을 간소화하고 시간을 효율적으로 사용하기 위해 우선 순위가 지정된 요구 사항 목록을 계획하는 시점에서 이러한 토론을 녹음하도록 요청하십시오. 수집하는 데 너무 많은 시간을 할애한 아름다운 요구 사항의 우선 순위를 정하는 종종 바쁘고 때로는 고통스러운 과정입니다!

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

대표하다). 개발팀의 비전을 대표하는 사람(

개발 옹호자).

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

Business Advocate: 비즈니스의 필요와 요구 사항을 대표하고 가능한 한 충실하게 고려되고 충족되도록 하는 팀원입니다. 비즈니스 지지자의 주요 관심사는 회사 및 부서의 전략적 목표를 달성하고, 프로젝트 중에 비즈니스 비전이 손실되지 않도록 하고, 프로젝트 목표에 초점을 맞추고 유지하는 것입니다. 사용자 대표: 사이트를 경험하는 기본 사용자의 요구와 관점을 대표하는 팀 구성원입니다. 사용자 옹호자의 주요 관심사는 사이트가 사용성 기대치를 충족하고 만족스럽고 매력적인 사용자 경험을 제공하며 프로젝트 목표를 지원하는 활동을 장려하는 것입니다. Development Advocate: 기술 및 QA 팀의 요구 사항과 제약 사항을 대표하는 팀원입니다. 주요 관심사는 개발 팀이 경계 내에서 효율적으로 운영되고 사용자 및 비즈니스 이해 관계자가 기대하는 품질 표준을 충족하는 제품을 제공하는지 확인하는 것입니다.

9장: 전환: 정의에서 계획으로

이것을 변호사들 사이의 3자 줄다리기라고 생각하세요. 세 당사자 사이에 긴장이 상당히 잘 유지된다면(즉, 방어자가 우세하지 않은 경우) 세 당사자는 프로젝트 목표를 충족하는 균형 잡힌 솔루션을 향해 노력할 수 있습니다. 각 팀원은 프로젝트 전반에 걸쳐 균형을 유지하는 것이 자신에게 이익이 된다는 점을 인식해야 합니다. 한 당사자가 우세하면 다른 역할이 자리를 잃고 프로젝트가 목표에 미치지 못하거나 예상보다 훨씬 높은 비용으로 목표를 달성할 수 있습니다. 장력이 균형을 이루지 못할 때 발생할 수 있는 일의 예는 그림 9.4를 참조하십시오.

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

위의 좋은 전압

155

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

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

156

9장: 전환: 정의에서 계획으로

다음은 개발 에이전트의 목표 및 관련 책임입니다. 시간과 예산 내에서 요구 사항을 이행합니다. 팀의 효율성을 보장합니다(불필요한 작업을 피하고 좋은

커뮤니케이션) 사용 가능한 도구와 플랫폼을 최대한 활용합니다. 비용 효율적인 추가 도구 선택 향후 변경에 많은 추가 작업이 필요하지 않도록 함 성장에 따라 솔루션을 확장 가능하게 함 개별 부품을 쉽게 수정할 수 있도록 솔루션을 모듈식으로 함 가능한 한 표준화된 솔루션으로 함: 더 적은 변경

구입한 시스템에 맞춰 제작할수록 개발 작업이 덜 필요합니다. 개발팀이 잘 작동하는지 확인하십시오. 상대적으로 흥미롭고 보람 있는 작업을 제공하여 이직률을 제한합니다.

q 레거시 요구 사항 작업 4단계

1단계

요구 사항을 검토하고 요구 사항이 명확하지 않거나 사용자 가치가 의심스러운 요구 사항에 플래그를 지정합니다.

요구 사항을 확인하고 사전 점검을 수행하십시오.

유

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 Prioritization" 기사(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 외에도 Learning IA 페이지에 http://iainstitute.org/en/learn/tools.php와 같은 많은 도구가 있는 Information Architecture Institute의 제안을 확인하십시오. 참고 Microsoft는 현재 2007 버전의 Vision을 제공합니다. 그러나 많은 회사에서 아직 제품으로 업그레이드하지 않았으며 버전 차이를 피하기 위해 현재 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의 사이드 스택 요소

페이지 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의 시각 어휘에서 연결선과 화살표 요소

커넥터와 화살표는 페이지, 페이지 스택, 결정 지점 등 간의 이동 또는 진행률을 표시하는 데 사용됩니다. 커넥터는 일반적으로 작업이 좌우로 프롬프트되는 위치에 나타납니다. 예를 들어 첫 페이지에서 About Us 페이지로 연결되는 링크는 두 페이지 사이의 커넥터가 될 수 있습니다. 화살표(그림 10.6 상단)는 작업 완료를 향한 하류의 움직임을 나타냅니다. 크로스바가 있는 커넥터(그림 10.6 하단)는 시작한 페이지("업스트림")로 돌아갈 때 더 이상 사용할 수 없음을 인식하는 데 사용할 수 있습니다. 예를 들어, 사용자가 웹 사이트에 로그인하면 이제 홈 페이지 콘텐츠를 사용자에 맞게 조정할 수 있으므로 사용자가 방금 따라간 경로에서 일반 페이지나 로그인 페이지를 더 이상 사용할 수 없습니다.

조건 A

비

그림 10.7 Jesse James Garrett의 시각적 어휘의 피트니스 요소

파선은 조건을 표시하는 매우 일반적인 방법입니다. 사이트맵, 작업 흐름 및 귀하가 생성하거나 발명한 기타 작업 제품에 나타날 수 있습니다. 점선을 연결선(그림 10.7 참조)으로 사용하거나 영역 주변의 상자로 사용하여 페이지 또는 전체 페이지 섹션에 대한 연결이 다른 작업이나 이벤트에 따라 달라짐을 강조할 수 있습니다.

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). 필요한 경우 하위 페이지를 함께 병합하는 것을 두려워하지 마십시오. Sitemap은 단일 표준 크기 용지가 허용하는 것보다 더 커질 수 있습니다. 사이트맵이 잘 구성되어 있고 청중을 위해 연결이 명확하게 문서화되어 있는 한 걱정할 것이 없습니다. 이러한 예는 사이트맵 생성을 시작하기에 충분합니다. 여러 프로젝트를 진행하면서 자신의 기술과 종종 팀이나 클라이언트의 요구 사항이 증가함에 따라 사이트맵을 제공하는 데 사용할 수 있는 다양한 접근 방식과 방법이 매우 많다는 것을 알게 될 것입니다.

176

10장: 사이트 카드 및 할당

사이트맵 틀 깨기 이제 기본 작업을 수행하는 데 필요한 대부분의 요구 사항에 적합한 사이트맵의 확실한 예를 보았습니다. 이러한 패턴으로 인해 더 나은 방법을 탐색하는 데 방해가 되지 않도록 하고 저희와 공유하십시오! 다양한 접근 방식을 통해 기본 사이트 아키텍처 이외의 정보를 강조할 수 있습니다. 예를 들어 Vanguard의 수석 정보 설계자인 Andrew Hinton이 친절하게 제공한 그림 10.16의 사이트맵을 고려하십시오. 새로운 연구를 계속 지켜봐주십시오

방

bc.org 지원

로그인

프로필 업데이트

비슷한 사람 찾기

"학문" 관심(의사, 학생, 일반)

참여하다

토론 인쇄물 가져오기

자세한 내용은 bc.org를 방문하십시오.

새로운 관심사

위험 관리

걱정되는 사랑하는 사람

사회화하다

전문가 회의 참여 학습

New Diag New stage / 앉다.

그림 10.16 사이드 맵. 앤드류 힌튼 제공.

이 사이트맵은 웹사이트의 다른 페이지를 보여줄 뿐만 아니라 사용자 경로 및 우선 순위에 대한 정보도 제공합니다. Andrew(www.inkblurt.com)는 Wolf Noeding의 독창성을 촉발시킨 예를 본 후 사이트맵을 만들었다고 말합니다. Andrew는 이 사이트맵을 사용하여 웹사이트와 관련된 다양한 사용자 시나리오 및 정신 모델을 보여줍니다. 지도의 더 큰 원에는 추가 기능이 있습니다. 가장 많은 트래픽을 받는 사이트의 최상위 영역을 강조 표시합니다. 좋은 사용자 경험을 제공하는 모든 실무자와 마찬가지로 Andrew는 빌렸지만 공로를 인정하기도 했습니다. 도구 사용 방법을 배우고 작업 제품과 클라이언트의 요구 사항을 식별하기 시작하면 사이트맵을 무제한으로 확장할 수 있습니다. 어디서든 영감을 얻을 수 있습니다! 새로운 것을 시도하는 것을 두려워하지 말고 시간을 들여 유용하고 가치 있는 시간을 보내십시오.

사이트맵 틀 깨기

177

작업 흐름 사이트맵과 동일한 기본 요소를 많이 사용하는 작업 흐름은 사용자(때로는 시스템)가 웹 사이트나 응용 프로그램을 이동할 때 거치는 경로 또는 프로세스를 식별하는 다이어그램입니다. 여러 가지 방법으로 Taskflow를 사용할 수 있습니다. 사이트맵과 함께 사용하면 사용자가 특정 데이터 세트가 있는 페이지에 도달하는 방법을 보여줄 수 있습니다. 때로는 특정 유형의 사용자(페르소나)가 웹 사이트를 탐색하는 방법과 개인의 정신 모델을 기반으로 볼 것으로 예상되는 내용을 나타내는 데 사용됩니다. 또한 작업 흐름을 통해 프로젝트를 개발 팀에 보내기 전에 명확하게 이해해야 하는 복잡한 프로세스를 식별할 수 있습니다. 작업하는 모든 프로젝트에 대해 워크플로를 사용하지 않을 수 있으며 고객에게 제시하는 작업 결과물에 워크플로가 항상 포함되지는 않을 수 있지만 항상 펜으로만 사용하는 경우에도 사용하는 것이 좋습니다. -자신의 이익을 위한 종이 형식. 약간의 명확성은 먼 길을 갈 수 있습니다. 작업 흐름을 만들려면 사용자의 목표를 이해해야 합니다. 어떤 경우에는 요구 사항 문서를 받을 수 있고 다른 경우에는 사용 사례를 받을(또는 작성) 수 있습니다. 사용 사례는 작업과 목표를 요약하는 몇 개의 문장으로 구성되지만 사용자의 비전을 경험으로 합성할 수 있습니다. 그림 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(Calls to Actions) ) )

와이어프레임은 일반적으로 흑백 또는 회색조로 생성되며 이미지에 자리 표시자를 사용하고 서체의 특성을 방해하지 않습니다(많은 경우 글꼴 크기를 사용하여 사본 유형 간의 구분을 전달함). 매우 기본적인 것부터 전체 화면 디자인을 거의 모방하는 고급 제품까지 모든 모양과 크기로 제공됩니다. 와이어프레임은 진화하고 있습니다. 더 이상 작업 개요에서 디자이너와 개발자에게 제공되지 않습니다. 이제 와이어프레임은 클라이언트, 디자이너, 개발자 및 핵심 수준에서 이해 관계가 있는 팀의 모든 사람에게 사이트나 응용 프로그램을 나타내는 데 사용됩니다. 시각적 디자인 및 개발 단계를 시작하기 전에 "디자인 사고"를 확인하기 위해 고객에게 제시하는 것이 일반적입니다. 종종 철제 프레임워크를 만드는 사람들은 비즈니스 요구 사항을 만드는 사람들과 손을 맞잡고 일합니다(경우에 따라 그들은 같은 사람들입니다). 최고의 프레임워크 및 주석 중 일부는 비즈니스 분석가에서 개발자 및 기타 디자이너에 이르기까지 다양한 파트너 간의 직접적인 상호 작용 및 공동 작업의 결과라는 점도 주목할 가치가 있습니다. 일부 회사는 비즈니스 요구 사항 문서(BRD) 대신 와이어프레임과 주석을 사용하도록 이동하고 있습니다. 세상이 BRD가 멸종했다고 주장하는 것과는 거리가 멀지만, 이 변화의 시작은 와이어프레임과 주석을 만들 때 매우 철저하고 사려깊은 것의 중요성을 보여주기에 충분합니다. 많은 경우 사용자에게 페이지 요소 수정에 대한 피드백을 받거나 변경을 요청하기 위해 와이어프레임이 표시됩니다. 다림질

186

11장: 배선 정보 및 마킹

사용자 앞에 배치되며 일반적으로 다른 이름인 프로토타입을 사용합니다. (시제품 제작에 대한 자세한 내용은 12장을 참조하십시오.) 가장 적합한 접근 방식을 식별하는 데 도움이 되도록 이 장에서는 금속 프레임 제작의 기본 사항을 다루고 산업 디자이너의 예를 제공합니다. 이 책의 나머지 부분과 마찬가지로 이러한 예는 시작에 불과합니다. 스스로 탐구하고 혁신하는 것을 두려워하지 마십시오.

표시는 무엇입니까? 레이블은 금속 프레임의 요소 또는 상호 작용에 대한 단순한 설명 및 메모입니다. 일반적으로 콘텐츠 식별자 또는 식별자와 같은 정보를 포함합니다. 콘텐츠 소스 표시 규칙 상호 작용 규칙 상호 작용 대상 프로세스 규칙 오류 콘텐츠/메시지

핵심은 아니더라도 매우 직접적인 어조와 명확한 설명으로 메모를 작성하는 것이 가장 좋습니다. 메모에 어떤 것도 우연에 맡기지 마십시오. should와 must 사이에는 매우 큰 차이가 있습니다. 나쁨: "이 클릭 유도문안(CTA)을 시작하면 홈페이지가 표시되어야 합니다." 좋음: "이 클릭 유도문안(CTA)을 시작하면 홈페이지가 표시됩니다." 공평하게 말하면 첫 번째 예는 그다지 끔찍하지는 않지만 질문에 답할 UX 디자이너가 없을 수 있는 다운스트림 개발자에게 혼란의 여지를 남겨야 합니다. 라벨링 스타일이 간결하고 지침을 읽고 신뢰해야 하는 모든 사람에게 모호함이 없도록 하십시오.

마크는 무엇입니까?

187

누가 와이어프레임을 사용합니까? 명확하고 간결한 음표가 있는 금속 프레임은 매우 훌륭하지만 이러한 결과의 청중은 누구입니까? 불행히도 이에 대한 간단한 대답은 없습니다. 프로젝트마다 청중은 한 사람에서 여러 그룹의 조합에 이르기까지 다양할 수 있습니다. 표 11.1에는 귀하의 프레임에 대한 잠재 고객이 요약되어 있습니다. 표 11.1

188

와이어프레임 잠재고객

청중

목적

프로젝트 관리

프로젝트 관리자는 팀 내에서 와이어프레임을 대화 포인트로 사용하여 전략, 기술 요구 사항 및 높은 수준의 사용자 경험을 강조할 수 있습니다.

비즈니스 분석가

비즈니스 분석가는 와이어프레임을 사용하여 요구 사항이 충족되었는지 확인하고 포함되어야 하는 요구 사항을 간과하지 않았는지 확인할 수 있습니다.

비주얼 디자이너

시각 디자이너는 금속 프레임을 결과물의 청사진으로 사용할 수 있습니다. 와이어프레임은 포함되어야 하는 페이지 요소 및 기능에 대한 설명을 제공합니다.

콘텐츠 제작자

카피라이터, 콘텐츠 전략가, 편집자 및 카피를 담당하는 기타 담당자는 와이어프레임을 사용하여 콘텐츠 매트릭스에 연결하고 프로젝트 중에 콘텐츠 요구 사항을 식별할 수 있습니다.

검색 엔진 최적화(SEO) 전문가

SEO 전문가는 와이어프레임을 사용하여 적절한 명명 체계, 카피 요구 사항 및 전반적인 SEO 전략 개선을 식별할 수 있습니다. (검색 엔진 최적화에 대한 자세한 내용은 8장에서 확인할 수 있습니다.)

개발자

개발자는 종종 비즈니스 요구 사항과 함께 와이어프레임을 사용하여 설계의 예상 기능과 동작을 이해합니다. 경우에 따라 철제 프레임을 개념 증명으로 사용할 수 있습니다.

품질 보증

QA 팀은 와이어프레임을 테스트 스크립트 작성을 위한 기초로 사용할 수 있습니다. 고객이 와이어프레임을 수락하면 변형이 최소화되어 QA 팀이 작업을 더 일찍 시작할 수 있습니다.

사용자

사용자는 설계 방향을 테스트하기 위한 메커니즘으로 매우 초기 단계에서 때로는 "종이 프로토타입"의 형태로 와이어프레임을 볼 수 있습니다. (12장 참조)

고객

고객은 비즈니스 요구 사항, 목표 및 목표를 충족하고 시각적 디자인 단계로 진행할 수 있는 권한을 부여하기 위해 금속 프레임 검토에 점점 더 많이 참여하고 있습니다.

11장: 배선 정보 및 마킹

와이어프레임 생성 와이어프레임을 생성하려면 일반적으로 일련의 요구 사항이 필요합니다. 클라이언트의 공식적인 비즈니스 요구 사항 문서, 크리에이티브 요약서 또는 프로젝트 요약서, 회의 메모, 잘 만들어진 사이트맵 또는 작업 흐름 또는 지침을 제공하는 냅킨의 메모일 수도 있습니다. 어떤 식으로든 사용자를 위해 무엇을 만들려고 하는지, 연결이 무엇인지, 기술적 한계와 기대치에 대한 일반적인 이해가 필요합니다. 참고 비즈니스 요구 사항 결정에 대한 자세한 내용은 4장과 5장을 참조하십시오. 효과적인 회의록에 대한 제안 사항은 www.projectuxd.com에서 온라인 보너스 장 "A Quick Guide to Meetings"를 참조하십시오.

필요한 정보를 수집하고, 모든 요구 사항을 주의 깊게 읽고, 질문을 하고, 추가 설명을 위해 답변을 반영하면 와이어프레임 생성을 시작할 준비가 된 것입니다!

거래 도구 10장의 "도구" 섹션에는 사이트맵과 작업 흐름을 만드는 데 사용할 수 있는 많은 디자인 도구가 나열되어 있습니다. 좋은 소식은 기본적으로 와이어프레임과 주석에 동일한 앱을 사용할 수 있다는 것입니다. 나쁜 소식은 이것이 와이어프레임을 만드는 첫 경험이라면 어디서부터 시작해야 할지 조금 헤매고 있을 수 있다는 것입니다. 하지만 기다리세요. 더 좋은 소식이 있습니다. 거의 모든 노련한 사용자 경험 전문가는 연필과 종이로 시작하므로 기술 솔루션으로 바로 뛰어들 필요가 없다고 느껴서는 안 됩니다. Adaptive Path의 경험 디자이너인 Leah Buley는 "하나의 UX 팀이 되는 방법" 프레젠테이션에서 펜과 종이(작가처럼) 사용의 중요성을 강조합니다. Leah는 말합니다. 금속 프레임에 대한 아이디어를 스케치하기 시작하면 종종 이런 일이 발생합니다. 한두 가지 좋은 아이디어가 있는데 벽에 부딪힙니다. 이러한 아이디어는 아마도 여러분이 보고 좋아했던 것 또는 과거에 디자인한 것에서 나올 것입니다. 그것은 종점이 아닙니다. 좋은 출발점입니다.

누가 LANGAREM을 사용합니까?

189

마음은 익숙한 것과 경쟁하는 경향이 있지만 익숙한 것이 문제에 대한 최선의 해결책이 아닐 수도 있습니다. 종종 아이디어 4 또는 5로 더 다양한 아이디어를 찾도록 강요할 때 새롭고 흥미로운 것을 생각해 낸 것입니다. 왜 이런 일이 일어나는지 모르겠습니다. 그냥 그렇습니다. 템플릿은 이 프로세스를 안내하는 데 도움이 될 수 있습니다. 적응형 경로에서는 6개의 작은 축소판 스케치를 위한 공간을 제공하는 6개의 이미지 템플릿을 사용합니다. 초안의 수는 실제로 그렇게 중요하지 않습니다. 중요한 것은 처음 몇 가지 명백한 아이디어를 넘어서도록 자신을 강요하는 것입니다. 식스업 디자인과 6개의 작은 상자가 모든 작은 썸네일이 채워질 때까지 계속 작업하도록 격려하기 때문에 6은 (저에게) 마법의 숫자입니다.

그림 11.1 적응 경로의 6조각 모델

이 말은 살아갈 가치가 있습니다. 특히 UX 디자인의 세계에서 자신이 하는 일을 이제 막 알게 된 경우라면 더욱 그렇습니다. 시간이 지남에 따라 자신에게 가장 적합한 접근 방식을 식별하기 시작하지만 Lean보다 더 나은 조언은 없습니다. 그의 접근 방식에 대해 자세히 알아보려면 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

시작하기 자신의 비즈니스 요구 사항 문서를 작성하는 것은 드문 일이 아니며 축복이자 저주가 될 수 있습니다. 당신이 요구사항 작성자라면 모호하거나 상대적으로 정의되지 않은 것의 의미에 대해 논의할 대상은 사실상 자신이나 클라이언트뿐입니다. 종종 알아낸 것처럼 느껴질 수 있지만 그렇다고 해서 멈추지 마십시오. 대부분의 경우 와이어프레임은 처리 중인 데이터의 차이를 식별하는 데 도움이 됩니다. 이것은 결국 최고의 솔루션을 만드는 데 도움이 될 수 있습니다. UX 전문가는 사용자에게 가능한 최상의 솔루션을 제공하기 위해 노력하며 모든 프로젝트의 첫 번째 버전은 항상 피드백을 요청하고 디자인의 다음 반복에 영향을 미치는 데 사용됩니다. 디자인이 완벽할 필요는 없지만 깔끔하고 전문적으로 보이도록 하고 싶고 최악의 시나리오는 잘못된 방향입니다. 이 홈페이지의 디자인 요구 사항은 제한적이고 매우 짧습니다. 다행히도 그림 11.2의 사이트맵은 웹 사이트에 사용되는 탐색을 설계하는 데 충분한 정보를 제공합니다. 홈 페이지(번호 1.0)는 탐색의 최상위 수준입니다. 자귀

& 용어(1.0.1)는 일반적인 바닥글 요소일 가능성이 높거나 최소한 기본 탐색의 일부로 간주되어서는 안 됩니다. 기타 기본 탐색 요소는 About(3.0), Work(4.0), Con-

tact(5.0) 및 Blog(2.0-2.x) - 페이지 스택으로 설명되므로 여러 동적 페이지로 표시되고 "이전" 및 "다음" 탐색이 가능합니다. 이러한 기본 탐색 요소는 시작하는 데 상당한 양의 정보를 제공하지만 웹 사이트의 홈 페이지를 생성할 만큼 강력하지는 않습니다. 따라서 가이드를 돕기 위해 고객은 추가 정보를 제공했습니다. 이 회사는 블로그와 진행 중인 프로젝트를 통해 노출된 부티크 사용자 경험 디자인 회사입니다. 웹사이트 방문자가 회사/웹사이트에 대해 빠르게 알 수 있는 것이 중요합니다. 또한 내비게이션이 명확해야 하며(가능한 경우 재사용 가능한 머리글과 바닥글을 선호합니다)

192

11장: 배선 정보 및 마킹

최신 블로그 게시물에는 클릭 유도 문안이 있으므로 방문자는 UX 세계의 현재 문제에 대한 최신 통찰력 요약을 빠르게 읽을 수 있습니다. 가능하다면 홈페이지에서 최근 작업을 강조할 수 있으면 좋겠지만, 우리 작업의 대부분이 개발 중이거나 엄격한 기밀로 유지되는 경우가 많기 때문에 이는 부차적인 일입니다.

와이어프레임 및 참고 사항 이러한 요구 사항은 다양한 방식으로 해석될 수 있으며 고객에게 첫 번째 와이어프레임 프레젠테이션은 그림 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 with, consectetuer adipiscing eliitti, 왜냐하면 그들은 nonummy nibh euismod tincidunt out laoreet 9 pain magna aliquam erat volutpat이기 때문입니다.

Lorem ipsum pain sit amet, consectetuer adipiscing elite, 15 sed diam nonummy nibh euismod tincidunt out laoreet pain magna aliquam erat volutpat.

내가 본 것처럼 나는 그들 중 일부가하는 것처럼 플레이어의 체벌을 실행하지 않는 최소한에 도달합니다. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

나는 고통에 대해 매우 유감입니다, 12

13 더보기 > 17

제품 번호

15 16 17 18 19

사이트의 어느 곳에서나. · 연락처 정보 탐색. · 사이트 어디에서나 연락처 페이지로 연결됩니다. · 영웅 이미지 회전. · 이미지는 미학적으로 만족스럽고 브랜드와 일치하는 여러 이미지를 통해 회전해야 합니다. · 환영 헤더. · 사이트 개요 제목. · 환영 콘텐츠. · 웹사이트의 일반 개요. · · 제목. · 작업 포트폴리오에서 표시할 임의의 예의 제목입니다. · · 사진 링크. · 작품 포트폴리오에서 볼 수 있는 임의의 예시 사진. 작업 포트폴리오에 나타나는 임의의 예에 대한 세부 정보를 볼 수 있는 링크가 있습니다. · · 요약. · 작업 포트폴리오에서 표시된 임의의 예에 대한 짧은 요약 텍스트(텍스트의 1-2줄 이하 권장). · · 링크를 추가합니다. · 작품 포트폴리오에 등장하는 랜덤 예시의 상세 내용을 볼 수 있는 링크입니다. · · 제목. · 마지막 라이브 블로그의 제목. · · 인트로 콘텐츠. · 최신 라이브 블로그의 선착순 200자. · · 링크를 추가합니다. · 최신 라이브 블로그의 전체 블로그 게시물을 볼 수 있는 링크. · 저작권 콘텐츠. · 저작권 및 현재 연도 및 회사 이름. · 약관 · &· 약관 링크.· 웹사이트 어디에서나 약관 · &· 약관 페이지로 연결됩니다. · 연락처 링크. · 사이트 어디에서나 연락처 페이지로 연결됩니다.

8 · 환영 제목. · 일반 웹사이트 개요 제목. 9 · 웰컴 콘텐츠. · 웹사이트의 일반 개요. 10 · · 제목. 무작위 예시의 제목

작업 포트폴리오에서 제공됩니다. 11 · · 사진 링크. · 랜덤 사진

nt 블로그 제목>

pain sit amet, consectetuer a 15 um nibh euismod tincidunt aliquam erat volutpat.

우리가 누구인지 말해줄게

15 16 17 18

참고 19

작업 포트폴리오 예시입니다. 작업 포트폴리오에 나타나는 임의의 예에 대한 세부 정보를 볼 수 있는 링크가 있습니다. · · 요약. · 작업 포트폴리오에서 표시된 임의의 예에 대한 짧은 요약 텍스트(텍스트의 1-2줄 이하 권장). · · 링크를 추가합니다. · 작품 포트폴리오에 등장하는 랜덤 예시의 상세 내용을 볼 수 있는 링크입니다. · · 제목. · 마지막 라이브 블로그의 제목. · · 인트로 콘텐츠. · 최신 라이브 블로그의 선착순 200자. · · 링크를 추가합니다. · 최신 라이브 블로그의 전체 블로그 게시물을 볼 수 있는 링크. · 저작권 콘텐츠. · 저작권 및 현재 연도 및 회사 이름. · 약관 · &· 약관 링크.· 웹사이트 어디에서나 약관 · &· 약관 페이지로 연결됩니다. · 연락처 링크. · 사이트 어디에서나 연락처 페이지로 연결됩니다.

그림 11.3 댓글과 함께 홈페이지 디자인을 위해 전송된 와이어프레임

간단하게 시작: 기본 스레드 설계

193

주석이 달린 금속 프레임은 각 페이지 요소, 예상 클릭 유도문안 및 작업 결과(예: 특정 페이지 로드)를 자세히 설명합니다. 이 예제는 제한된 수의 요소와 제한된 양의 세부 사항이 필요하기 때문에 매우 잘 작동합니다.

그림 11.4 www.userglue.com의 라이브 홈 페이지 디자인

그림 11.4에서 볼 수 있듯이 이 홈페이지의 현재 라이브 버전은 그림 11.3의 원래 프레임과 약간만 다릅니다. 예를 들어 일정 및 콘텐츠에 문제가 있었기 때문에 포트폴리오 예제 섹션이 제거되었습니다. 또한 내비게이션 및 클릭 유도문안의 이름 지정 규칙의 차이점에 유의하세요. 유선은 지침이지 마지막 단어가 아닙니다. 또한 최종 결과에는 종종 와이어프레임의 내용과 비교하여 몇 가지 작은 변경 및 업데이트가 있습니다.

194

11장: 배선 정보 및 마킹

연습: 홈페이지용 와이어 프레임 디자인 예제를 보셨으니 이제 직접 와이어 프레임을 만들어 보세요. 귀하의 임무는 가상의 국제 크루즈 회사인 Global Cruises의 홈페이지를 재설계하는 것입니다. Global Cruises는 홈 페이지가 크루즈를 예약한 것으로 보이고 다른 옵션 및 추가 사항에 대해 자세히 알고 싶어하는 재방문자를 위한 보다 효과적인 판매 도구 및 정보 소스가 되기를 원합니다. 정황. , 등등. 연습에서는 아래 요구 사항을 사용하여 문서 또는 별도의 문서(선택)에 대한 주석이 있는 단일 홈 페이지 프레임을 만듭니다. 아무것도.

요구 사항 가장 중요한 필수 요구 사항은 일반적인 머리글과 바닥글(그림 11.5)이 동일하게 유지되어야 한다는 것입니다. GLOBAL HEADER 로고 항목

현재 캠페인 로고 여행 경험

여행 계획하기

해

여행 전

글로벌 크루즈

VIP 클럽

특별 제공

가다

마이 월드 크루즈

다시 오신 것을 환영합니다.아니다?) | 다음 크루즈까지 XX일 - 예약 관리 | BookTravel 엑스트라| 온라인 체크인

그림 11.5 기존 Global Cruises 전역 머리글 및 바닥글

연습: 첫 페이지 디자인

195

"있으면 좋은 것"은 최신, 가장 인기 있는 및/또는 판매 계획을 표시하는 기능 여정의 지리적 위치 및 경유지를 표시하는 기능 로그인한 경우 여정을 볼 수 있는 기능(MY TINEERARY/IES) 추가 정류장과 같은 추가 판매 항목을 볼 수 있는 기능 (예를 들어 당신이 가고 있다면

하와이의 경우 섬 투어 예약), 선상 식사 경험 등 추가할 가치가 있다고 생각하는 모든 것

글로벌 크루즈 이제 작업이 시작됩니다. 와이어프레임 스케치를 시작하고 메모하는 것을 잊지 마세요! 철선이 준비되면 다음 페이지에서 동일한 요구 사항을 받은 다른 최고 전문가의 예를 참조하십시오.

196

11장: 배선 정보 및 마킹

결과: 디자인 홈 페이지 와이어프레임 Semantic Foundry(www .semanticfoundry.com)의 사용자 경험 아키텍트인 Will Evans는 친절하게 글로벌 크루즈 연습 요구 사항을 기반으로 와이어프레임을 만들었습니다. 자신의 작업을 그림 11.6 및 11.7의 그의 디자인과 비교하여 그의 접근 방식이 당신의 접근 방식과 어떻게 비교되는지 확인하십시오. 다음은 그가 금속 프레임과 노트를 조립한 방법을 설명합니다. 990픽셀 너비의 여행 알림

크루즈 찾기

심벌 마크

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

다음 메타데이터가 포함된 Cruise Billet: 1. 가격 2. 평균 평점 3. 제목: 크루즈 제목 4. 기간 5. 항구 6. 세부 정보 링크 7. 이 크루즈 링크 예약 8. 이 크루즈를 즐겨찾기에 기억/추가

8.0

패싯 탐색 기능을 통해 사용자는 포트, 여행 월, 배송 또는 가격 범주를 동적으로 변경하고 해당 결과를 동적으로 정렬/필터링할 수 있습니다. 사용자가 검색 결과 화면에서 모든 결과를 볼 때 이 중 하나를 취소할 수 있습니다.

9.0

사용자는 예측 검색에 대한 필터를 설정한 후 클릭하여 모든 검색 결과를 볼 수 있습니다. 그러면 전체 결과 Ajax가 빠른 정렬을 위해 javascript 테이블로 로드됩니다.

순간을 공유하세요 Call Out, 회원 프로필 크라우드소싱 페이지에 나만의 Starring Your Moments 링크를 제출하세요.

세부 사항

Shot FridayHero Saturday의 제목

이 특별 패키지 예약

-모든 선박 제안/뉴스

$190-$1650

Adipasisic Duis라는 제목을 따랐다, 또는 고통은 쾌락에 의해 꾸짖어지고, 그는 고통으로부터 머리카락이 되고자 하며, 태어날 일이 없을 것이다.

명료함은 주님 자신의 고삐, 또는 꾸짖는 고통의 분노이며, 그는 깃털의 고통 속에 있기를 원하는 기쁨입니다.

주연 당신 순간

세부 사항

가격: 헤도닉 이미지

명료함은 주님 자신의 고삐, 또는 꾸짖는 고통의 분노이며, 그는 깃털의 고통 속에 있기를 원하는 기쁨입니다.

링크가 포함된 새로운 여정: 4.x 섹션에 대한 링크가 포함된 여정 표시 인기 여정 - 상위 5개 여정을 보여주는 드롭다운 메뉴

5.0

나소

좋은:

-매 달 -

쾌락적 이미지

헤더 결과 Adipisicing

정의된 사용자 시나리오로 예측 제안 검색 3.X

4.0

세부 사항

지금 당신의 결과! 가다

월:

링크 홈페이지의 브랜딩/로고

3.0

금요일 토요일 7박

그레이트 스터럽 케이(우리만의 개인 섬) 포트 커내버럴 찰스턴

고향/도시: Campaign/News Washington, D.C. 8.0

나소

여정 참조 | 나의 글로벌

금요일 토요일 7박

여행 알림: 0.2.0.0 링크

2.0

세부 사항

금요일 토요일 7박

1.0

나의 글로벌

HEDONIC IMAGE 9.0 검색결과 전체보기

Adipasisic 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's Words 나에게 와이어프레임은 특정 문제 공간(이 예에서는 유람선 운영자의 홈 페이지)을 정의하고 탐색하기 위한 일종의 "사고 장치" 역할을 합니다. 철골을 사용하여 디자인하는 것은 문제 공간에서 대안을 찾는 것입니다. 그것은 문제 해결 과정만큼이나 문제 설정 과정입니다. 즉, 저는 항상 맥락에서 시작합니다. 이 경우 주요 청중은 적시에 적시에 적절한 가격으로 최고의 크루즈를 쉽게 찾고 싶어합니다. 단순화하기 위해 저는 주요 청중과 그들이 하나의 목표를 빠르고 쉽고 우아하게 해결할 수 있는 하나의 활동을 선택합니다. 여러 개의 와이어프레임을 스케치하여 옵션을 탐색할 수 있으며 불가능하거나 상상할 수 있는 아이디어가 모두 제시되고 테스트되며 많은 경우 폐기됩니다. 저는 가능한 최고의 크루즈 검색 사용자 인터페이스를 디자인하고 싶다는 것을 이미 알고 있었고 이 기능이 디자인의 우선 순위가 되기를 원했습니다. 사용자가 보기로 약속하기도 전에 즉석 제안 크루즈를 제공하는 개념을 스케치한 곳이 바로 여기였습니다.

198

11장: 배선 정보 및 마킹

전체 검색 결과 표시. 사용자가 대화에 참여하고 좋은 크루즈를 찾는 데 참여하기를 원했습니다. 크루즈 찾기

바하마

알겠습니다. '바하마'를 찾아보겠습니다.

가다

18 크루즈 상품

279달러

바하마 및 플로리다

279달러

바하마 및 플로리다

279달러

바하마 및 플로리다

279달러

바하마 및 플로리다

찰스턴 프리포트

7박

그레이트 스터럽 케이(우리만의 개인 섬) 포트 커내버럴 찰스턴

나소

7박

그레이트 스터럽 케이(우리만의 개인 섬) 포트 커내버럴 찰스턴

나소

세부 사항

금요일 토요일 7박

그레이트 스터럽 케이(우리만의 개인 섬) 포트 커내버럴 찰스턴

세부 사항

금요일 토요일 7박

그레이트 스터럽 케이(우리만의 개인 섬) 포트 커내버럴 찰스턴

세부 사항

금요일 토요일

세부 사항

금요일 토요일

결과 필터링 Y 고향 항구/도시: 월:

워싱턴 DC.

좋은:

-매 달 -

가격:

- 모든 선박

$190-$1650

모든 검색 결과 보기

그림 11.8 Will Evans 홈페이지 크루즈 검색 결과 기능

유람선 사업자의 경우 머리글, 바닥글, 정적 콘텐츠, 클릭 유도문안, 프로모션 등 콘텐츠 모듈 디자인에서 제외해야 할 영역을 스케치했습니다. 이 단계의 결과를 주요 이해관계자와 공유할 것이지만, 비주얼 디자이너, 개발 리드 및 QA도 참여시켜 그들이 프로세스에 참여하고 더 많은 아이디어를 제공하고 함정과 제약 사항을 문서화할 수 있도록 할 것입니다. 마지막으로 디자이너로서 사양에 디자인을 구현하기로 결정해야 했습니다. 저는 최종 고려를 위해 2~3개의 후보를 생성하고 이해관계자와 대상 테스터에게 어필할 수 있도록 주석이 포함된 와이어프레임을 제공했습니다. 그림 11.6 및 11.7에 표시된 금속 와이어는 이제 디자인 변경이 적고 세부 사항이 개선된 이 단계에 있습니다.

연습: 첫 페이지 디자인

199

비교 및 대조 그림 11.3의 예와 Will Evans의 작업은 금속 프레임을 만드는 스타일이 상당히 비슷하지만 다르다는 점에 유의하는 것이 중요합니다. 이제 보기도 편하고 "이건 철제 프레임이야!"라고 자랑스럽게 말할 수 있습니다. 둘 다 고유한 스타일과 접근 방식이 있지만 핵심은 매우 유사합니다. 이 장의 예는 자신에게 가장 적합한 와이어 프레이밍 스타일을 찾을 수 있는 좋은 장소입니다.

평가: Maciej Piwowarczyk

시각 디자인: 와이어프레임이 성장하고 세상에서 길을 찾을 때

그림 11.9 Mark Brooks의 Global Cruises 홈페이지 비주얼 디자인

200

11장: 배선 정보 및 마킹

Mark Brooks(www .markpbrooks.com)는 요구 사항과 Will Evans의 와이어프레임에서 가상의 Global Cruise Lines에 대한 홈 페이지 디자인을 만들었습니다. 그림 11.9의 시각적 디자인을 보면 그가 페이지 레이아웃과 콘텐츠를 어떻게 고려했는지 알 수 있습니다. 디자인이 프로세스를 거쳐 개발 단계로 이동함에 따라 상호 작용 패턴이 생기기 시작합니다.

계획 실행 모니터링: 어떤 모델이 적합합니까? 요구 사항이 충족되는 한 옳고 그른 디자인은 없습니다. 때로는 단일 페이지에 여러 와이어프레임을 생성하여 다양한 접근 방식을 탐색하고, 세부 사항을 해결하고, 잠재 사용자, 팀원 및 고객에게 제시해야 할 수 있습니다. 이것은 완벽하게 수용 가능합니다. 이것은 반복 연습이라는 것을 기억하십시오. 고객에게 제공하는 작업은 거의 항상 처음부터 "올바른" 또는 "최종"으로 간주되지 않습니다. 대부분의 경우 최소한 한 번의 반복 및 업데이트를 거쳐야 합니다. 불행히도 때때로 여러 라운드로 확장될 수 있지만 이는 프로젝트의 특성이며 결국 다운스트림 파트너를 덜 탐색하게 됩니다. 금속 프레임과 메모를 제공된 두 가지 예와 비교할 때 접근 방식과 프레젠테이션의 차이점을 살펴보세요. 이 장 앞부분의 홈페이지 예제 및 수행한 작업과 이를 비교하십시오. 유사점과 차이점을 찾고 이미 확립된 모델이 없는 한 자신에게 가장 적합한 접근 방식을 만드십시오. 많은 경우 와이어프레임을 만드는 데 있어 가장 어려운 부분은 처음으로 펜을 종이에 쓰는 것입니다. Leah Buley의 조언에 따라 다양한 아이디어 스케치를 시작하세요. 그림을 그리고 스케치하고, 다양한 접근 방식을 탐색하고, (방어적이지 않고) 디자인을 방어할 수 있다는 확신이 들 때까지 동료, 동료, 가족과 함께 디자인을 테스트하세요. 올바른 방향으로 자신을 찾으십시오.

연습: 첫 페이지 디자인

201

와이어프레임 소개에 대한 최종 참고 사항 와이어프레임을 만들기 시작하고 작업 결과물에 더 익숙해지고 워크플로에 얼마나 가치가 있는지 깨닫게 되면 모든 사람이 와이어프레임을 만드는 데 드는 생각과 시간을 이해하지 못한다는 사실을 잊기 쉽습니다. 종종 고객과 작업 파트너는 품질, 복잡성 또는 마킹 스타일 수준이 다른 강철 프레임에 노출되었을 수 있습니다. 실제로 많은 동료와 고객이 이전에 금속 프레임을 본 적이 없다는 것을 알 수 있습니다(그들이 본 적이 있다고 주장하더라도). 클라이언트와 파트너가 사이트맵과 프레임의 차이점과 목적에 대해 혼란스러워하는 것도 드문 일이 아닙니다. 즉, 첫 번째 철선이 잠재적으로 고객의 첫 번째 철선이 될 수도 있습니다! 그렇기 때문에 발표할 내용에 대한 명확한 프레임워크를 설정하는 것이 매우 중요합니다. 와이어프레임을 도입하기 전에 와이어프레임이 무엇인지, 최종 시각적 디자인과 비교하여 어떻게 보이는지, 그 목적이 무엇인지 명확하게 설명해야 합니다. 다음은 금속 프레임 제시에 대한 몇 가지 추가 정보입니다. 가능하면 검색 중에 고객 팀을 참여시키십시오. 그들을 얻으려고

칠판에 그림 그리기에 적극적으로 참여했습니다. 그들이 프레이밍 프로세스에 참여하고 최종 결과는 동일하게 보이지만 전자 형식으로 생성될 것이라고 설명합니다. 이것은 설계 옵션을 탐색할 때 완전히 다르게 보일 수 있는 보강 철근 구조를 초래하는 활동임을 설명하는 것이 매우 중요합니다. 리드 간의 차이점을 전달하기 위해 강력한 은유를 찾으십시오.

프레임 워크 및 프로젝트의 최종 디자인. 인기 있는 은유는 "집에 청사진/평면도가 있는 것처럼 앱/웹사이트에 와이어프레임이 있습니다."입니다. 와이어프레임을 사용하면 변경 사항을 보다 쉽고 효율적으로 구현할 수 있으며 일반적으로 변경 사항이 더 저렴한 단계(팀을 구성하고 기반을 마련하기 전)에 적용할 수 있습니다. 회의 참가자들에게 Metallilangat가 최종 프레젠테이션이 아니라고 알립니다.

사이트의 그래픽 처리. 콘텐츠, 전체 레이아웃 및 상호 작용을 설명하기 위해 와이어프레임이 제공됩니다.

202

11장: 배선 정보 및 마킹

페이지 요소. 철선이 승인되면 공사를 시작할 수 있습니다. (아, 그리고 미묘한 변화는 여전히 일어날 수 있습니다!) 시간과 예산이 있다면 시각 디자이너를 데려와

와이어프레임과 최종 설계 사이의 차이점을 보여주는 설계 모델. 가능하면 금속 프레임과 최종 디자인이 동시에 어떻게 유사하고 다른지를 보여주는 다른 프로젝트의 고객 사례를 보여주십시오. 프로젝트 팀의 다른 구성원이 리드를 사용하는 방법 설명

프레임 – 고객이 이 이정표를 검토하고 승인하는 것의 중요성과 금속 프레임이 프로젝트의 나머지 부분에 어떻게 영향을 미치는지 이해하는 것은 결코 나쁠 일이 없습니다. 클라이언트와 파트너가 금속 프레임의 가치와 디자인 프로세스에서의 위치를 이해하고 감사하기 시작하면 프로젝트를 더 쉽게 진행할 수 있습니다. 왜? 금속 와이어는 프로젝트 전반에 걸쳐 시각적 명확성과 방향성을 만드는 데 도움이 되기 때문입니다. 많은 경우 동료와 고객은 금속 프레임의 유용성을 전파할 수도 있습니다. 이렇게 하면 사용자 경험을 디자인하는 데 더 많은 시간을 할애하고 판매 시간을 줄일 수 있습니다!

스레드 보조금 제시에 대한 최종 참고 사항

203

프로토타이핑 계획에 생명을 불어넣습니다. 프로토타이핑은 개발에 투자하기 전에 제안된 기능과 모델을 테스트하고 검증하는 효과적인 방법입니다. 신속하고 깔끔한(빠르고 깨끗한 것을 선호함) 것부터 대화형 및 내구성에 이르기까지 프로토타이핑에 다양한 도구와 접근 방식을 사용할 수 있습니다. 사용하는 방법은 주로 프로토타입을 개발하는 데 사용할 수 있는 시간과 재료라는 두 가지 요소에 의해 결정됩니다. 러스 엉거와 조노 케인

프로토타이핑이란 무엇입니까? 사용자 경험 디자인의 맥락에서 프로토타이핑(및 많은 경우 기술)은 사용자와 함께 애플리케이션이나 웹 사이트의 기능을 만들고 테스트하는 것입니다. 프로토타이핑은 아날로그 도구(예: 화이트보드 또는 펜과 종이)를 사용하거나 PowerPoint, Acrobat, Visio, OmniGraffle, HTML 또는 기타 기술 기반 도구를 사용하여 디지털 방식으로 수행할 수 있습니다. 프로토타이핑은 일반적으로 사용자 경험 문제를 식별하거나 검증하기 위해 생성되므로 반복적인 프로세스가 될 수 있습니다. 피드백을 수집한 후 추가 테스트를 위해 프로토타입을 변경할 수 있습니다. 다른 경우에는 성공적인(충분한) 프로토타입이 프로젝트를 개발 수명 주기의 다른 단계로 계속 진행할 수 있습니다. 프로토타이핑은 가공물이 아니라 프로세스라는 점을 기억하십시오. 프로토타이핑이라고 부르는 화면 및 (때로는 모의) 기능을 생성하게 될 수 있지만 이는 최종 결과가 아니라 프로토타이핑의 일부입니다. 프로토타이핑 프로세스는 디자인을 다듬고 개선하는 데 사용할 수 있는 개념의 피드백을 가져옵니다. 그러나 이 장은 프로토타이핑에만 초점을 맞추고 테스트에 대한 세부 사항은 13장에 맡깁니다.

얼마나 많은 프로토타입이 필요합니까? 모든 사용자 경험 디자인 프로세스에는 공식적이든 비공식적이든, 대화형이든 정적이든 일정 수준의 프로토타이핑이 포함되어야 합니다. 전체 웹사이트나 애플리케이션의 프로토타입을 만들 필요가 없습니다. 실제로 프로토타이핑은 시스템의 대표적인 샘플링만 사용할 때 매우 효율적일 수 있습니다. 즉, 전체 시스템의 시뮬레이션을 만들 필요 없이 가장 중요한 부분만 만들면 됩니다. 대부분의 경우 몇 가지 개념을 테스트하고 싶고 프로토타입에는 이러한 개념만 포함되어야 합니다. 화이트보드, 연필 및 종이 스케치, 스토리보드, 판지 오려내기 등 원하는 대로 여러 가지 방법을 사용하여 프로토타입을 만들 수 있습니다. 또한 대화형 프로토타입을 만들고 보다 현실적인 환경에서 테스트 사용자를 참여시키는 데 도움이 되는 여러 디지털 도구를 사용할 수 있습니다.

얼마나 많은 프로토타입이 필요합니까?

205

선택한 프로토타이핑 방법은 사용 가능한 시간과 재료에 따라 크게 달라집니다. 다음은 많은 프로토타이핑 요구 사항을 충족하는 데 사용할 수 있는 가장 널리 사용되는 방법 중 일부입니다.

종이 프로토타이핑 종이 프로토타이핑의 실습 예술 및 공예 접근 방식과 같이 어린 시절로 돌아갈 수 있는 활동은 거의 없습니다. 필요한 유일한 도구는 연필과 펜, 종이, 가위, 미술 부서에서 수집하거나 지역 사무용품점에서 구입할 수 있는 모든 것입니다. 종이 프로토타입의 생산은 유연합니다. 지우개 또는 더 많은 재료가 있는 한 필요한 만큼 시나리오를 만들 수 있습니다. 또한 테스트마다 신속하게 확인할 수 있습니다. 즉, 잠재적인 사용자가 귀하가 만든 항목에 눈에 띄는 오류가 있다고 보고하는 경우 다음 잠재적 사용자에게 보여주기 전에 디자인을 업데이트하는 복잡한 프로세스가 아닙니다. 또한 저렴합니다. 종이 프로토타이핑에 투자하는 것 외에도 일반적으로 고급 라떼 몇 개보다 훨씬 적은 시나리오를 만들 수 있습니다. 이미 종이, 포스트잇, 색인 카드, 연필 등이 있어야 하며, 그렇지 않은 경우 비축하여 은행을 망치지 않을 것입니다. 프로세스는 간단합니다. 테스트하려는 일부 기능을 그립니다. 사용자에게 기능을 소개합니다. 피드백을 문서화합니다(종이이므로 프로토타입을 뒤집고 쓰기 시작). 그런 다음 다음 사용자로 이동하거나 업데이트를 수행하고 다시 시작하십시오. 단순한. 재미있는. 효과적인. 프로세스 초기에 종이 프로토타입을 사용하면 막대한 투자를 하기 전에 디자인 문제를 발견하는 데 도움이 될 수 있습니다. 이 단계에서 변경을 빠르고 효율적으로 수행하여 위험을 줄일 수 있습니다. 이렇게 하면 디자인에 너무 많은 투자를 하기 전에 효과적으로 변경할 수 있습니다. 그림 12.1의 각 탭은 세 가지 다른 색상의 종이를 사용하여 웹 사이트에 표시되는 대로 그려지고 서로 쌓였습니다. Global Now 탭은 맨 위에 위치하여 사용자가 처음으로 홈 페이지를 방문한 것처럼 콘텐츠를 표시합니다. 각 탭은 사용자가 사용할 수 있는 탐색을 표시하고 다른 보기 옵션을 선택할 수 있도록 합니다.

206

12장: 프로토타입

그림 12.1 세로 탭 기반 탐색의 종이 프로토타입

그림 12.2 내 경로 탭이 활성화된 수직 탭 기반 내비게이션의 페이퍼 프로토타입

사용자가 다른 탭을 선택하면 해당 탭이 스택의 맨 앞으로 이동하여 그림 12.2에 표시된 My Itinerary 탭과 같이 콘텐츠 영역에 활성 탭의 보기를 표시합니다. 종이 프로토타이핑은 최대한 저예산으로 할 수 있으며 위의 연습처럼 간단할 수 있습니다. 전체 시스템을 조사하기 시작하면 투자하는 작업 시간이 크게 증가할 수 있습니다(재료 비용이 약간만 증가하더라도). 100개의 종이 프로토타입 페이지에서 기본 탐색을 변경해야 하는 경우 이 방법은 비용이 많이 듭니다. 종이 프로토타이핑은 근본적으로 저렴하지만 조각을 업데이트해야 할 때 재사용하기에는 적합하지 않습니다. 그 시점에서 디지털 도구로 전환하는 것이 더 유용한지 생각해야 합니다.

디지털 프로토타이핑 프로토타이핑 요구 사항이 종이로 처리할 수 있는 것보다 큰 경우 기술 기반 솔루션이 귀하와 청중에게 더 적합하다는 것을 알 수 있습니다. 이러한 도구를 사용하면 사이트 또는 응용 프로그램의 대화형 부분이 사용자에게 어떻게 표시되는지 정확하게 보여줄 수 있습니다. 디지털 프로토타이핑은 디자인 프로세스의 다른 많은 측면을 활용합니다. 디지털 프로토타입을 시연하거나 테스트할 때 페르소나, 프로토타이핑 및 시각적 처리를 위한 철제 프레임, 사실적인 이미지를 위한 시각적 디자인 리소스(프로세스의 이 단계에서 사용 가능한 경우)를 참조할 수 있습니다. 프로토타입을 맞추고 마무리합니다.

와이어프레임 대 사실적인 프로토타입 종이 프로토타이핑 방법과 마찬가지로 마일리지는 디지털 프로토타입에 따라 다를 수 있습니다. 사용 가능한 도구, 리소스 및 기술에 따라

디지털 프로토타이핑

207

폐기 및 처리 중인 요구 사항을 고려하여 프로토타입을 금속 프레임처럼 보이게 만드는 것이 프로젝트에 충분하다는 것을 알 수 있습니다. 사실 그게 더 나을 수도 있습니다. 와이어프레임은 프로젝트가 아직 진행 중인 작업이며 최종 제작 준비가 된 사이트가 아님을 청중에게 보여줄 수 있습니다. 반면에 때때로 사용자와 함께 디자인을 테스트하는 동안 프로토타입의 가장 중요한 측면이 최종 시스템을 얼마나 사실적으로 표현하는지를 알게 됩니다. 디지털 프로토타입의 결과는 세 가지 요소를 기반으로 합니다. 타임라인은 어떻게 생겼습니까?

팀을 구성하고 바로 앞에 있는 사용자에게 생산 준비 위치에 대한 명확한 비전을 보여주는 놀랍고 생산 준비가 된 프로토타입을 구축할 시간이 있습니까? 와이어프레임을 HTML로 내보내거나 프로젝트의 페이지 흐름과 기본 대화형 요소만 표시하는 매우 간단한 Flash 프로젝트를 빌드할 몇 시간이 있습니까? 두 디지털 프로토타입 모두 매우 유용할 수 있습니다. 그러나 기한이 임박한 실제 프로젝트와 마찬가지로 사용 가능한 시간과 자료를 기반으로 기대치를 설정하는 것이 중요합니다. 누구를 위해 이 프로토타입을 제작하고 있으며 그 이유는 무엇입니까?

프로젝트에 너무 깊이 들어가기 전에 무엇을 하고 있는지 아는 것은 프로토타입의 성공에 매우 중요합니다. 사용자와 함께 디자인 테스트를 위한 프로토타입을 만들고 있습니까? 그렇다면 테스트에서 중점을 두어야 할 중요한 사항은 무엇입니까? 프로토타입이 흑백 프레임인지 아니면 라이브 웹 사이트와 유사해야 하는지가 중요합니까? 버튼과 링크의 검색 가능성을 테스트합니까? 경영진, 관리자, 투자자 또는 하루가 끝날 때 귀하의 수표에 서명할 수 있는 다른 사람의 동의가 필요한 비즈니스 프레젠테이션을 위한 프로토타입을 만들고 있습니까? 그렇다면 그들에게 무엇을 전달하려고 합니까? 기능적이어야 하는 것과 기능적으로만 보여야 하는 것은 무엇입니까? 이러한 질문은 디지털 프로토타입의 요구 사항을 결정하는 데 도움이 될 수 있습니다.

208

12장: 프로토타입

어떤 종류의 리소스, 도구 및 기술을 마음대로 사용할 수 있습니까?

HTML 또는 Flash 전문가가 아니고 전문가를 고용할 예산이 없는 경우에도 PowerPoint 또는 Keynote와 같은 간단한 프레젠테이션 도구나 Visio 또는 OmniGraffle과 같은 프레이밍 도구를 사용하여 기능이 뛰어난 프로토타입을 제작할 수 있습니다. 간단한 PDF도 가능합니다.

HTML 대 WYSIWYG 편집기 HTML은 종이 프로토타입에 해당하는 디지털입니다. (때로는) 무료이고 (다소) 쉽습니다. HTML 마법사나 UI 코드 전문가가 아니더라도 기본적인 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로 저장합니다. 텍스트 편집기를 사용하는 경우 파일 형식으로 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 문서에 대한 링크를 정의하는 데 사용됩니다. 단순화를 위해 예제의 앵커 태그는 튜토리얼이 동일한 폴더에 있기 때문에 "relative"라는 상대 경로를 사용합니다. 절대 경로는 다음과 같습니다. 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: Patrick Griffiths의 XHTML 및 CSS에 대한 모범 사례 가이드(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 형식으로 내보낼 수 있으므로 CTR 프로토타입을 만들 수 있습니다. OmniGraffle에서는 함수를 쉽게 정의하고 HTML 형식으로 내보낼 경우 PDF 파일 또는 URL에 점프 지점을 지정할 수 있습니다. Visio에는 페이지 간 탐색을 위해 클릭 가능한 영역을 사용하여 HTML 또는 PDF로 쉽게 내보낼 수 있는 다운로드 가능한 프로토타입 키트가 있습니다. Visio 및 OmniGraffle은 또한 EPS, GIF 및 JPEG와 같은 널리 사용되는 벡터 및 래스터 형식을 내보낼 수 있으므로 이미지를 Flash로 쉽게 가져오고 HTML 프로토타입의 이미지로 사용하는 등의 작업을 수행할 수 있습니다. Axure RP Axure RP의 "RP"는 신속한 프로토타이핑을 의미하며 많은 UX 디자이너에게 인기 있는 도구입니다. 이 도구는 Visio 및 OmniGraffle과 유사한 그리기 기능을 제공하지만 다양한 탐색 스타일, 양식, 팝업 및 기타 일반적인 페이지 기반 상호 작용을 만들 수 있는 상대적으로 배우기 쉬운 도구를 추가합니다. . 또한 사양, 설명, 작업 및 진행 노트와의 유연한 통합을 통해 프로토타입에서 직접 문서 기반 사양을 생성할 수 있습니다. 그러나 Axure는 Windows 전용 도구이므로 Mac으로 작업하고 Windows를 시작할 수 있는 앱을 사용하지 않는 경우 문제가 될 수 있습니다. Fireworks CS4 Adobe의 Fireworks CS4는 최근 금속 프레임에서 시각적 디자인에 이르기까지 다양한 디자인 구성 요소를 만드는 데 널리 사용되는 도구가 되었습니다. 여기에는 외부 개발자 없이도 기능을 강조할 수 있는 쉽게 정의된 상호 작용을 허용하는 표준 Windows 및 Mac 양식 요소 및 컨트롤 세트가 있습니다. 공용 라이브러리는 여러 문서에서 추가하고 공유할 수 있는 요소를 저장하므로 재사용할 수 있습니다.

디지털 프로토타이핑

215

구성 요소. Fireworks에는 개발자가 "포함"을 사용하는 방법이나 일부 문서 시스템에서 문서 페이지를 재사용하기 위한 배경을 만드는 방법과 유사하게 지정된 문서의 모든 페이지에 공통적인 요소 세트를 만들 수 있는 페이지 기능도 포함되어 있습니다. 이 기능은 각 페이지에서 고유한 콘텐츠 영역을 유지하면서 머리글, 바닥글 및 탐색과 같은 반복 가능한 페이지 수준 콘텐츠 영역을 식별하는 데 유용합니다. Balsamiq 목업 Balsamiq Studios의 목업은 연필과 종이 스케치 경험을 제공하는 와이어프레임 및 프로토타이핑 도구입니다. 컴퓨터만 사용하고 있습니다. 화면에 드래그 앤 드롭하고 프로젝트에 맞게 사용자 지정할 수 있는 미리 디자인된 공통 UI 컨트롤(작성 당시 60개 이상)이 많이 있습니다. 모델은 마치 손으로 그린 것처럼 스타일이 지정되어 디지털로 생성된 디스플레이에 좀 더 유기적인 느낌을 주지만 디지털 플랫폼을 사용하면 빠른 반복을 위해 모델을 빠르게 수정할 수 있습니다. Flash 및 Flash Catalyst 프로토타이핑 Adobe Flash는 클릭 가능한 프로토타입을 넘어 인터랙티브한 개념을 전달할 수 있는 좋은 방법입니다. Flash를 사용하면 클릭 프로토타입을 쉽게 만들 수 있지만 마우스 포인터 이벤트, 클릭 이벤트, 비디오 및 애니메이션을 비롯한 다른 상호 작용 요소를 추가할 수도 있습니다. Flash를 더 깊이 파고들 수 있다면 Flash에는 사용자 상호 작용에 응답하고 원하는 출력을 표시하도록 프로그래밍할 수 있는 핵심 사용자 인터페이스 구성 요소 세트도 있습니다. Boxes and Arrows: www.boxesand arrows.com/view/quick-and-easy-flash에서 Alexa Andrzejeski의 기사 "Quick and Easy Flash Prototypes"에서 Flash 프로토타이핑의 시작을 확인하십시오. 이 책이 나왔을 때 Adobe는 Flash Catalyst라는 새로운 프로토타이핑 도구를 발표했습니다. Flash Catalyst는 디자인과 개발 프로세스 간의 채널로서 다른 Adobe CS4 응용 프로그램과 함께 작동하는 개발 환경입니다. 이를 통해 적은 노력으로 템플릿을 브라우저 지원 형식으로 내보낼 수 있습니다. 자세한 내용은 www. Adobe.com.

216

12장: 프로토타입

개발자와 작업 필요한 리소스가 있는 경우 와이어프레임이나 계획을 기반으로 프로토타입을 생성하도록 개발자에게 요청할 수 있습니다. 개발자는 수행하려는 작업을 잘 이해하고 있어야 하므로 이 접근 방식을 사용하려면 프로세스를 효율적이고 효과적으로 만들기 위해 개발 사양 및 요구 사항을 만들어야 할 수도 있습니다. 프로토타입이 반복 테스트에 사용되는 경우 프로토타입의 어느 부분에 테스트에 중점을 두고 있는지, 따라서 변경 사항을 신속하게 구현해야 하는지 명시해야 합니다. 개발 프로세스 중에 개발자와 시간을 보내고 변경에 취약한 것으로 표시(코드 주석 포함)해야 하는 코드의 주요 영역을 식별하는 것이 좋습니다. 프로토타입을 개발하는 동안 개발자와 연락을 유지하여 커뮤니케이션 라인을 개방하고 결과의 정확성을 보장하십시오. 참고 다양한 프로토타이핑 방법에 대한 자세한 내용은 Todd Zaki Warfel이 저술한 A Practitioner's Guide to Prototyping 책(Rosenfeld Media, 2009년 출판 예정: www.rosenfeldmedia.com/books/prototyping)을 참조하십시오.

프로토타이핑 예제 이 장에 있는 간단하고 사용하기 쉬운 프로토타이핑 예제는 모든 상황에서 사용해야 하는 완벽한 접근 방식과는 거리가 멉니다. Keith Tatum과 Jon Hadden은 프로토타이핑의 실제 사용 경험을 아낌없이 공유하여 강조했습니다. Slingthought(www .slingthought.com)의 수석 사용자 경험 전략가인 Keith Tatum은 왼쪽 탐색 링크를 설명하고 Align Interactive(www .aligninteractive)의 파트너를 위한 탐색 계층 및 분류를 식별하기 위해 그림 12.5의 종이 프로토타입을 만들었습니다. .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는 프로젝트 관리를 위한 협업 웹 기반 애플리케이션입니다. 이것은 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분 동안 살펴본 다음 목록에서 모델을 가장 잘 설명하는 용어를 3개 이상 선택하도록 요청할 수 있습니다. 그들은 지루함, 트렌디함, 보수적, 시끄럽다, 안전함 등과 같은 20개의 단어로 된 시트에서 무작위 순서로 선택 사항에 동그라미를 칠 수 있습니다. 열린 질문에 대한 답변을 수집할 수도 있습니다. 예를 들어 참가자들에게 디자인에 대한 전반적인 인상을 쓰도록 5개의 빈 줄을 줄 수 있습니다. 귀하가 수집하는 일부 정보에는 참가자가 생성한 일반적인 브랜드 연상이 포함됩니다.

"Pseudo Corporation은 위젯 제조업체의 롤스로이스입니다. 멋져 보이지만 아마도 감당할 수 없을 것입니다."

224

13장: 사용자와 디자인 테스트

디자인과 라이프스타일:

"나는 내 아들을 이 사이트에 보내지 않을 것이라고 생각합니다. 그는 겨우 8살이고 이 사진들은 그에게 너무 어른스러워 보입니다." 새로운 개념을 설명하는 특정 모델의 효율성:

"아, 알겠습니다. 이 사이트는 결혼 등록부와 같지만 요리 대신 자선 단체에 등록하고 있습니다." 참가자가 귀하가 사용하는 일부 핵심 용어를 정의하는 방식:

"이 사이트에서 솔루션이라는 단어를 보면 선적을 추적하는 데 필요한 모든 제품과 서비스를 찾을 수 있을 것 같은 생각이 듭니다." 특정 도구 집합을 사용하는 방법에 대한 질문 또는 우려 사항

또는 구현의 영향(다음 섹션에서는 참가자의 우려 사항에 대한 몇 가지 예를 보여줍니다). 디자이너는 이러한 응답을 사용하여 그들이 받고 있는 반응이 의도와 일치하는지 또는 다른 접근 방식을 시도해야 하는지 여부를 측정할 수 있습니다. 참가자(및 프로젝트 이해 관계자)는 종종 다른 설계에서 다른 요소를 선택한다는 점을 기억하십시오. "이 부분은 개념 A가 좋고 이 부분은 개념 B가 좋습니다." 이것은 자연스러운 반응이지만 너무 문자 그대로 받아들여서는 안 됩니다. 서로 다른 두 가지 디자인 방향이 부자연스럽게 융합되는 것을 원하지 않습니다. 비주얼 디자이너가 대중적인 요소가 잘 어우러진다고 느끼면 그렇게 하세요. 그러나 그가 "초콜릿과 피클"보다 "초콜릿과 땅콩 버터"가 적다고 말할 여지를 남겨 두십시오. 전반적으로 개념 테스트에 포함된 기능이나 테스트할 수 있는 요소에 대한 엄격하고 빠른 규칙은 없습니다. 오히려 핵심은 테스트에서 어떤 종류의 정보를 얻었는지, 창의성을 저해하지 않고 디자인 결정에 해당 정보가 어떻게 사용되었는지에 대해 프로젝트 팀에 대한 올바른 기대치를 설정했는지 확인하는 것입니다.

사용성 테스트 사용성 테스트는 가장 일반적으로 사용되는 UX 디자인 테스트 방법 중 하나입니다. 또한 UX 디자이너가 아닌 사람들 사이에서 가장 인기가 있기 때문에 회사의 이해 관계자와 프로젝트 팀은 이미 익숙할 수 있습니다. 개념 자체는 우아할 정도로 단순합니다. 우선 순위가 지정된 시리즈를 만듭니다.

작동 테스트

225

사이트에서 작업을 수행하고 일부 사용자가 작업을 완료하고 문제와 성공이 있는 위치를 기록하도록 합니다.

사용성 테스트 대 사용자 승인 테스트 조직의 일부 사람들은 사용성 테스트가 사이트 또는 응용 프로그램의 작업 버전(아마도 베타 버전)이 있을 때 개발 종료 또는 배포 초기에만 발생한다는 오해를 가질 수 있습니다. 이 인상은 나중 단계에서 UAT(User Acceptance Testing)를 수행하는 일반적인 관행과도 관련이 있을 수 있습니다. 이름의 유사성으로 인해 둘 사이에 혼동이 발생할 수 있습니다. 정식 QA 프로세스를 거치는 애플리케이션의 경우 UAT는 테스트 후반 단계 중 하나이며 실제 사용자가 거의 수행하지 않습니다. UAT의 주요 목적은 응용 프로그램이 이해 관계자가 설정한 기능 요구 사항을 충족하는지 여부에 대한 최종 확인 역할을 하는 경우가 많습니다. 또한 참가자가 보고한 오류나 결함을 감지할 수도 있습니다. UAT는 사용성 문제를 강조할 수 있지만 프로젝트에서 문제를 감지하는 유일한 방법으로 의존해서는 안 됩니다. 프로세스 후반에 발생하기 때문에 UAT 피드백을 기반으로 하는 변경은 훨씬 더 비쌉니다. 개발에 많은 시간을 들이기 전에 프로세스 초기에 큰 문제를 파악하는 것이 훨씬 좋습니다. 사용성 테스트는 프로세스 초기에 보다 정확한 성능 데이터를 제공하도록 설계되었습니다.

다음 섹션에서는 접근 방식 선택과 같은 사용성 테스트의 일반적인 단계를 다룹니다. 연구 설계 채용 및 실행 계획 토론 가이드 작성 촉진 결과 분석 및 제시 권장 사항 만들기

226

13장: 사용자와 디자인 테스트

시작하기 전에 프로젝트의 목표를 고려하십시오. 전체적으로 집중력을 유지하는 데 도움이 되지만 접근 방식을 선택하고 테스트를 계획할 때 초기에 특히 유용합니다.

접근 방식의 선택 연구 접근 방식은 종종 양적 또는 질적이라고 설명됩니다. 정량적 연구는 수치 데이터에 중점을 두고 대상 고객에게 높은 신뢰성과 반복성을 가진 결과를 제공하는 것을 목표로 합니다. 그것은 당신이 더 작은 그룹에서 관찰하고 주어진 영역에서 전체 사용자 그룹이 어떻게 반응하는지에 대한 결론을 도출할 수 있도록 해당 그룹(샘플 크기라고 함)에 충분한 수의 사용자를 포함하는 것에 의존합니다. 오류. 전반적으로 테스트 설계 및 분석의 형식을 갖춘 보다 과학적인 연구 접근 방식입니다. 초점은 특히 사이트의 다른 반복, 경쟁사 또는 벤치마크와 비교하여 현재 디자인을 평가하는 데 있습니다. 정량적 연구를 수행한다는 것은 입력 속도, 유사한 사이트에 대한 친숙도 등과 같은 개인차를 설명하기 위해 참가자 수를 더 추가하는 것을 의미합니다. 설문조사는 더 많은 청중에게 확장할 수 있는 데이터 수집 방법의 한 예이며 올바른 질문을 하면 정량적 데이터를 얻을 수 있습니다(설문조사에 대한 자세한 내용은 6장 참조). 반면에 질적 연구는 신뢰 수준과 반복 가능성에 초점을 맞추기보다는 사용자 행동에 대한 맥락과 통찰력을 얻는 데 중점을 둡니다. 디자이너의 발견, 직관 및 상식에 대한 해석을 기반으로 합니다. (6장에서 논의된 상황별 연구는 질적 연구의 한 예입니다.) 질적 접근 방식은 테스트에 대한 개방성을 허용하여 아이디어 탐색 및 통찰력 확보를 촉진합니다. 사용자와의 대화는 성능만큼이나 중요합니다. 초점은 현재 디자인을 개선하는 것입니다. 즉, 아이디어를 생성하기 위해 제시된 것에 대한 통찰력과 반응을 얻는 것입니다. 그렇다면 사용성 테스트는 정량적 방법입니까 아니면 정성적 방법입니까? 이것은 UX 디자인 분야에서 가장 오래 지속되는 논쟁 중 하나입니다. 두 접근 방식 모두 가능하며 유용한 결과를 생성할 수 있습니다. 보다 정량적인 접근 방식을 지지하는 사람들은 다음과 같이 말합니다.

작동 테스트

227

테스트할 수 있는 측정 가능한 벤치마크를 설정할 수 있습니다.

목표(예: 로그아웃 시간 20% 단축 또는 사이트 사용성 문제의 80% 탐지)를 향한 진행 상황을 보여주는 후속 반복에서. 이것은 또한 두 사이트 간의 공식 비교를 수행하거나 특정 사이트를 평가하려는 경우 좋은 접근 방식입니다. 중요할 수 있는 통계적으로 유효한 결과를 제공합니다.

데이터 기반 의사 결정에 의존하는 이해 관계자에게 권장 사항을 방어해야 하는 경우. 개별 UX 디자이너의 편견이 역할을 할 가능성이 적습니다.

점수. 달성한 결과가

전체 사용자 기반에 결과를 반영합니다. 결과를 확인하는 명확한 수치 방법을 제공합니다(예:

동일한 문제가 발생한 사용자 수). 질적 사용성 테스트 지지자들은 다음과 같이 말합니다. 질적 연구는 디자이너의 경험과 공감을 구축합니다.

사용자 중심의 창의적인 솔루션을 홍보합니다. 합리적인 추천을 하기 위해 UX 디자이너의 직관에 크게 의존합니다.

그가 팀에 있는 이유의 큰 부분입니다. 특히 사용성 테스트에서 질적 접근 방식이 부족한 경우가 많습니다.

더 적은 수의 사용자가 필요하고 정성적 연구는 공식적인 과학적 설계 및 분석(예: 통계)에 대한 지식이 필요하지 않기 때문에 정량적 연구보다 더 비쌉니다. 거짓말을 함으로써 양적 연구 결과를 부정확하게 분석하는 것은 매우 쉽습니다.

(그러나 의도치 않게) 데이터를 사용하므로 정량적 접근 방식은 올바르게 수행되지 않으면 정성적 테스트보다 실제로 더 많은 위험을 초래할 수 있습니다. 결과가 수치적으로 검증되지는 않았지만 확인할 수 있습니다.

정보에 근거한 추론을 기반으로 문제의 영향 가능성에 대해 전화를 걸고 사용자 스토리를 사용하여 사례를 구축하는 디자이너입니다. 정성적 사용성 테스트는 공식적인 과학적 방법에 대한 교육을 받지 않은 사람들에게 가장 쉬운 접근 방식이며 디자인에 대한 풍부한 정보 소스를 제공합니다. 이러한 이유로 이 장의 나머지 부분에서는 정성적 테스트 설계에 중점을 둘 것입니다.

228

13장: 사용자와 디자인 테스트

얼마나 많은 사용자가 "충분"합니까? "충분한 사용자 수는 몇 명입니까?" UX 디자이너 그룹에서 그것은 정치 집회에서 종교를 언급하는 것과 같으며 뜨거운 논쟁거리입니다. 또한 연구 설계를 시작할 프레임워크가 필요하기 때문에 피할 수 없는 질문이기도 합니다. 사용하는 접근 방식(양적 또는 질적)과 관련이 있습니다. 짧은 답변을 드리자면, UX 분야에서 가장 합의된 것으로 보이는 Jakob Nielsen이 제공한 지침은 다음과 같습니다. 정량적 테스트의 경우 더 많은 수의 참가자를 계획하십시오. .useit.com/alertbox/quantitative_testing.html). 정성 테스트의 경우 그룹당 5~8명의 사용자가 일반적으로 각 연구 라운드에 충분합니다. 이상적으로는 다른 문제 아래에 "숨겨져 있거나" 우연히 새 디자인에 도입되었을 수 있는 문제를 발견하기 위해 한 번 이상의 조사가 수행됩니다(http://www.useit.com/alertbox/20000319.html 참조).

연구 설계 사용성 테스트를 설계할 때 초점과 범위를 제공하기 위해 초기에 몇 가지 질문에 답해야 합니다. 이것은 종종 사용자 조사 계획이라고 하는 프로젝트 팀 및 주요 이해 관계자를 위해 작성되고 논의된 문서로 제공될 수 있습니다. 계획은 위에서 선택한 접근 방식을 간략하게 설명해야 합니다. 왜 테스트를 하시나요? 하나 이상의 전체 프로젝트 목표를 기반으로 테스트 목표를 설명하는 명확한 설명을 작성하십시오. 디자인 목표의 예와 프로젝트 유형에 따라 어떻게 다른지는 2장을 참조하십시오. 누구를 테스트하고 있습니까? 사용자 모델을 만든 후에는(6장 및 7장 참조) 테스트할 사용자를 결정하기 위한 기준으로 사용할 수 있습니다. 아직 하지 않은 경우 프로젝트 팀 및 관련 이해 관계자와 만나 사용자 그룹의 우선 순위를 지정합니다. 이 정보는 귀하의 심사에 입력됩니다("채용 및 물류"에서 논의됨). 작동 테스트

229

이 섹션에서는 표시할 사용자 그룹과 각 그룹에 포함할 사용자 수도 선택해야 합니다. 무엇을 테스트하고 있습니까? 무엇을 테스트하고 있는지에 대한 질문에는 두 가지 관련 질문이 포함됩니다. 사이트 또는 응용 프로그램을 나타내기 위해 어떤 방법을 사용하고 있습니까? 어떤 작업을 포함할 예정입니까? 이미 리엔지니어링된 앱이 있는 경우 현재 버전에서 전체 테스트를 먼저 실행하여 주요 사용성 문제를 찾을 수 있습니다. 새 디자인 작업을 하는 경우 스케치나 종이 프로토타입(예: 인쇄된 와이어프레임 패키지)을 사용하여 페이지와 같은 새 인터페이스 요소를 나타낼 수 있습니다. 사용자 인터페이스의 이러한 저충실도 데모를 통해 프로젝트 팀 간에 아이디어를 신속하게 생성 및 토론하고 참가자와 함께 아이디어를 빠르게 반복할 수 있습니다(스케치 및 프레이밍에 대한 자세한 내용은 10장 및 11장 참조). 고도의 상호 작용 요소가 포함된 새 디자인을 작업할 때 디자인의 탐색 흐름을 사실적으로 시뮬레이션하는 프로토타입을 만드는 것이 더 나을 수 있지만 본격적인 개발이 시작되기 전에 빠르게 만들 수 있습니다(자세한 내용은 12장 참조). . 프로토타이핑). 추가하는 페이지는 선택한 작업과 밀접한 관련이 있습니다. 프로토타입을 사용하여 사용자와 테스트하려는 경우 중간 페이지 및 대체 경로뿐만 아니라 작업의 기본 페이지를 디자인해야 합니다. 각각을 자세히 설명할 필요는 없지만 사용자가 해당 방향으로 이동하는 경우 응답을 설계해야 합니다. 경우에 따라 특정 경로를 사용할 수 없다고 알리고 사용자에게 이전 페이지로 돌아가서 다시 시도하도록 요청하는 페이지처럼 간단할 수 있습니다. 작업의 세부 사항은 토론 가이드(아래에서 설명)에 들어가지만 포함하는 작업의 유형에 따라 범위가 크게 달라질 수 있으므로 계획 중에 목록의 개요를 작성하는 것이 좋습니다.

230

13장: 사용자와 디자인 테스트

심층 분석 스케치를 사용한 반복적인 디자인 및 테스트에 대한 자세한 내용과 디자인 프로세스의 창의성에 대한 영감을 주는 통찰력을 보려면 Bill Buxton의 스케치 사용자 경험: 올바른 디자인 및 올바른 디자인 얻기(Morgan Kaufmann, 2007)를 참조하십시오. 페이퍼 프로토타이핑 기술에 대한 자세한 내용은 Carolyn Snyder의 Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces(Morgan Kaufmann, 2003)를 참조하십시오.

목록이 너무 길고 우선 순위를 정하는 방법을 잘 모르는 경우 고려해야 할 몇 가지 우선 순위는 다음과 같습니다. 디자인이 일부 기존 규칙을 위반하는 영역. 당신은

"장바구니"가 아니라 "선물가방"이라고 부르나요? 사용자에게 명확한지 확인하는 것이 좋습니다. 계획 결정이 정치적으로 부과되는 영역. 당신은 가질 수 있습니다

특정 디자인 방향이 옳다는 강한 느낌이 들지만 이해 관계자나 다른 프로젝트 팀 구성원 간에 많은 의견 차이가 있음을 알고 있습니다. 보는 것은 믿는 것입니다. 사용성 문제가 분실과 같은 심각한 결과를 초래할 수 있는 영역

판매 또는 최악의 경우 생명 손실(약물 투약과 관련된 의료 응용 프로그램이 이에 대한 좋은 예입니다). 다음으로 사용자가 각 작업을 완료하려고 할 때 수집하려는 정보를 정의합니다. 어떤 정보를 수집합니까? 우리는 일반적으로 더 작은 측정 세트를 갖는 질적 사용성 테스트에 중점을 둡니다. 대부분의 경우 사용자가 직면할 수 있는 문제, 사용자가 겪고 있는 불만 수준 및 특정 문제의 심각성을 이해하려고 합니다. 예를 들어 게시된 스토리가 돌이킬 수 없는 손실을 초래하는 간헐적인 문제(모든 사용자가 경험하지는 않음)가 있을 수 있습니다. 그것은 확실히 귀하의 보고서에서 매우 우려되는 문제가 될 것입니다!

작동 테스트

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개월 등을 위해 다시 한 번 창의력을 발휘하고 개성에 집중하는 것이 좋습니다. 사용자 그룹에 동기를 부여하는 것은 무엇입니까?

스크리닝 스크리닝은 잠재적 참가자를 예약하기 전에 사용할 수 있는 일종의 설문지입니다. 대표 사용자의 정의와 일치하는지 확인합니다. 질문의 목적은 응답자가 테스트 중인 기능의 현재 사용자인지 확인하는 것입니다.

또는 가능성 있는 미래의 사용자 하나 이상의 사용자 그룹에 대한 적합성을 정의합니다. 해당 사용자 그룹의 참가자를 적절하게 혼합하도록 돕습니다.

236

13장: 사용자와 디자인 테스트

편향된 경험이 있을 수 있는 특정 응답자 제외

결과 참가자가 도착하기 전에 알아야 할 가장 중요한 정보 수집

(선택 사항) 스크리너에는 참가자를 수락(동의하는 경우)하거나 통화를 종료하는 방법(동의하지 않는 경우)에 대한 지침과 함께 채용 담당자가 전화로 읽을 수 있는 소개 스크립트가 포함되어야 합니다. 심사의 최종 사용자는 심사를 위해 온라인 양식을 사용하는 경우 참가자 또는 잠재적 참가자를 모집하는 사람들입니다. 둘 다 가능하지만 일반적으로 양식이나 이메일을 통해 이해 당사자 목록을 수집한 다음 전화로 선별하는 것이 가장 좋습니다. 왜? 불행히도 사람들은 일반적으로 누군가에게 직접 답변할 때보다 종이에 잘못된 정보를 제공하는 것이 더 쉽고 자격이 없더라도 누군가가 설문 조사에 참여하려고 시도하는 것이 드문 일이 아닙니다. 특히 보상이라면! 귀하의 검사는 또한 귀하의 결과에 영향을 미칠 수 있는 정보를 가진 사람들을 걸러내야 합니다. 예를 들어 일반적인 질문은 응답자가 일반적으로 연구에 너무 익숙하여 진정한 반응을 줄 수 없기 때문에 시장 조사에서 일하는지 여부입니다. 설계 정보 공유가 우려되는 경우 경쟁업체에서 일하는 사람들을 선별할 수도 있습니다. 다음은 B2B 온라인 주문 신청서를 심사할 때 볼 수 있는 질문의 예입니다. 이 경우 온라인에서 사용하고 구매하는 것을 좋아하고 혼자 할 가능성이 높은 사용자 그룹을 대상으로 합니다. 일부 질문은 참가자의 안팎을 가려내기 위한 것이고 다른 질문(예: 질문 4)은 자격을 갖춘 참가자를 올바른 사용자 그룹에 배치하는 데 더 적합합니다. 1. 귀하는 어느 연령대에 속하십니까? [18세 이상 혼합] a. 18세 미만

그만해요

b.18-24 c. 25–34 라. 35–44 e. 45–54 f. 55 이상

작동 테스트

237

2. 집에서 인터넷을 얼마나 자주 사용합니까? 절대

그만해요

b. 한 달에 한 번 미만

그만해요

씨. 한 달에 몇 번 d. 적어도 일주일에 한 번 e. 일주일에 여러 번 f. 하루에 한 번 또는 더 자주 3. 마지막으로 온라인에서 제품을 구입한 것이 언제입니까? a.지난달 b.1~3개월 전 c. 3-6개월 전 d. 6~12개월 전

그만해요

e. 12개월 이상 전

그만해요

f. 온라인에서 개인적으로 구매한 적이 없습니다.

그만해요

4. pseudocorporation.com을 마지막으로 방문한 것이 언제입니까? [그룹 A는 자주 사용하지 않거나 사용하지 않습니다. 그룹 B는 자주 사용하는 사용자]

238

가. 나는 사이트를 방문한 적이 없다.

그룹 A 확인

나. 최근 한 달 동안

그룹 B 확인

씨. 1~3개월 전

그룹 B 확인

디. 3~6개월 전

그룹 B 확인

e. 6-12개월 전

A 또는 B 확인

f. 12개월 이상 전

그룹 A 확인

13장: 사용자와 디자인 테스트

당신은 해고되었습니다. 해고는 거칠게 들리는 단어입니다. 응답자가 테스트에 적합하지 않기 때문에 통화를 종료해야 한다는 의미입니다. 응답자가 이것에 대해 기분 나빠하는 것을 원하지 않을 뿐만 아니라 적합하지 않다는 것을 알고 후속 질문을 함으로써 시간을 낭비하고 싶지도 않습니다. 이를 처리하는 방법에는 여러 가지가 있습니다. 좋아하는 것 중 하나는 단순히 그가 자격이 있는 그룹이 이미 채워졌다고 말하고 그가 다른 테스트에 관심이 있으면 나중에 그에게 연락할 수 있는지 묻는 것입니다.

공간 및 장비 계획 이 단계에서는 원격 또는 대면 테스트 여부와 각 참가자에게 필요한 시간을 알 수 있습니다. 결정해야 할 몇 가지 다른 사항은 다음과 같습니다. 테스트 장소: 관찰실이 있는 임대 공간, 회사 회의실 또는 잠재 사용자가 있는 곳? 두세 사람이 편안하게 들어갈 수 있는 조용한 장소를 설계하고 컴퓨터를 테스트하십시오. 퍼실리테이터 외에 필요한 직원: 예를 들어 테스트 중 메모의 로그 데이터가 있으면 시간을 절약하고 정확도를 높일 수 있습니다. 다른 가능성으로는 인사 담당자(들어오는 참가자를 맞이하고, 사람들이 기다리는 동안 설문지를 나눠주고, 시험장 안팎으로 참가자를 에스코트하는 것)과 시험 중에 무슨 일이 생기면 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 디자인 작업은 누군가의 프로젝트 계획의 작업 중 어딘가에서 끝나고 나머지 팀에게 작업 제품이 전달되면 항상 다른 프로젝트와 혼동됩니다. 그 문을 닫고 새로운 것을 시작할 때죠? 매우 잘못되었습니다! 최상의 사용자 경험을 설계하기 위해 여전히 많은 일을 할 수 있습니다.

시각적 디자인, 개발 및 QA 경우에 따라 프로젝트 기반 작업 제품을 받는 디자인 또는 개발 팀과 원활하게 작업할 수 있습니다. 때로는 다운스트림 파트너가 귀하에게 의존하여 질문에 답하고 피드백을 제공하며 일부 설계 개념을 도와줍니다. (이것은 프로토타이핑처럼 들릴 수도 있습니다!) 이러한 작업 환경은 이미 UX 디자인을 수용하고 있으며 팀은 아마도 이러한 컨설팅 작업을 수행할 시간을 제공할 선견지명을 가지고 있었을 것입니다. 그러나 많은 조직에서 사용자 경험 디자이너, 정보 설계자, 인터랙션 디자이너 등의 역할은 여전히 매우 생소합니다. 이러한 역할을 관리하는 것이 불분명할 수 있으며 얼마나 헌신해야 하는지 결정하는 것은 사용자 경험 디자인을 완전히 이해하지 못하는 사람에게 떨어질 수 있습니다. 귀하의 임무는 지속적으로 참여하는 방법을 찾는 것일 수 있습니다.

248

14장: 전환: 설계에서 개발까지

다음은 몇 가지 제안 사항입니다. 1. 이 책을 구입하십시오. 2. 부끄러워하지 마십시오. 3. 이 장의 나머지 부분을 읽고 참여하고 유용할 수 있는 기회를 찾으십시오. 4. 약혼을 요청하고 귀하의 요청을 변호할 준비를 하십시오. 시각 디자인 또는 개발 팀이 회사와 프로젝트의 왕이라는 것을 알게 될 다른 경우도 있으며 따라가기가 어려울 수 있습니다. 작업을 평가하고 규정 준수를 보장하기 위해 벽을 허무는 자신을 발견할 수 있습니다. 항상 그런 것은 아니지만 발생합니다. Behavior(www.behaviordesign.com)의 공동 설립자인 Christopher Fahey는 이 문제를 극복하는 데 익숙합니다. 그는 다음과 같은 조언을 합니다. 일부 조직은 엄격하게 구획화되어 있습니다. 초기 디자인 단계 이후에 프로젝트 개발에 계속 참여하려면 능동적으로 행동해야 하며 시각 디자인 및 개발 팀에 피드백과 수정 사항을 제공할 기회를 요구해야 합니다. 그들은 종종 당신에게 거기에 있어달라고 부탁할 생각조차 하지 않습니다. 이상적으로는 프로젝트의 계획 및 예산 책정 단계에서 이 작업을 수행합니다. 그렇지 않은 경우 나중에 개발하는 동안 디자인이 저하되지 않도록 문자 그대로 서비스를 제공해야 할 수 있습니다. 한 가지 트릭은 비공식적으로라도 QA 팀에 추가되도록 요청하는 것입니다. . 그런 다음 개발자가 매일 검색하는 동일한 버그 수정 대기열에 비판과 편차를 추가할 수 있습니다.

물론 많은 프로젝트에는 QA 팀의 사치가 없습니다. 완벽한 세상에서 모든 프로젝트에는 다음과 같은 팀이 있습니다. 그러나 실제로 품질 보증이 항상 가능한 것은 아닙니다. 개발자가 개발하면서 스스로 QA를 수행하는 경우가 있습니다. 움츠러들게 만드는 것 외에도, 이것을 알면 개발자와 함께 일하기 위해 더 열심히 노력해야 합니다.

시각적 디자인, 개발 및 품질 보증

249

협상 기술 협상 기술은 사용자 경험 디자이너로서의 역할에서 중요한 부분이 될 수 있습니다. 비주얼 디자이너 및 개발자와 같은 다운스트림 파트너는 작업이 사용자 경험의 주요 부분에 어떤 영향을 미치는지 이해하지 못한 채 작업을 자유롭게 변경할 수 있습니다. 누군가 "할 수 없다"고 말하는 경우 계획 B를 제시할 준비가 되어 있어야 합니다. 좋은 협상 기술은 디자인 결정(수행한 연구를 기반으로 해야 함)을 방어하는 데 도움이 됩니다. 사용자 경험이 가능하다는 것을 다른 사람들에게 확신시키십시오. 또는 이러한 기술은 파트너와 협력하여 가능한 한 많은 사람의 요구를 충족하는 만족스러운 플랜 B를 만드는 데 도움이 됩니다. 협상에 대한 자세한 내용은 Roger Fisher, William L. Ury 및 Bruce Patton(Penguin, 1991)의 Get to Yes: Negotiating Agreement Without Give In(양보하지 않고 협상) 및 Dave Gray(XPLANE Corp.)의 Selling to No. VP of No.를 참조하십시오. , 2003).

많은 소기업에서는 특히 그렇습니다. QA는 사치입니다. Ascend Realty Solutions(www .ascendrealtysolutions.com)의 사장 겸 최고 개발 책임자인 Troy Lucht는 품질 보증은 모두가 하지만 특히 개발자가 수행한다고 말합니다. 모든 사람이 기여하려고 노력하고 원하지만 테스트 스크립트를 만들기 위한 리소스가 없으면 개발이 마지막 순간까지 완료될 때 사람들에게 무엇을 테스트해야 하는지 알려주는 것이 불가능할 수 있습니다. 대부분의 경우 저희 하우스 디자이너는 저만큼 앱을 잘 아는 사람이기 때문에 더 많은 정보에 입각한 피드백을 줄 수 있습니다. 믹스에 사용자 경험 디자이너를 추가하면 소규모 팀에 실제로 추가됩니다.

사용자 경험 디자인 작업 제품에 테스트 스크립트 생성이 포함되지 않을 수 있지만 경우에 따라 모든 요소가 고려되고 정의된 모든 클릭 유도 문안이 올바르게 작동하는지 확인하기 위해 생성한 프레임워크 및 주석을 테스트할 수 있습니다. 이 상황이 완벽하지는 않지만 품질 보증이 없을 때 유용할 수 있는 접근 방식입니다. 여기서 가장 중요한 것은 작업 결과물을 번역하고 데이터 전송을 완료했다고 해서 사용자 경험 디자인이 끝나는 것이 아니라는 것입니다. 귀하의 역할은 일시적으로 더 많은 컨설팅일 수 있지만 아직 완료되지 않았습니다.

250

14장: 전환: 설계에서 개발까지

사용자와 디자인 테스트 (다시) 사용자 테스트를 이미 수행하지 않았습니까? 이 질문에 예라고 답할 수 있기를 바라지만 항상 그런 것은 아닙니다. 불행하게도, 최종적으로 설계되고 개발된 사이트를 출시 전에 실제 사용자와 함께 테스트하기 위한 이 테스트 단계도 그렇게 하지 않습니다. 이를 통해 웹사이트를 마지막으로 한 번 살펴보고 QA 테스트 중에 간과했을 수 있는 마지막 순간의 버그와 오류를 찾을 수 있습니다. 대상 고객을 식별한 후에는 위험이 높거나 사이트의 이전 반복에 문제가 있을 수 있는 모든 시나리오에서 웹 사이트를 테스트할 수 있습니다. 이 테스트 실행은 사이트가 활성화될 준비가 되었는지 확인하는 데 필요한 정보를 제공할 수 있습니다. 이 테스트 중에 중요한 문제가 발견되면 업데이트하고 다시 테스트하는 것이 중요할 수 있습니다.

10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … "당신이 그것을 만들면 그들은 올 것입니다. ..." 그 이론은 많이 언급되고 거의 자주 반박됩니다. 가능한 한 가장 아름답고, 즐겁고, 사용하기 쉬운 앱을 만들고, 세상에 출시하고, 두 달이 걸립니다. 사용자 채택은 대상 사용자 기반이 사이트나 앱을 사용하는 정도를 의미합니다. SEO 모범 사례(8장)를 따르면 일부 채택 문제를 피할 수 있습니다. 사용자가 새 사이트를 찾도록 합니다. 또한 사용자 채택은 좋은 사용자 경험 디자인이 프로젝트 종료 후에도 중단되지 않거나 작업 중인 프로젝트로 제한됨을 의미합니다.마케팅, 고객 지원, PR, 및 교육 팀은 사용자 채택에 종종 영향을 미치는 세 가지 요소를 지원하여 원활한 롤아웃과 사이트 또는 프로젝트에 대한 사용자 기반을 보장합니다. 개인적 관심

10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … GO!

251

지원 네트워크의 의견

각각에 대해 차례로 자세히 살펴보겠습니다.

개인 혜택 사용자가 묻는 가장 중요한 질문 중 하나는 "나에게 도움이 되는 것이 무엇입니까?"입니다. 사이트가 훌륭하더라도 특정 유형의 사용자(또는 식별한 특정 인물)에게 고유한 이점을 신속하게 설명할 수 없다면 사용자 참여를 유도하는 데 어려움을 겪을 수 있습니다. 이점 중 일부는 간단합니다. "이 카메라 기능을 사용하면 버튼 하나만 누르면 온라인 계정으로 사진을 보낼 수 있습니다." 일부는 간접적입니다. "이 작업표 도구를 사용하면 회사에서 각 프로젝트에 소요되는 시간을 보다 쉽게 추적할 수 있습니다." 사용자에 대해 알아보는 데 귀중한 시간을 할애했습니다. 이제 이 정보를 사용하여 마케팅 부서에서 메시지를 맞춤화하도록 돕습니다.

지원 사용자가 사이트에 대한 도움이 필요할 때 어떻게 얻습니까? 우수한 사용자 경험 디자인이 제공하고자 하는 상황별 도움말 외에도 이 질문에 대한 답변에는 교육 및 고객 지원도 포함됩니다. 사용자가 온라인 교육보다 강의실 교육에 더 잘 반응할 것이라고 생각하십니까? 일부 사용자는 교육을 건너뛰고 사이트 자체에서 필요한 모든 것을 얻을 것으로 기대합니까? 실시간 채팅이 고객 지원 측면에서 사용자에게 중요한 옵션입니까, 아니면 전화 및 이메일 지원에 만족합니까? 지원 업무는 힘들고 사용자를 이해하면 고객 지원 및 교육 부서를 효과적으로 지원하는 데 도움이 됩니다.

252

14장: 전환: 설계에서 개발까지

네트워크 의견 입소문이 가장 큰 영향을 미치는 요인입니다. 대상 사용자 그룹에 대한 고객 회사 및 현재 웹 사이트의 평판은 어떻습니까? 이에 대한 대답이 긍정적이라고 해도 노력이 필요하지 않다는 의미는 아닙니다. 평판 유지는 항상 중요합니다. 다음 섹션으로 넘어가기 위해 긍정적인 대답을 변명으로 사용하지 마십시오. 유지 관리 노력이 중요할 필요는 없지만 손상된 평판을 복구하는 데 필요한 노력은 엄청날 수 있습니다. 약간의 TLC는 먼 길을 갈 수 있으므로 계속 읽으십시오. 대답이 '아니요'인 경우 인식을 개선하기 위해 진지한 노력을 기울여야 합니다. 사용자 커뮤니티에 연락하여 인플루언서가 누구인지, 그들이 어떻게 소통하고 청중에게 어떤 영향을 미치는지 알아낸 다음 그들을 참여시켜야 할 수도 있습니다. 소셜 네트워킹을 통해 사용자를 참여시키고 고객, 비즈니스 및 웹 사이트에 대한 의견에 영향을 미치는 방법에는 여러 가지가 있습니다. 고객이 이러한 커뮤니티에 참여할 기회를 식별하고 긍정적인 방향으로 이끌 수 있도록 도와주세요. 세 가지 요인이 모두 충족되고 여전히 활용도가 낮은 경우 경쟁업체가 사용자 요구를 충족하기 위해 수행하는 방법과 작업을 고려하십시오. 제품이나 사이트를 어떻게 차별화할 수 있습니까?

출시 후 활동 우리는 흥미로운 시대에 살고 있습니다. 많은 회사가 "베타" 모드에서 자체 또는 제품을 출시합니다. 베타 릴리스는 일반적으로 필터링되지 않은 실제 사용자가 웹 사이트를 실시간 테스트하여 버그, 오류, 충돌 또는 기타 문제를 식별하는 데 도움이 되는 대상임을 의미합니다. 한때 베타 버전은 일반적으로 개발자에게만 제공되었지만 이제는 전체 사용자 커뮤니티에 베타 버전을 공개하는 것이 일반적인 관행이 되었습니다. 베타 단계 동안 사용자가 가질 수 있는 문제를 기록하고 보고하는 통신 방법을 정의해야 합니다. 모든 종류의 시스템 오작동을 기록하고 프로젝트에 제공해야 합니다.

접근 후 조치

253

팀. 또한 사용자가 발생하는 모든 문제를 적절한 프로젝트 팀 구성원에게 보고할 수 있는 메커니즘이 있어야 합니다. 이런 종류의 커뮤니케이션이 이루어지지 않는다면, 즉 UX 디자이너, 비주얼 디자이너, 개발자가 빠듯하고 빠르게 진행되는 베타 단계에서 어떤 일이 자주 일어나는지 알지 못한다면 사용자가 많은 노력을 기울이지 않고도 웹 사이트를 업데이트하고 사용자를 위해 위치를 변경할 수 있습니다. 전략을 구현했습니다.

출시 후 분석 사이트를 시작한 후 가장 먼저 해야 할 일 중 하나는 사이트 사용에 대한 데이터 수집을 시작하는 것입니다. 가장 좋은 소스는 사이트의 로그 파일입니다. 불행히도 UX 디자이너는 이 정보를 받거나 확인하는 목록의 맨 위에 있지 않을 수 있으므로 사이트 호스팅 담당자를 찾아 협상 기술을 사용하십시오. 웹사이트 분석을 통해 사이트 방문자에 대한 통찰력을 얻을 수 있습니다. 무엇보다도 사이트의 신규 방문자가 누구인지 알 수 있습니다. 사이트의 반복 방문자는 누구입니까? 페이지 보기 수 페이지 보기 기간 페이지 깊이 방문자가 사이트를 떠나는 위치(페이지) 세션 기간 기간 광고 노출의 사용된 검색어, 결과 및 반복 검색

이 정보는 사이트에서 문제 영역을 강조 표시하여 사용자에게 문제가 있는 위치를 이해하는 데 도움이 될 수 있습니다. 분석이 무미건조하고 숫자가 무거워 보일 수 있지만 데이터와 통찰력은 출시 후 테스트를 수행할 때 적절한 질문을 공식화하는 데 도움이 될 것입니다. 참고 웹 사이트 분석에 대해 자세히 알아보려면 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 기능 충돌에 대한 선호도 그래프 16160 사용성 테스트에서 99–100 244 민첩한 접근 방식 개요 63–64 AIGA용 리소스 65 웹사이트 51 Ajax, 문제 132 Align Interactive 웹사이트 217 대체 속성 포함, 139 ACSI(American Customer Satisfaction Index) 103 분석 도구의 가용성4 254 라벨링 이점 187 도구의 개요 189–190 및 와이어프레임 186–187, 193–194, 201 Aquent Talent Agency 웹 사이트 51 Arrows and Connectors Defined 170 Ascend Reality Solutions Atonsh 웹 사이트, 2516ghansk. .com, 명제 47–48을 포함하여 128개의 가정에 대해 검색이 수행되었습니다.

속성 비교 90 Axure RP 프로토타이핑 도구 기능 215 웹사이트 우선 순위 지정 및 정의 167

89–91

B Babyhold 웹사이트 118 BabyNames 웹사이트 118 균형, UX 디자인 달성 6-7 Balsamiq Mockups 프로토타이핑 도구, 216 Baty, Steve 12, 95 Behavior 웹사이트 기능 249 베타 릴리스, 정의 253-254 청구 비율, 검은색 모자 정의 130-131 대 흰색 모자 141–142 블로그 기능, 사이트맵 166, 191 Blue Flavor 웹사이트 167 Blueprint CSS 웹사이트 167 바디 랭귀지, 대상 그룹에서 해석 106 봇, 설명 129 브랜드 존재 웹사이트 설명 13 기능의 11가지 예 12–13 목표 13– for 14- 1세 브랜드 전략가/수탁자, 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 아이디어 청취 813 협상 간 813 우선순위 지정 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 133 콜라주, 소액 금융 사례 223–224 의사소통, 우선 순위 지정의 중요성 160개 기업의 SWOT 분석 적용 61–62 경쟁업체 비교 61 기업 문화의 계층 구조 36–37 물류의 역사 34–37

258

색인

보상, 사용자 그룹 235명, 경쟁자 241명을 할당하고 61개의 개념 연구를 비교합니다. 참조 시각적 템플릿 예 222-224 잠재적 함정 222 의도 221 정의된 조건 170 우선 순위 지정 중 충돌 관리 158-162 연결 171 커넥터 및 화살표 부주의 정의 170 합의 우선 순위 지정,16 5 콘텐츠 모범 사례 138-139 135-136 최신 유지 138의 중요성 138 콘텐츠 제작자, 188 CMS 프레임워크, 콘텐츠 매트릭스 133–134 개요, 173 콘텐츠 소스 사이트에 적용된 번호 매기기 시스템, 108 콘텐츠 전략에서 비즈니스 분석가 사용 28 사용과 관련된 17 작업에 대한 16-17 목표의 11가지 특성 설명, 맥락 디자인의 역할 28-29, 맥락적 탐구를 위한 자원 101 설명 92 프로세스 98-99에서 얻은 정보 99-101의 친화성 그래프 사용 99-101 카피라이터, 역할 29-30 Coroflot 웹사이트 51 제안을 포함한 비용 및 수수료(추가 요금) 50 크롤러 기능 131 Creative Commons 웹사이트 50 설명 132를 통한 마스킹 감지 131

D 파선은 170개의 결정 지점, 정의된 169개의 정의 및 설계 단계, 제안 48-49를 포함하여 145개의 산출물 간에 중복되는 조건을 묘사합니다. 브랜드 존재 사이트의 제품 디자인 목표 13 콘텐츠 소스 사이트 17 전자 상거래 사이트 19 온라인 교육 응용 프로그램 20 마케팅 캠페인 사이트 15–16 설정 10 소셜 네트워킹 응용 프로그램 21 작업 기반 응용 프로그램 18–19 디자인 오류 참조 페이지 번호 매기기 부족 173–174 잘못 정렬된 개체 172 잘못 배치된 텍스트 172–173 엉성한 연결 171 고르지 않게 배치된 항목 172 계획, 개선 227 개발자 프로토타이핑 217 와이어프레임 사용 188 개발 옹호자 및 커뮤니케이션 옹호자가 비즈니스 및 사용자 따르기 155 심지어 158 관심사 154 목표 및 책임 157 요구 사항 상속 157–158 156 개발 팀 158 기능 참여, 디지털 자산에 대한 피드백 제공 24 9, 138 디지털 경험을 위한 최적화, 5-6 디지털 프로토타입 디자인. 청중 프로토타이핑 208 HTML 대 WYSIWYG 편집기 209–214 타임라인에 필요한 리소스 208 와이어프레임 대 현실적인 프로토타입 207–209 Digital Web Magazine 웹 사이트 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 아이디어 및 시각화 포함 146–147 160–162 피드백 메커니즘 충돌 관리, 219 수수료 및 비용 프로토타이핑(부록), 제안 포함 50 Finck, Nick 167 Fireworks Tool, CS4 프로토타이핑 도구, CS4 215 –216개의 Flash 기능, 130–132개의 Flash 및 Flash Catalyst 프로토타이핑 도구 기능, 216개의 Flash 컨텐츠 기능, 정적 레이어에 포함 131 대상 그룹 토론 형식 105–106 설명 93 바디 랭귀지 해석 106 조정 프로세스 107 프로세스 105–107 소액 금융에 사용 예 223에서 바닥글 104 –105, 디자인 196 사용

색인

259

바닥글 링크, 링크 인기도 140 프런트엔드 개발자의 역할, 31 파이낸싱 모델, 소액 금융 신청 222

G Garrett, Jesse James 168 Global Cruises, Google 분석 도구용 홈페이지 디자인 195–201 24 PageRank 시스템 139 웹마스터를 위한 품질 지침 142 128 그리드로 검색, 응용 프로그램에서 172 그룹 토론 형식 105–106 설명 93 해석적 바디 랭귀지 106 중재 107 프로세스 105–107은 104–105를 사용하는 예에서 소액 금융 223을 사용합니다.

H Hadden, Jon 217–219 제목/탐색, 195 휴리스틱 분석을 가능하게 하는 제목 메타 디자인 137 수집을 통한 요구 사항의 이점 73 계층 구조의 71단계에 대한 70–71 이론적 근거 72–73 회사 프로젝트에 미치는 영향 36–37 Hinton, Andrew 177 Hofstede, Geert 36 홈페이지 디자인 192 Global Cruises용 디자인 195-201 와이어프레임 디자인 197-200 템플릿 예 194 HTML 프로토타입 212 링크 인기도 140 HTML 프로토타입 분해 코드 213-214 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 도메인 이름을 포함한 키워드 동작 134 명명 규칙 136 URL 구조에서 사용될 때 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 마케팅 캠페인 사이트 설명 11가지 예 14가지 기능 14가지 목표 15–16 to market, 관계 구축 26–27 Melzer, James 182 Messagefirst person 사례 연구 115 웹 사이트 219 메타 설명 태그 설명 137 메타 키워드 태그 설명 136-137 스팸 142 in meta 설명 필드, 136–137 -방법론 가용성, 62 마이크로파이낸스의 중요성, 정의됨 222 마이크로사이트, 정의됨 15 Microsoft PowerPoint 사이트 167 Microsoft Visio 웹사이트 167 오류 페이지 번호 지정 부족 173-174 잘못 정렬된 텍스트 173-174 고르지 않게 배치된 표적 172 수정된 접근, 170 MSN을 설명하는 64–65 이동, 검색 128

N 이름, 페르소나 118 협상, 250 네트워크 의견 기술, 사용자 채택에 미치는 영향 253 Nicolle 페르소나, 설명 115–116 Nielsen, Jakob 71 nofollow 링크 속성, 140 noindex 설명 필드 사용, 설명 137

SWOT 분석을 적용한 O 목표 61–62 fuzzy vs. fixed 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 p. 참조 사이트 복제 142–143 정의 168 개별 인덱싱 137–138 페이지 스택 정의 169 종이와 연필, 와이어프레임에 사용 189–190, 201 "종이 문화", 이해 37

색인

261

종이 프로토타입 206–207 209 탐색 개념에 대한 217–218 HTML의 예 218 수동적 관찰, 정의된 99 경로, 작업 흐름에서 식별 180 제안서 포함 52–53 펜과 종이, 프레임 189–20190, 페르소나 나이 118 사용 약력 119 사례 연구 115 정의 113 교육 수준 120 고객을 위한 시작 또는 트리거 포인트 120 정보 검색 114 위치에 포함된 정보에 대한 정보 116 위치 119 사용 극대화 125 모바일 편안함 수준 121, 고객의 사용 동기, 브랜드 또는 프로젝트 121 명명 118 직업 119 오프라인 활동 120 온라인 활동 120 개요 기본 시트 122 개인 인용문 120 사진 정보 117–118 정당성 113–114 급여 또는 등급 120 대상 청중 사회적 안락 수준 1121 대상 청중 그룹 124 개인의 대상 청중 124 기술적 편안함 수준 121 유형 113 사용자 목표 121 사진 소스, 개인용 획득 117 포스트잇 노트, 친화성 다이어그램에 사용 161 출판 후 계획 테스트 255. 테스트 참조 ; 사용성 테스트 단계 전력 거리, 정의 36 PowerPoint 프로토타이핑 도구, 기능, 214

262

색인

PowerPoint 웹사이트 167 PR(PageRank), 설명 139–140 PURITE 프로세스 섹션 준비 45 가격 책정, 프로젝트 구조화 51–52 사용성 테스트에서 우선순위 프로세스 244–245 역할 균형 조정 154 촉진 150–15146 프로세스 중 커뮤니케이션 관리 충돌 158–162, 예 181 – 제품 182개, 성공 5. 프로젝트 폭포수 63에 대한 제안서 45–47 수정 64–65 단계 62–63 포함 63, 프로젝트 관리의 정렬 부족 160, 와이어프레임 사용 188 프로젝트 목표에서 SWOT 분석 적용 61–62 퍼지 대 고정 58–60 중요성 57–58 UX 디자이너의 60–62 측정 58, 60 제안서 포함 프로젝트 개요 44–45 제안서 포함 프로젝트 가격 책정 51–52 프로젝트 요구 사항 , 관련된 단계 69 프로젝트 자금 제공자, 75 프로젝트 그룹 정의, 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 최종 219 WYP 찾기 209–214 예제 217–219 피드백 메커니즘 219 목표 219 반복 테스트 217 개발자 확보 217 현실적인 프로토타입 20 205–206 문서 205–206–207 프로토타이핑 도구 개요의 디지털 프로토타이핑 모범 사례도 참조하십시오. 4 비전 215 PURITE 프로세스 45–46

Q 정성적 연구, 사용성 테스트 애플리케이션 227–229 정성적 사용성 테스트, 데이터 수집 231–232 품질 보증 문서, 번호 지정 시스템 애플리케이션 174 품질 보증 팀 옵션 250 참가자용 249

품질 보증, 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 상대 경로, PURITE 프로세스 사용 46 요구 사항 HTML 프로토타입 213 렌더링 섹션, 정의 66 요구 사항 단축 74 비즈니스 요구 사항 참조 프로세스, 격려 74 연구, 사용성 테스트 계획 229–233 연구 기법 카드 정렬 93, 107–110 컨텍스트 설문조사 92, 98–101 대상 그룹 93, 104–107 사람들 121 설문조사 9–12 104 사용성 테스트 93, 110–111 사용자 인터뷰 92, 95–9 7 리소스. 참조 웹 사이트 리소스 친화도 다이어그램 161 민첩한 접근 방식 65 분석 254 바디 랭귀지 106 컨텍스트 디자인 101 Google 128 HTML(HyperText Markup Language) 214

색인

263

리소스(계속) 반복 설계 231 협상 250 프로토타이핑 접근 방식 217 소셜 네트워킹 애플리케이션 20 도구 167 사용성 테스트 231 책임 영역, 제안서 포함 75–76 수정 내역 요약 44 우선 순위 지정 프로세스에서 균형 역할 154 병합 2146-294

S 샘플 크기, 정의된 227개의 작업 범위, 제안서의 스크리너 47명, 사용성 테스트의 236-239명. 질문 스크립팅된 탐색, 132–133 검색 동작 관련 문제, 135 SEO 시작 가이드 129 검색 엔진 이해, 129 검색 결과 진화, 매월 142 검색에 영향, 137 Seiden을 가능하게 하는 128 섹션 제목과 관련된 통계, Josh 113 SEO(검색 엔진 최적화) 129 SEO 방법에 대한 127–128 리소스의 134 중요성에 대한 127 UX 영향 정의, 흰색 모자 대 검은 모자 141–142 SEO 전문가, 188 서명 및 승인이 있는 와이어프레임 사용, 제안서 53–54 사이트 분석, 도구 블로그 활동 166, 191 최신 패션 177 정의 166에 대한 175–176의 24 사이트맵 고급 예

264

색인

11개의 위치를 식별하는 178개의 슬롯 유형이 있는 작업 흐름을 사용하는 108에 대한 카드 정렬을 사용하는 138을 사용하는 작업 흐름 166과 비교하여 174개의 간단한 예에서 번호 매기기 구조를 생략합니다. 페이지 색인 생성 131 작성 29–30 6페이지 템플릿 190 Slingthought 웹사이트 217 소셜 네트워킹 앱 설명 20 디자인 목표 21 사회보장국 인기 아기 이름 118 소프트웨어 사용성 측정 인벤토리(SUMI) 103 SOW(작업 명세서), 54 –55 공간 콘텐츠 사용성 테스트 설계 239 메타 키워드가 포함된 스팸 142 Spencer, Donna 17, 109 스파이더 설명 129 Spool, Jared 125 SRA International Inc. 웹 사이트 182 이해관계자 정의 75 모임 76–77 듣기 81개의 정적 레이어, 131개의 스티커 포인트에 Flash 콘텐츠 포함, 유사성 다이어그램 161 Stock.XCHNG 웹사이트 117 스토리보드, 147–150 강점 및 약점 프로세스, 이해 61 SUMI(소프트웨어 사용성 측정 인벤토리) 103 – 지원 네트워크, 구축 32 33. 참조 UX -디자인 역할 연구 설명 92 개요 101 프로세스 102–104 vs. 사용자 인터뷰 102

SWF객체, 131개의 수영 레인, 182–184 SWOT 분석의 예, 프로젝트 목표 61–62에 적합

T 태그. 113을 설명하는 대상 사용자를 위한 콘텐츠 설명 필드를 참조하십시오. 번호 매기기 시스템을 적용하는 사용자 작업 흐름도 참조하십시오. 애플리케이션 사이트는 비즈니스 분석가를 사용하여 18-19세를 위한 11가지 기능 및 목표를 설명했습니다. 28 Tatum, Keith 217-218 Taylor, Dave 214 기술 구조, 31 모델 빌더, 190 철골 사용 긴장, 변호사 간의 균형 154-162 해고, 사용 사용성 테스트 239 테스트 자료, 사용성 테스트를 위한 작성 241 PURITE 프로세스 테스트 섹션 46 테스트, 사용성 대 사용자 수용 226. 출시 후 디자인 테스트도 참조하십시오. 사용성 테스트 단계 사용성 테스트를 위한 텍스트 마무리 239–241 172–173 사이트의 잘못된 기사 배치 29–30 제안서 포함 제목 페이지 42–43 제목 태그, HTML 프로토타입 213 도구 사용, 167–168 가용성

U UAT(User Acceptance Testing), 목적 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-245 네트워킹 252 개인 관심사 252 지원 252 사용자 옹호 150–151 건설 네트워크 32–33 대 비즈니스 및 개발 촉진 155는 154 사용자 속성, 사용자 행동 비교 990–91에 적용됩니다. , 우리는 227개의 사용자 경험(UX)에 대한 컨텍스트를 얻습니다. 목록 속성 87을 정의하는 UX(사용자 경험) 사용자 그룹 참조 87–89 사용자 인터페이스 엔지니어링 웹 사이트 125 사용자 인터뷰 설명 92 인터뷰 팁 97 프로세스 95–96 대 설문 조사 102

색인

265

사용자 모델, 디자인 91 사용자 연구 93–94 111 디자인 수행 94 기술 수행 단계 86 92 사용자 연구 계획, 229–233 사용자 연구원 개발, 23–25 사용자 만족도 역할 233 측정 도구 103 사용성 분류 테스트 245 평가 233 사용자 성공 , 232~233명의 사용자를 정의합니다. 사용성 테스트를 위해 전화를 거는 대상 사용자를 참조하십시오. 229 식별 88–89 유형의 와이어프레임 사용 188 UX(사용자 경험) 디지털 측면 6 SEO에 미치는 영향 134 UX 디자인, 3가지 UX 디자인 역할 정의. 지원 네트워크 브랜드 전략가/수탁자 26–27 비즈니스 분석가 27–28 선택 31 콘텐츠 전략가 28–29 카피라이터 29–30 프런트 엔드 개발자 31 정보 설계자 22–23 인터랙션 디자이너 23 25 사용자 리서치 책임 23–24 비주얼 디자이너 30 –31 UX 디자이너와 다른 역할의 균형 248–249 공감 156 프로젝트 목표에 대한 기여 60–62 조직 7–8 우선 순위 지정 역할 151 특성 6–7

V 검증, 초기 191가지 가치 제안을 찾아 15일 발표

266

색인

비전 프로토타이핑 도구, 215 Visio 웹 사이트 167 시각 디자인 팀 기능, 금속 프레임워크 제작에 참여하는 249 시각 디자이너에게 피드백 제공. 174 모델에 번호 매기기 시스템을 적용하는 개념 연구 참조 224 와이어프레임 200–201 시각적 용어집 정의 용어 170 커넥터 및 화살표 170 결정 지점 169 페이지 168–169 페이지 스택 169 시각화 및 관념화 기능 145–140 비즈니스 요구 사항 공유 –81

W WAMMI(웹사이트 분석 및 측정 인벤토리) 103 Warfel, Todd Zaki 115, 124, 217, 219 수정된 폭포수 방식 63명의 웹마스터로부터 65단계, 142명의 웹마스터/사이트 소유자를 위한 품질 지침(웹사이트 분석 및 사이트 소유자 측정 지침) (WWW 데이터 analysis1AM29) 웹 사이트 리소스 28. 참조 리소스 ACSI(American Customer Satisfaction Index) 103 Adaptive Path 168 Adobe Illustrator 167 Adobe InDesign 167 AIGA 51 Align Interactive 217 Aquent 탤런트 에이전시 51 Ascend Reality Solutions 250 Axure 8 Babyh 1orvimes117 9

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 1811 콘텐츠 코딩 , Jon 219 휴리스틱 분석 71 HTML 프로토타입 214 Illustrator 167 이미지 맵 213–214 InDesign 167 Information Architecture Institute 51, 167 정보 검색 17 jQuery 214 키워드 연구 도구 135 마케팅 캠페인 사이트 Microsoft Message116최초 마케팅 캠페인 사이트 16 Microsoft 이름 118 OmniGraffle 167 OpenOffice Draw 167 Optimalsort 109 개인 유형 113 사진 리소스 117 파워포인트 167 무작위 이름 생성기 118 검색 엔진 최적화 시작 가이드 129 SEO(검색 엔진 최적화) 143 SlingThought 217 사회 보장국 인기 아기 이름 118 SRA International Inc. 182 SUMI(소프트웨어 측정 인벤토리) 103 도구 167 사용성 테스트 스크립트 240 Usability.gov 240

사용자 인터페이스 디자인 125 사용자 만족도 측정 도구 103 UX 디자인 접근법 24 UX 조직 8 UX 연구 95 비전 167 WAMMI(웹사이트 분석 및 측정 인벤토리) 103 웹마스터/사이트 소유자를 위한 가이드 129 WebSort 102 WebTrends! 사용자 인터페이스 라이브러리 웹 사이트 214 WebSort 웹 사이트 109 WebTrends 웹 사이트 24 흰색 모자 대 검은 모자 141–142 화이트보드, 스토리보드(149개 와이어프레임 및 주석 포함) 186–187, 193–194, 201 210 비교 200 만들기 189, 198–199 반복 연습으로 홈 페이지 디자인 197–200 201 고객 피드백 받기 192–193 프레젠테이션 개요 186–187 202–203 대 현실적인 프로토타입 207, 207–209 201 "생각하는 장치" , 198개의 도구 189–188, 시각 디자인 분야의 사용자 190명 및 정의된 고용 작업 200–201개 49개의 워크플로우 비즈니스 요구 사항을 생성하는 149개의 스프레드시트 스토리보드 153개의 WYSIWYG 편집자 프로토타이핑–21420

Y 야후, 128 야후! 사용자 인터페이스 라이브러리 웹사이트 214

색인

267

이 책을 45일 동안 무료로 온라인으로 만나보세요! 무료 Safari Books Online 평가판에 등록하여 수천 가지 이상의 책에 액세스하십시오! 이 책을 구입하면 45일 동안 Safari Books Online에 온라인으로 즉시 액세스할 수 있습니다! 거기에 있는 동안 Safari Books Online의 주문형 디지털 라이브러리와 무료 평가판 제안(별도의 가입 프로세스)을 확인하십시오. Safari Books Online 구독자는 수천 권의 기술, 창의적 및 비즈니스 서적, 교육용 비디오 및 세계 유수 출판사의 기사를 이용할 수 있습니다.

www.peachpit.com/safarienabled를 방문하여 코드 FJGSLZG를 입력하여 오늘 사용해 보십시오.

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

References