당당한 디자인 결정을 위한 9가지 방법(7)
톰 그리버의 'Articulating Design Decisions'
7장: 메시지를 선택하자
6장에서는 소통할 때 활용해야 할 여러 기술들을 살펴봤다.
이제 기술들을 각 맥락에 맞춰 적용할 메시지를 파악해야 한다.
순서에 특별한 기준은 없지만 '비즈니스, 디자인, 연구, 제약사항'이라는 네 가지 카테고리로 구성된다.
1. 비즈니스
디자인을 변론할 때 가장 좋은 방법은 디자인과 비즈니스 수요 연결이다.
일반적으로 통용 가능한 세 가지 문구는 다음과 같다.
[1] 목표를 이루는 데 도움이 된다
우리의 디자인은 기업이 목표를 이루는 데 기여하고자 한다는 점을 항상 강조하자.
여기서 중요한 점은 확실하게 아는지 여부가 아니다.
우리의 디자인이 최소한 가고자 하는 방향으로 향하고 있다고 믿고 자신감을 가져야 한다.
효과적으로 해내기 위해선 우리의 솔루션이 어떻게 특정 문제점을 해결할지 잘 연결해서 설명해야 한다.
[2] 유스케이스를 용이하게 한다
우리가 하는 모든 일은 특정 유스 케이스, 사용자 스토리, 기능 세트와 관련이 있으므로 위 문구는 어느 디자인에서도 가장 명확하고 일반적인 설명이 돼줄 것이다.
우리의 결정이 어떤 유스 케이스에 도움이 되는지 짚어주면서 이해관계자가 수긍하도록 설명할 수 있다.
[3] 브랜딩과 일맥상통한다
앱 디자인은 기업이 브랜드 정체성을 전달하는 좋은 채널이다.
UX 프로세스에 해당하지 않는 부분이기도 하지만 일부 기업에서는 버튼, 드롭 다운 목록, 체크박스 같은 세부요소들에 적용할 자체 스타일이 없는 경우도 있다.
이때 기업이 우리가 만든 스타일 지침을 갖고 브랜딩 규범과 시각적인 정체성을 긍정적으로 발전시키도록 기여할 수 있다.
2. 디자인
우리가 왜 그렇게 디자인했는지에는 분명 이유가 있다.
디자인 근거를 설명할 때 필자는 주로 다음 세 가지 메시지를 활용한다.
[1] 일반적인 패턴을 사용한다
이해관계자들은 UI 디자인에서 말하는 '패턴'이라는 콘셉트를 잘 모를 수 있으니,
이 용어를 쓸 때는 이해관계자가 소외됐다고 느끼지 않게끔 주의하자.
사용자 경험에서 일관성이 중요해서 특정 맥락에서 패턴을 변경하면 파급효과처럼 앱에 있는 다른 부분들도 다 수정해야 한다는 걸 이해하게끔 설명하자.
패턴은 한 부분만 개별적으로 분리해서 결정할 수 있는 게 아니다.
디자인 패턴은 일관성을 부여하고 어떤 인터랙션이 일어날지 사용자가 미리 예상하도록 도와야 한다.
하지만, 특정 패턴을 선택하지 않았을 경우의 시나리오를 나타내는 확실한 데이터도 없이 어떤 패턴이 더 효과 있을지 논의하는 건 의미가 없다.
[2] 사용자의 이목을 끈다
이해관계자가 우리가 왜 그런 결정들을 내렸는지 파악하도록 하려면 디자인 요소와 사용자 행위 간의 관계를 이해시키는 일이 중요하다.
우리가 내리는 결정은 웹사이트나 앱에서 궁극적인 목표인 '사용자 행위'를 토대로 한다.
[3] 사용자를 위한 흐름을 형성한다
우리의 디자인이 사용자 흐름에 영향을 미치는지 세심하게 살펴봐야 한다.
왜 그런 결정을 했는지 이해관계자들이 이해도 하지 않은 채 흐름을 망가뜨리지 않도록 하자.
3. 연구
데이터, 사용자 테스트, 기타 다른 연구 결과를 활용하는 건, 우리의 디자인을 정당화하는 데 가장 설득력 있는 방법이다. 다음 세 가지 일반적인 답변 메시지를 제시하고자 한다.
[1] 데이터가 이를 입증한다
우리의 디자인을 뒷받침할 데이터를 활용하는 건 곧 이해관계자의 지지를 얻을 절호의 기회다.
우리의 디자인이 의도하는 효과를 가져온다는 인과성을 가장 과학적인 방식으로 보여줄 수 있기 때문이다.
기업들은 충분한 데이터를 보유했음에도 시간이나 기술이 부족해서 그걸 추려내서 의미 있는 결론으로 도출하지 못하는 경우가 매우 많다.
따라서 우리가 다루는 맥락에 유용한 데이터를 찾아 디자인 내용을 변론하는 데 활용하자.
이때 활용 가능한 데이터에는 두 가지 유형이 있다.
1) 기존에 있던 데이터
이미 가지고 있고 지금 결정하는 데 활용할 수 있다.
데이터를 보고 예측할 수 있다.
2) 해석한 데이터
디자인을 변경하고 전후를 비교한 뒤 수집하는 데이터
데이터를 가정한 이후를 의미한다.
즉, 디자인을 한 번 수정해 보고 관련된 데이터 수치가 좋아졌는지 해설할 수 있다.
이런 정보를 확보한다면 무엇이 '옳은'지 훨씬 분명하게 드러난다.
데이터는 이해관계자를 설득하는 데 정말 강력한 아이템이다.
그러므로 옳지 않은 데이터는 옳지 않은 선택으로 이어진다는 점 또한 인식해야 하며,
데이터를 활용할 때 매우 신중해야 한다.
데이터는 보통 사용자가 '무엇'을 했는지 말해주지만 '왜' 그렇게 했는지는 말해주지 않는다.
따라서 데이터를 토대로 결정하는 방법은 너무 많은 가설을 세우지 않고,
적절한 맥락에서 전체적으로 프로젝트를 보고 쓸 때만 진정으로 효과적이라는 점을 유념하자.
우리의 목표는 단순히 동의를 얻고 우리 하고 싶은 대로 디자인하는 게 아니라는 점을 기억해야 한다.최상의 사용자 경험을 창출하고 이해관계자가 그 목적을 달성하는 데 기여하는 것이 목표다.
[2] 테스트 결과에서 이렇게 나타났다
사용자 테스트는 원 데이터가 제공하는 기계적인 느낌보다는 실질적으로 인간적인 요소를 반영해 스토리를 만들어내는 방법이다.
이해관계자에 따라 사용자의 실제 스토리를 활용하는 게 숫자나 차트보다 훨씬 더 효과적일지도 모른다.
우리의 디자인에 정당성을 부여하려고 사용자 관찰 결과를 활용할 때, 몇 가지 문제점이 있다.
사용자 관찰은 매우 주관적이고 우리가 기억하는 내용을 바탕으로 하므로 클라이언트와의 회의 용도로 문서화하기가 어렵다.
그럼에도 사용자와 상호작용하고 거기서 얻은 교훈을 디자인에 반영해 개선한다는 걸 나타내기에는 효과적인 방법이다.
'사용자 테스트에서 얻은 아이디어를 전달하기에 가장 좋은 방법'은 일부 사용자의 말을 인용 문구로 슬라이드에 담거나 테스트 세션 중 발견한 문제점을 영상으로 찍어 보여주는 것이다.
이러한 방식은 시간을 절약하고 핵심만 보여주면서도 상대방이 실제 사용자 세션을 직접 볼 기회를 제공하고, 실제 사용자를 간접적으로라도 만나볼 수 있는 효과적인 방법이다.
[3] 다른 연구 결과도 이를 뒷받침한다
우리가 결정한 디자인을 정당화할 때, 가능한 모든 참고자료를 갖고 있어야 한다.
좀 더 중요한 이해관계가 달려 있는 경우에는 우리가 작업한 디자인이 최상의 선택이라고 확신을 주는 데 유일한 방법일 수도 있다.
1) 햄버거 메뉴 아이콘 제거하기
햄버거 아이콘이 '메뉴'라는 이름값을 할 만큼 효과적이지 않다는 점을 보여주는 연구결과를 토대로 제안한다. 설명만으로 설득하는 데 충분하지 않았다.
결론을 내리는 데 참고할 수 있게 두 가지 방안으로 A/B 테스트를 만들었다.
우리의 디자인을 뒷받침하고자 외부 연구 자료를 사용할 때는 다음 사항을 유념하자.
나중에 찾을 수 있게 별도의 파일로 연구 자료를 저장해 두기
제목, 저자, URL/링크, 날짜를 적어두기
우리의 프로젝트와 어떤 연관이 있는지 간략하게 요약해 두기
이해관계자가 요청하면 보여줄 수 있도록 참고자료 목록을 만들어두기
균형 잡힌 정보를 고루 갖추는 차원에서 다른 관점을 담은 자료도 찾아보기
이해관계자도 생각해 보고 대답할 수 있는 기회를 주기
4. 제약사항
일을 추진하다 보면 결정을 내리고 정당화하는 때도 있고, 제약사항이 있다고 주장해야 할 때도 있다.
우리의 역량 밖에 있는 변수가 생기기도 하고, 디자인이나 프로그래밍 기준에 맞춰야 하다 보니 항상 클라이언트가 원하는 걸 해줄 수는 없다.
이런 제약사항을 다룰 때 일반적으로 활용할 수 있는 답변 문구로는 다음 세 가지를 들 수 있다.
[1] 자원이 충분하지 않다
디자인 분야에서 유감스러운 현실은 기업이 바라는 바를 대개 앱이나 웹사이트에서 실현해야 하는데, 필요한 자원을 전부 갖고 있지는 않다는 사실이다.
이런 제약사항을 고려하는 건 의사결정 과정에서 중요한 부분이다.
다른 분야에 비해 특히 웹/앱 디자인 영역에 영향을 미치는 네 가지를 소개한다.
1) 지원 부족
지지가 충분하지 않거나 인프라가 부족하거나 추가 필요사항을 처리하는 절차가 미흡할 수도 있다.
설령 프로젝트에 착수한다 해도 그걸 추진해 나갈 내부적인 지원이 부족하다.
2) 인력 부족
인력 부족이 단기적인 문제처럼 보일 수도 있지만 일단 일을 할 사람이 충분하지 않다는 사실은 디자인 과업 범위를 조정하는 데 정당한 사유로 작용할 수도 있다.
우리가 맡은 디자인이 현재 및 향후 인력 상황에 어떤 영향을 받게 되는지 항상 고려하도록 하자.
3) 예산 부족
구현해야 하는 서비스나 기술을 추가할 예산이 없는 경우를 의미한다.
예산이 부족하면 재정적 한계에 맞춰서 디자인해야 한다.
우리의 디자인을 설명할 때 이런 사유를 명확하게 알려야 한다.
4) 시간 부족
시간이 부족하면 보통 갖고 있던 아이디어를 정해진 기한 내에 해낼 수 있을 정도로 맞춰 줄이게 된다.
즉 아이디어의 실행 수준을 낮추는 행위이며, 이는 매우 중요하게 소통해야 하는 부분이다.
그렇다 보니 많은 팀들이 최소 기능 제품으로 시작해 계속 그 정도 수준에서 반복 작업하는 경향을 보인다.
항상 한계가 주어진 범위 안에서 디자인해야 한다.
[2] 기술적으로 제약이 있다
디자인 아이디어가 좋다고 하더라도 뒷받침할 기술이 없다면 그 아이디어는 고려할 수 없다고 설명하는 게 좋다.
[3] 기준에 맞춰야 한다
해당 앱이 모든 브라우저, 기기, 사용자에게 작동하길 바라므로 개발하는 측면에서 일정 부분 정해진 '룰(기준)'을 따라야 한다.
한 예로 '접근성'을 언급할 수 있다.
오늘날 거의 모든 것이 기술적으로 가능하긴 하지만, 그렇게 모든 기술을 갖다 쓰는 게 항상 바람직한 것도 아니므로 이런 기술적인 요구사항을 신경 쓰면서 적절한 수준에서 이해관계자의 기대치를 조절해야 한다.
우리는 앱에 반영한 기준들이 앱 개발 과정, 장기적인 휴대성 및 접근성에 이롭다는 걸 보여주고자 한다.
