여기에 가혹한 진실이 있습니다. 저는 지금까지 디자인 경력을 통해 1,000개 이상의 포트폴리오를 검토했는데 그 중 90%를 선형 디자인 프로세스 때문에 거절했습니다. "선형 설계 프로세스"란 항상 같은 내용을 읽는 진부한 사례 연구를 의미합니다. 디자이너는 문제를 인지하고, 사용자 인터뷰를 진행하고, 사용자 페르소나를 만들고, 스케치를 거쳐 목업과 와이어프레임을 진행하고, 시각적 디자인을 통해 모든 것을 아름답게 만들고, 프로토타입을 만들고, 5명의 사용자와 함께 테스트했습니다. 모든 것이 완벽해서 디자인 시스템이 아닌 스타일 가이드인 디자인 시스템도 만들었습니다. 하지만 그들은 그것을 '디자인 시스템'이라고 부릅니다. 왜냐하면 그것이 유행이고 채용 담당자들의 키워드이기 때문입니다. ???? 잠깐만요! 나의 새로운 온라인 코스인 UX Buddy는 디자이너가 UX 포트폴리오를 만들고, UX/디자인이 성숙한 회사에서 멋진 UX 디자인 일자리를 찾고 얻을 수 있도록 도와줍니다. 이제 라이브가 시작되었으며 등록은 며칠 더 열려 있습니다. 확인 해봐! 이는 마치 온라인에서 구매하고 싶은 제품을 찾는데 별 5개 리뷰만 있는 것과 같습니다. 모든 것이 완벽하다고 표시되면 신뢰성을 잃습니다. 리뷰가 가짜인가요? 제가 귀하의 틀에 박힌 포트폴리오를 검토할 때도 마찬가지입니다. 모든 것이 완벽할 때 나는 그것이 모두 가짜인지 궁금합니다. 90%는 제가 검토한 많은 포트폴리오를 바탕으로 한 추정치입니다. 정확한 수치가 무엇인지는 모르겠지만 높은 수치입니다. 대부분의 UX 및 제품 디자인 포트폴리오에는 동일한 두 가지 사례 연구가 있지만 세부 사항만 약간 다릅니다. 나는 몇 달 전에 LinkedIn에 이 게시물의 훨씬 짧은 버전을 게시했고 그것이 입소문을 탔습니다. 경험 많은 디자이너들은 다음과 같이 동의했습니다. 많은 사례 연구는 학교 숙제처럼 나에게 읽어주었습니다. 그들은 교과서에 따라 대답과 과정이 무엇인지 알고 있었기 때문에 그에 맞게 이야기를 구성했습니다. 실제로는 지적했듯이 결코 매끄럽고 선형적이지 않습니다. 지저분하고 루프스럽습니다. 당신이 일을 잘하고 있다면, 처음 시작할 때 예상했던 것과 같은 결과를 원격으로 얻는 경우는 거의 없습니다. ( 원천 ) 페르소나, 접착 메모지 벽, 인터뷰 중인 고객 사진, 노트북 스케치 등을 안내하는 또 다른 사례 연구를 본다면… 나는 미친 듯이 정신을 잃고 머리카락을 뽑을 것입니다. ( 원천 ) 그러한 포트폴리오를 검토할 때 나는 그 뒤에 있는 디자이너가 경험이 없거나 디자인에 대한 열정이 부족하거나 단순히 자신의 작업의 가치를 전달할 수 없다는 생각을 하지 않을 수 없습니다. 때로는 위의 사항이 모두 사실일 때도 있지만, 하나만 해당하더라도 디자인이 성숙한 회사에서 거절하기에 충분합니다. 이것은 두 번째 요점으로 이어집니다. 틀에 박힌 사례 연구가 포함된 얕은 포트폴리오를 통해 UX 분야에 취업할 수 있습니다. 하지만 디자인을 완전히 이해하지 못하고 디자인이 미성숙한 회사에서 일할 가능성이 높습니다. 지루한 디자인 작업에 꼼짝 못하게 되고 작업의 질이 결코 향상되지 않아 포트폴리오에 더 좋은 것이 없기 때문에 경력이 정체됩니다. 당신은 루프에 갇히게됩니다. 내가 디자이너의 90%를 고용할 수 없다고 말할 때, 내 말은 그들이 디자인이 성숙한 회사에 의해 즉시 거절당할 것이라는 뜻입니다. 반면, 성숙한 디자인 회사는 창의적인 방법으로 문제를 해결할 수 있는 디자이너를 찾습니다. UX 부트 캠프에서 배운 디자인 프로세스를 활용하여 직면한 모든 문제를 해결하는 것만으로는 충분하지 않습니다. 내가 디자이너의 90%를 고용할 수 없다고 말할 때, 내 말은 그들이 이런 종류의 회사에 의해 즉시 거절당할 것이라는 뜻입니다 . 우리는 디자이너들에게 디자인 프로세스와 그들의 사례 연구를 어떻게 구성해야 하는지 가르치지만, 지저분하고 비선형적인 프로세스인 실제로 디자인이 작동하는 방식은 아닙니다. 이 결론에 따르면 디자이너의 프로세스와 작업 표현 방식에 있어 두 가지 주요 문제가 있습니다. 디자이너의 프로세스는 실제로 선형적입니다. 디자이너의 프로세스는 선형적이지 않지만 사례 연구는 선형적이고 완벽해야 한다고 생각합니다. 두 가지를 자세히 살펴보겠습니다. 디자이너의 프로세스는 실제로 선형적입니다. 디자이너와의 인터뷰와 대화를 바탕으로 내 가정은 이들 중 상대적으로 적은 양이 실제로 선형이라는 것입니다. 나머지 부분은 완벽해 보이도록 장식되어 있습니다. 디자이너가 채용 관리자가 보고 싶어하는 것이 바로 이것이라고 생각하기 때문입니다. 아니면 단순히 사례 연구가 해피엔딩으로 끝나는 완벽하고 선형적인 이야기여야 한다고 생각합니다. 그림 1 : 위의 UX 디자인 프로세스에 대한 단순화된 설명( 소스 )과 아래의 NNG에 의한 더 나은 설명( 소스 ). 이는 아마도 연공서열(또는 경험 부족)과 일치할 것입니다. 저는 디자이너의 20-30%가 실제로 선형 디자인 프로세스를 사용하는 것으로 추정합니다. ( 왜 디자이너가 2023년을 종료하는지에 대한 내 연구 에서 중급 또는 중급으로 확인된 사람의 수입니다 .) 나는 그런 디자이너들을 목격했다. UI의 상호 작용을 다시 디자인해야 한다고 말합니다. 작은 작업이지만 사용자 인터뷰 수행 및 페르소나 생성에 대해 이야기하기 시작할 것입니다. 디자인 프로세스에는 시작도 끝도 없습니다. 이는 디자인 프로세스의 어느 단계에서나 시작할 수 있으며(따라서 번호를 매기는 것은 오해의 소지가 있습니다. 첨부된 이미지의 상단 예) 실제로는 끝나지 않습니다(따라서 순환이어야 합니다, 하단 예). 이는 또한 무언가를 하라는 요청을 받을 때마다 "프로세스"의 시작 부분으로 돌아갈 필요가 없다는 것을 의미합니다. 진정한 선형 설계 프로세스는 설계자가 모든 권한을 갖는다는 것을 의미합니다. Eduardo Hernandez는 Death to the Double Diamond 에서 이것을 아름답게 설명합니다 . 영향을 미치는 요인을 더 많이 제어할수록 문제 해결 프로세스를 더 예측할 수 있습니다. 영향을 미치는 요인에 대한 통제력이 약할수록 문제 해결 프로세스의 예측 가능성도 낮아집니다. 그래서 디자인 프로세스 로 자주 거론되는 더블 다이아몬드 디자인 프로세스도 현실을 반영하지 못하고 있다. 이는 디자이너가 추구하지만 거의 달성하지 못하는 완벽한 이상입니다. 디자이너는 영향을 미치는 요소를 그다지 통제할 수 없기 때문에 완벽하고 틀에 박힌 사례 연구를 읽는 디자인 관리자는 이중 다이아몬드 프로세스를 사용하더라도 그것이 가짜라는 것을 즉시 알 수 있습니다. 이중 다이아몬드를 사용하는 것은 목적, 연속성 및 맥락이 부족합니다. 왜냐하면 디자이너가 예상치 못한 새로운 질문이나 상황에 반응하지 않기 때문입니다. 오히려 이중 다이아몬드는 디자이너가 종종 갖고 있지 않은 질문에 대한 답변을 제공한다고 Hernandez는 설명합니다. 이러한 디자이너를 위한 권장사항 그렇다면 경험이 부족한 디자이너로서 당신은 무엇을 해야 할까요? 당신은 프로세스를 사용하는 법을 배웠지만 이제는 그것을 폐기하라고 말하고 있습니다. 내 권장 사항은 다음과 같습니다. 경력 초기에는 자기주장을 하는 것과 학습하는 사고방식 사이에서 균형을 찾으려고 노력하십시오. 이제 장밋빛 안경을 벗고 마음을 열고 디자이너가 된다는 것이 무엇을 의미하는지 현실을 직시할 때입니다. 의사소통 및 리더십 능력을 키우는 데 집중하세요. 수석 디자이너가 아니더라도 모든 디자이너 역할에는 어느 정도의 리더십이 필요합니다. 다른 이해관계자들과 관계를 구축하면 그들은 일을 완수하는 데 중요한 역할을 합니다. 디자인은 소통과 협업을 통해 이루어집니다. 마지막으로, 디자인 프로세스에 대한 독단적이고 이상주의적인 관점을 버리고 그것이 얼마나 유연하고 지저분하며 아름다운지 계속 배우십시오. 디자이너들은 사례 연구가 선형적이고 완벽해야 한다고 생각합니다. 제가 링크드인에 그 바이럴 게시물을 올렸을 때 가장 놀랐던 것 중 하나는 디자이너들이 “디자인 과정이 지저분하고 혼란스러운 것은 사실이지만 사례 연구는 선형적이어야 하지 않겠습니까?”라고 말하는 디자이너들의 댓글이었습니다. 예는 다음과 같습니다. 그러나 사례 연구를 작성할 때는 논리적 서술에 따라 슬라이드의 선형 순서를 제시해야 합니다. 이야기를 전달하려면 논리적으로 이루어져야 합니다. 최근에 UX 사례 연구를 완료했는데 그 과정이 꽤 혼란스러웠습니다. UX 연구를 두 번이나 하고, 사용자 스토리를 작성하고, 계속해서 수정을 해야 했습니다. 하지만 사례 연구에서는 이를 선형적인 방식으로 제시해야 했습니다. ( 원천 ) 또 다른 의견은 이러한 유형의 사고에 대해 더 많은 정보를 제공합니다. 솔직히 선형 스토리가 생성하고 소비하기가 더 쉽기 때문에, 특히 채용 담당자/관리자가 훑어볼 수 있는 항목을 만들 때, 거기에 넣지 않은 수많은 장애물, 반복 및 앞뒤로의 반복이 있을 것입니다. ( 원천 ) 사례 연구는 선형적이어야 하고 모든 복잡한 세부 사항을 제외해야 한다고 누가 말했습니까? 세부 사항은 흥미로운 내용이며 디자인 관리자가 디자인 프로세스를 평가하는 방법입니다. 거의 모든 사람이 틀에 박힌 디자인 프로세스의 기본 사항을 배우고 단계를 완료할 수 있습니다. 훌륭한 디자이너는 팀 내 디자인의 리더이자 훌륭한 협력자이며, 올바른 솔루션을 찾는 데 필요한 사항을 전달하기 위해 올바른 도구를 조정하고 사용하는 방법을 알고 있습니다. 항상 같은 일을 하고 위험과 불확실성을 피하는 틀에 박힌 디자이너들과는 달리 그들은 손을 더럽히는 것을 두려워하지 않습니다. 이것이 바로 디자인 매니저가 보고 싶어하는 것이고, 이것이 당신의 포트폴리오에 넣어야 할 것입니다. 모니카의 이야기 저는 UX Buddy 멘토십 프로그램 의 일환으로 지난 몇 주 동안 Monica를 멘토링해 왔습니다 . 그녀는 몇 가지 사례 연구를 작성하고 나에게 검토를 요청했습니다. 나는 이 문제를 즉시 발견했습니다. 사례 연구에서 그녀는 문제에 직면했고 결국 두 가지 가능한 해결책을 생각해 냈습니다. 하나는 기존 UI에 대한 소소한 변화였고, 다른 하나는 완전히 달랐습니다. 그녀는 사소한 변경을 진행했지만 사례 연구에서는 그 이유를 설명하지 못했습니다. 나중에 그녀는 솔루션이 계획대로 작동하지 않았고 새로운 문제가 발생했다고 썼습니다. 그들은 다른 솔루션을 선택했고 그 솔루션은 효과가 있었습니다. 그게 다야! 맥락이 충분하지 않습니다! 그녀는 자신이 더 낫다고 생각하는 다른 해결책을 추진할 자신감이 부족하다는 점을 결코 설명하지 않았습니다. 그녀는 왜 그들이 해결책을 선택했는지, 그것이 실패했을 때 어떻게 용기를 내어 문제를 스스로 해결하고 다른 방법을 추진했는지에 대한 세부 사항을 제외했습니다. 그녀는 UI 변경을 최소화하려고 노력하는 대신 유익한 방식으로 경험에 의도적인 마찰을 추가했습니다. 이러한 마찰은 사용자에게 새로운 UI를 설명하는 데 도움이 되었으며 사용자 테스트를 통해 훨씬 더 잘 작동한다는 것이 입증되었습니다. 그녀는 사례 연구에서 그 모든 것을 설명하지 못했습니다. 그녀는 뭔가가 성공할 때까지 하나의 잠재적인 솔루션에서 다른 솔루션으로 이동하는 선형적인 이야기로 읽을 정도로 단순화했습니다. 그녀는 자신의 약점 중 하나에 직면했고 그로 인해 훨씬 ​​더 강한 디자이너가 된 흥미로운 이야기를 말하지 못했습니다. 왜 디자이너들은 선형적이고 완벽한 것이 디자인 관리자가 원하는 것이라고 생각합니까? 나는 대다수의 디자이너, 즉 70-80%가 이 선형 구조에 맞게 사례 연구를 단순화한다고 믿습니다. 이것이 디자이너에게 이것이 올바른 방법이라고 확신시키는 요소는 다음과 같습니다. 일반 포트폴리오, 사례 연구 템플릿 및 "체크리스트" 그들은 독자가 선형 프로세스를 사용하기가 더 쉽다고 생각합니다. 그들은 채용 담당자와 디자인 관리자가 보고 싶어하는 것이라고 생각합니다(아마도 템플릿 때문일 것입니다). 따라서 대다수의 디자이너는 지저분한 작업을 선형적이고 단순화된 묘사로 리버스 엔지니어링해야 한다고 믿게 됩니다. 당신은하지 않습니다! 이야기는 선형적일 수 있지만 이야기의 주인공은 다양한 도전에 직면하고 괴물을 물리치기 위해 적응해야 합니다. Slava Shestopalov는 디자인 포트폴리오를 구성하는 10가지 팁 에서 디자인은 선형이 아니므로 사례 연구도 마찬가지라고 설명합니다. 이미 눈치채셨겠지만 저는 '이상적인' 디자인 프로세스에 대해 언급하지 않습니다. 단순한 이유는 그것이 존재하지 않기 때문입니다. 디자인은 결코 선형적이지 않으며 모든 프로젝트는 독특합니다. 요점은 포트폴리오의 시작부터 최종 결과까지의 경로를 보여주고 설명하는 것입니다. 문제를 해결하는 방법은 다음과 같습니다. 지저분한 세부정보를 포함하고 스토리를 전달하세요. 여기에서 제가 자막에서 약속한 문제를 해결하게 됩니다. 판에 박힌 사례 연구가 기사와 용에 관한 이야기라면 다음과 같습니다. 나는 용이 마을을 위협하고 그들이 그를 죽인 기사에게 기꺼이 막대한 양의 금을 지불했다는 사실을 알게 되었습니다. 나는 마을 사람들에게 동굴이 어디에 있는지, 어떻게 죽이는지 물었다. 나는 용의 동굴을 발견하고 모래에 자갈을 깔아 계획을 세우고 용을 찾았습니다. 그것은 나에게 불을 뱉었지만 나는 그것을 방패로 튕겨내고 칼을 용에게 찔러 죽었습니다. 나는 금을 모았고, 행복한 날들을 보냈습니다. 기사를 디자이너로, 마을 사람을 사용자로, 자갈을 포스트잇으로, 용을 디자인 문제로, 방패를 디자인 프로세스로, 검을 Figma로 바꾸면 전형적인 쿠키 커터 UX 사례 연구가 있습니다. 그러나 Figma의 아름다운 프로토타입이 있어야만 디자인 문제가 해결될 수 없는 것처럼 단순히 칼을 휘두르는 것만으로는 어떤 용도 죽일 수 없습니다. Figma의 아름다운 프로토타입이 있어야만 디자인 문제가 해결될 수 없는 것처럼 간단한 칼을 휘두르는 것만으로는 어떤 용도 죽일 수 없습니다. 사례 연구를 이야기처럼 읽어야 하는 이유는 무엇입니까? 위의 쿠키 커터 기사와 용 이야기는 지루합니다. 해피엔딩이어서가 아니라 기사가 실질적인 도전에 직면하지 않기 때문에 용을 죽이기 위해 적응하거나 배울 필요가 없습니다. 그분은 전능하시며 그분이 하시는 일은 무엇이든 완벽하게 잘 이루어집니다. 거의 이야기가 아닙니다. 실제로 용을 죽이는 기사는 끔찍한 위험에 직면해야 합니다. 용이 불을 뱉자마자 방패가 너무 뜨거워져서 들고 다닐 수 없기 때문에 그는 아마도 방패를 떨어뜨려야 할 것입니다(이상주의적인 디자인 과정을 포기함). 그는 첫 번째 시도에서 용에 검을 찔러 넣을 만큼 가까이 접근하지 못했습니다(너무 빨리 Figma에서 아름다운 시각적 디자인을 만드는 것은 의미가 없습니다). 그는 후퇴하고, 자기 회의에 직면하고, 용기를 모으고, 배우고, 적응하고, 새로운 계획을 세우고, 다시 시도하고, 뭔가 효과가 있을 때까지 반복해야 했습니다. 이것이 기사를 흥미롭고 인간적으로 만드는 세부 사항입니다. 당신은 그와 공감할 수 있습니다. 포트폴리오를 검토할 때 디자인 관리자도 마찬가지입니다. 세부적인 내용과 잘 안 됐던 점, 문제를 극복하기 위해 어떻게 적응했는지 이야기를 해주시면 디자인 매니저가 공감해 주실 거예요. 사례 연구를 읽는 데 걸리는 5분 동안 그들은 당신의 입장이 될 것입니다. 그것은 그들에게 비슷한 문제가 있었던 모든 시간을 상기시켜 줄 것이며 디자이너로서 당신과 당신의 노력에 감사하게 될 것입니다. 이야기는 우리가 다른 사람들에 대해 배우고, 그들과 그들의 상황에 대한 이해와 공감을 찾는 데 도움을 주는 능력을 가지고 있습니다. — 케이트 허스트 스토리텔링은 디자이너에게 요구되는 핵심 소프트 스킬 중 하나이기도 합니다( 출처 ). 논리는 다음과 같습니다. 케이트 허스트(Kate Hurst)는 스토리텔링과 이야기 창조의 중요성 에서 스토리텔링이 우리가 다른 사람에 대해 배우고, 그들과 그들의 상황에 대한 이해와 공감을 찾는 데 도움이 된다고 설명합니다. 즉, 당신이 당신의 디자인 작업에 대해 좋은 이야기를 할 수 있다면, 제가 당신을 고용한 후에 당신의 스토리텔링 기술을 활용하여 디자인의 가치를 전달할 수도 있다는 뜻입니다. 스토리가 선형적이라는 주장은 부분적으로 사실입니다. 스토리는 거의 항상 스토리 아크라고도 불리는 동일한 구조를 따릅니다. 설명, 선동적 사건, 액션, 클라이막스, 결론의 다섯 가지 주요 요소로 구성됩니다. 그렇다고 해서 이야기 속의 주인공이 전능하고 어떤 도전에도 직면하지 않는다는 의미는 아닙니다. 이는 사례 연구를 작성하기 위해 구조를 사용할 수 있지만 여전히 모든 지저분한 세부 사항을 포함할 수 있음을 의미합니다. 제가 추천하는 구조는 STAR 프레임워크, 즉 Situation(상황), Task(과제), Action(행동), Result(결과)입니다. 이는 디자인 프로세스와 스토리 아크와 잘 일치합니다. 작업 부분( 그림 2 )에서 모든 복잡한 세부 사항을 설명할 수 있고 설명해야 합니다. 그림 2 : STAR 프레임워크와 결합된 스토리 아크를 사용하여 UX 사례 연구에서 스토리를 전달하세요. 다음은 STAR 프레임워크를 사용하는 방법과 모든 것을 완벽해 보일 정도로 장식하지 않고 작업을 현실적으로 더 잘 표현하는 방법에 대한 몇 가지 팁입니다. 누구나 당신이 말하는 내용을 이해할 수 있도록 충분한 맥락을 추가하십시오(내부자의 관점은 없습니다). 동료가 아닌 친구에게 이야기하듯이 이야기를 들려주세요. STAR 프레임워크 사용 상황 : 문제에 대해 어떻게 알게 되었고, 왜 문제가 되었으며, 누구와 함께 일했습니까? 목표는 무엇이었나요? 해결해야 할 문제나 목표를 선택한 이유는 무엇입니까? Task : 당신은 무엇을 하기로 결정했나요? 왜? 어떻게 결정하셨나요? 당신의 기대는 무엇이었나요? 액션 : 얼마나 많은 잠재적인 솔루션을 생각해냈나요? 탐구할 수 있는 솔루션으로 우선순위를 정한 항목은 몇 개입니까? 어떻게 작동하고 생겼나요? 솔루션을 어떻게 검증했나요? 어느 쪽이 승리했나요? 왜? 당신을 놀라게 한 점과 그 이유는 무엇입니까? 무엇이 예상대로 작동하지 않았으며 그 이유는 무엇입니까? 그때 당신은 무엇을 했나요? 무엇을 배웠고, 어떻게 적응했나요? 이제 무엇을 다르게 하시겠습니까? 다른 이해관계자들과 교류할 때 어떤 어려움에 직면했습니까? 어떻게 극복하셨나요? 결과 : 결국 솔루션은 어떻게 수행되었나요? 성공을 어떻게 측정했나요? 그것으로부터 무엇을 배웠나요? 무엇을 다르게 하시겠습니까? 인쇄 가능한 사례 연구 프레임워크 받기 UX 사례 연구에서 좋은 스토리를 전달하는 방법을 설명하는 예제가 포함된 이 프레임워크의 인쇄 가능한 버전을 다운로드할 수 있습니다. 여기에서 다운로드 → 결론: 디자인의 상품화가 탓인가? UX 채용이 문제인가요? 채용 담당자가 포트폴리오를 보고 "필수" 부분을 확인하시나요? 부분적으로 그렇습니다. 디자이너 모집을 전문으로 하는 사람은 극히 일부에 불과합니다. 물론 그렇지 않은 사람들도 후보자가 확인할 수 있는 체크리스트를 갖게 될 것입니다. 그러나 반면에 디자이너는 채용 담당자와 디자인 관리자 모두를 만족시킬 수 있는 사례 연구를 작성할 수 있습니다 . 세부 사항을 추가하고 무언가를 배웠기 때문에 프로세스에서 몇 단계 뒤로 물러나야 했던 방법을 설명한다고 해서 사례 연구의 일반적인 구조를 완전히 포기해야 한다는 의미는 아닙니다. 대부분의 디자이너가 실패하는 가장 중요한 조언은 다음과 같습니다. 사례 연구와 포트폴리오에 관해서는 노력을 기울이십시오. 단지 템플릿을 사용하지 말고 이미지를 몇 개 넣고 자리 표시자 텍스트를 자신만의 텍스트로 바꾸고 그게 전부라고 생각하세요. 귀하의 포트폴리오는 귀하가 디자인하는 방식을 반영하기도 합니다. 잘못 디자인된 포트폴리오와 잘못 작성된 틀에 박힌 사례 연구를 본다면 나는 그것을 당신의 디자인 기술이 반영된 것으로 볼 것입니다. 그러나 무엇보다도 후배 디자이너들은 디자인 작업의 유연성과 지저분함에 대해 배워야 하며, 숙련된 디자이너들은 자신이 무능해 보인다고 생각하기 때문에 자신의 작업의 지저분한 세부 사항을 숨기는 일을 멈춰야 합니다. 그 반대가 사실입니다. 사례 연구에서는 진부한 환상이 아닌 실제 이야기를 들려줍니다.