by
Sep 10. 2023
#14 Break the Frame!
2023년 36주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/57
다음 회고 ☞ https://brunch.co.kr/@327roy/60
노트
#1 Break the Frame!
#제로베이스사고 #객관
최근 회사에서 기술지원팀으로 유입된 VOC를 해소하기 위한 기능 기획을 진행하며 느낀 점이 있다. 바로 '틀에 갇힌 사고'에 대한 것.
1. 고객의 기술지원을 담당하고 있는 동료들로부터 개선 요청사항이 인입되었다. 인터뷰를 통해 맥락을 파악하고 문제를 재정의한 후 최소 스펙(기능 요구사항)을 도출해 냈다.
2. 기획을 완료하고, 컨셉 디자인을 진행했다. 나는 여전히 공수를 줄이는 방법에 갇혀있다. 그래서 기존에 만들어 놓은 프로세스와 UI 컴포넌트만을 활용하여 이를 해결하기 위한 기능을 기획했다.
3. 그렇게 장단점을 서로 트레이드오프하는 대안이 2개 탄생했다. (A안의 장점은 B안의 단점, A안의 단점은 B안의 장점)둘 모두 최선의 대안이 아니라는 생각이 들었다.
4. 개발자들과 디자이너에게 기획리뷰를 일찍 요청했고, 30분 동안 8명의 멤버들과 아이디어 발산을 하는 시간을 가졌다.
5. 추가적인 대안인 'A-1안, B-1안'을 도출했다.
6. A, B안에 너무 갇혀있다는 생각이 드는 찰나, 디자이너가 C안을 가지고 왔다. A안, B안의 단점을 최소화했음에도 불구하고 기능 요구사항을 잘 해결할 수 있는 대안이었다. (심지어 별건으로 분리해 뒀던 기능 개선을 위한 VOC도 함께 해결할 수 있다.)
7. C안은 서비스 내에 컴포넌트는 이미 개발되어 있지만, 기능이 필요한 화면(프로시스) 내에서는 사용된 적 없는 컴포넌트다. 따라서 추가 개발이 필요하였고 프론트 개발 담당자에게 확인을 요청했다.
8. 문제 없다는 답변을 받았고, C안으로 기능을 개발할 예정이다.
결론은 최선의 방법을 찾았다.
그리고 얻은 두 가지 레슨런
1. 사고가 틀에 갇히는 경우가 많다.
- 이것이 꼭 나쁜 것은 아니다. 사고를 틀에 가두는 것은 '반복적이고 변하지 않는 업무'를 할 때 좋다. 사고를 틀에 가둘 때 '휴리스틱'을 최대로 발휘할 수 있기 때문이다. (A 상황이 발생했다. → A' 방법으로 대처한다. B상황이 발생했다. → B' 방법으로 대처한다.'와 같은 것들). 따라서 외부 요인들이 제한적일 때는 사고를 틀에 가두는 것이 효율적이기도 하다.
- 하지만 '제작을 위한 사고'를 할 때는 이러한 휴리스틱을 경계해야 한다. 충분히 더 좋은 방법이 있음에도 하던 대로 하게 되기 때문이다. 이렇게 관성에서 벗어나지 못하는 상태는 제작자와 주변 사람들의 창의적인 사고를 제한한다.
- 실제로 이번 기획을 할 때 기존 UX와 UI를 고려해야 하는 것은 맞지만, 내 사고는 그 기능이 들어갈 화면에 종속되어 버렸다.
※ 휴리스틱이란 의미를 사전에서 찾아보면 '시간이나 정보가 불충분하여 합리적인 판단을 할 수 없거나, 굳이 체계적이고 합리적인 판단을 할 필요가 없는 상황에서 신속하게 사용하는 어림짐작의 기술'로 표현된다.
2. 그래서 우리는 '환기'가 필요하다.
- 내 사고가 틀에 갇혀 있다는 것을 외부 자극 없이 스스로 깨닫는 것은 쉽지 않다. 가령 '내가 어떻게 숨을 쉬고 있는가'를 남이 말하기 전까지 생각해 보기 힘든 것과 같다.
- 그래서 우리는 '환기'가 필요하다. 더 효과적인 결과를 생각하기 위해 '주관'에서 빠져나와야 한다.
- 그리고 이는 '객관'으로 해결할 수 있다. 가령 '동료 리뷰', '페르소나' 등 여러 방법을 활용할 수 있다.
- 이때 중요하다고 생각하는 것은 설명을 하거나 역지사지를 할 때 '내가 그렇게 만든 이유'를 배제하는 것이다. 예를 들어 "타깃이 어떤 문제를 가지고 그래서 무엇을 해결해야 한다. 나는 이를 이것으로 해결하려고 한다."라고 설명할 때, '나는 이를 어떻게 해결할 것이다.'라는 내 생각을 제외하고 동료에게 설명(혹은 페르소나에 몰입) 해야 한다.
결국 나는 이번 기획에서는 동료 리뷰를 통해 이를 해결했다고 생각한다.
신경 써야 하는 것은 '1) 리뷰 시 동료들을 내 주관에 가두지 않도록 조심할 것과 2) 꼭 단체 리뷰가 필요한지 판단할 수 있는 기준을 세우는 것'이라고 생각한다. 불명확한 리뷰, 미팅은 모두의 시간을 뺐는 악마라는 것을 잊으면 안 된다.
#2 맥킨지식 제로베이스 사고
#제로베이스사고 #맥킨지
아래는 신입 시절 현재의 멘토님이 추천해 주신 책, '맥킨지식 사고와 기술'에서 다룬 내용이다.
[맥킨지식 제로베이스 사고]
A. 사고를 자신의 좁은 틀 속에 가두지 않는다.
① 제로베이스 사고는 문자 그대로, 기존의 틀에서 벗어나 백지상태에서 생각하고 사고하는 법
② 제로베이스 사고에 방해가 되는 것은 '기존 관념’ (그중에서도 가장 방해가 되는 것은 자기 자신)
③ 종래의 틀 이외의 가능성에 도전하는 제로베이스 사고는 적극적 정신(Positive Mentality)과 상통함
B. 고객(Client)의 입장에서 가치를 생각한다.
→ 생각한 것을 실행에 옮기는 단계에서도 어김없이 ‘고객의 입장에서 가치’를 생각한 후에 관철 시킴
C. 시대가 제로베이스 사고를 요구한다.
→ 정보의 유동화가 가속적으로 진행되는 현재의 상황에서 규제나 기존의 범위를 벗어나 ‘소비자에게 있어서 가치는 무엇인가’를 기반으로 Business의 의미를 다시 생각하는 것이 점점 더 중요해지고 있음
https://blog.naver.com/minuword/221248014506
#3 주워 담아야 할 것(a.k.a 기획부채)
#기획부채 #Myopia
단순하게 기능으로 풀었을 때 당장 해결하는 방법이 일도 아닌 것들이 종종 있다.
가령 '사람들이 자신의 목표를 작성할 수 있는 영역'과 '목표 달성률'을 입력할 수 있는 기능을 제공하며, 보다 정확하게 목표 달성률을 산출해 낼 수 있도록 사용자가 임의를 가중치를 곱하기 싶어 한다고 가정해 보자.
이를 기능으로 푼다면 그냥 이러한 가중치를 입력할 수 있는 Input 박스를 추가하면 된다.
예시 ⓒ 327roy하지만 SaaS 솔루션에서 특히 생각해야 하는 것은 이를 ‘보편적으로generally 누구나 사용할 수 있어야 한다.'는 점이다. (특히 제도와 관련된 제품이면 더욱 그렇다.) 특수성이 고려된 기능을 추가하면 결국 고객사로부터 전용개발 요청이 들어온다. 자신들은 이 기능을 보기도 싫으니 빼달라고.
결국 이를 고려하여 기능을 추가하게 된다면 ON/OFF가 가능한 '옵션' 기능의 기획과 영향범위, 개발 공수를 고려해야 한다.
그래서 우리는 기획을 할 때, 혹은 제품을 관리하며 해결책을 제시할 때 다른 방향으로 풀 수 있는 방법이 있는지, 진짜 그것을 해야 하는지(정말 그것이 문제인지) 고민이 필요하다. 깊은 고민 없이 막연하게 채택한 결과는 추후에 ‘기획부채’로 돌아오기 때문이다.
일을 하는 데 있어서 도전적일 필요도 있지만, 깊은 고민 없이 행해지는 도전은 무모함일 것이다.
멀리, 꼼꼼히, 잘 볼 필요가 있다.
#4. 집단지성의 힘
#집단지성
사람은 집단을 이룬다. 집단이 생기는 이유는 정서적 교감과 같은 이유도 있겠지만, 근본은 모여 사는 것이 그렇지 않은 것보다 효용이 크기 때문이라고 생각한다. 아래는 이번 주 집단지성을 느낀 경험과 레슨런이다.
1. 기획리뷰 시, 개발자, 디자이너와 함께한 How to 고민
기획 시 어떻게 화면에 풀 것인지에 대해 막히는 부분을 기획리뷰 자리에서 아이디에이션을 요청했고, 꽤나 좋은 결과를 얻어낼 수 있었다. 아이디어의 발산과 이를 수렴하는 과정이 힘들기도 하지만, 다양한 직군이 맞물려 만들어 낸 결과는 시너지가 좋았다. (개발, 디자인 공수를 줄이면서 기획에서 고려한 효용을 사용자에게 줄 수 있는 결과)
단, 이해의 시간을 단축시키기 위해 내가 생각한 How to를 먼저 공유했는데, 오히려 이 때문에 그들의 사고가 빠르게 확장되지 못했다는 생각도 든다. 어디까지가 가이드라인이고 어디까지가 울타리일까?
2. '작은 도서관' 셀원 피드백
금일 기획 스터디가 일찍 마무리되어 따로 만들고 있는 '공유 목적의 아카이브, 작은 도서관'을 셀원과 셀장님께 공유하고 피드백을 요청했다.
현재의 형상과 고민하는 부분에 대해 설명했는데, 짧게 설명한 것임에도 불구하고 모두에게 정말 도움이 되는 피드백을 받을 수 있었다. 당장 실행 가능한 액션 아이템도 존재하는 만큼, 이번 주중 밤에 조금씩 시도할 생각이다. (가령, 도서관을 공유 목적으로 만든다고 공유했을 때, 스토리를 챙기는 것에 대한 피드백을 받았다.)
#5. 알아두면 쓸 곳 있는 UI 가이드
#UI #컴포넌트
서비스 기획자, 프로덕트 매니저의 핵심 능력은 이해관계자와의 원활한 커뮤니케이션이다. 개발자와 대화를 하든, 디자이너와 대화를 하든, 대화의 상대가 누구든 간에 그들의 언어를 해석하고 자신의 의도를 정확하게 전달할 수 있어야 한다.
제품 개발 프로세스의 끝에서 산출물을 잘 만들어 내기 위해서는 어떻게 해야 할까? 기획자 자신이 정의한 문제의 해결방안 혹은 검증하고 싶은 것을 개발자와 디자이너에게 명확하게 전달할 수 있어야 한다. 그래서 우린 이를 위해 화면을 설계하기도 하며, 디자이너, 개발자와 함께 회의실 티브이에 디자인을 띄워놓고 논의를 가지기도 한다.
결국 좋은 기획자가 되기 위해서는 UI에 대해서도 얘기를 할 수 있어야 한다. 단순히 디자이너의 모든 요구를 수용하는 것이 아닌, 개발 가능한 스펙과 이상적인 디자인 사이에서 아슬아슬한 줄타기를 잘해야 할 필요가 있다. 가령 토스트메시지와 알럿 모달 중 무엇이 더 상황에서 적절한 인터랙션일지, 텍스트 필드와 텍스트 에어리어 중 무엇이 더 적합한 사용자 경험 인가 와 같은 것들을 디자이너뿐 아니라 기획자도 판단할 수 있어야 한다.
즉, 기획자도 UI를 알아야 한다.
생각 중인 것은 Ant Design Component, Material Design Compoentn 등을 참고하여, 서비스 기획 시 자주 사용하는 컴포넌트들을 리스트업하고, 이들이 1) 언제 사용되는지(When to use), 2) 어떤 특징을 가지고 있는지 를 정리하는 것이다. 시간 될 때마다 가볍게 작성해 봐야겠다.
#6. UX 라이팅에 대한 대화 그리고 고찰
#UX라이팅 #글쓰기
오늘 구성원 분과 버튼 UX 라이팅에 대해서 얘기한 내용 중 인상 깊었던 것.
처음에 버튼의 이름을 [생성]으로 하고 싶어 했지만, ‘친절’을 고려하다가 결국 디자인 단에서 [과제 생성]으로 톤을 잡게 되었다고 한다. (아마 사용성 관점에서의 ‘친절’이 아니었을까 한다. 보통 UX 라이팅의 개론에서 말하는 4가지 원칙 중 ‘명확하게 작성하기’에 해당하는 것) [생성]으로 버튼을 퉁쳐도 되는 경우는, 버튼이 존재하는 영역이 UIUX상 어떤 것을 가리키는지가 명확할 때라고 생각한다.
가령 블로그 글을 쓰는 화면에 [게시]라는 버튼이 존재할 경우, 이 [게시] 버튼은 버튼의 명사 앞에 ‘글’이라는 단어가 빠져도 버튼을 클릭하면 ‘글을 게시하는 것’ 임을 알 수 있으니까.
여기서 사소한 디테일, '게시하기, 게시’ 중 무엇이 더 나을까?
'게시하기'? '게시'? ⓒ 327roy