[UPF 2022ss] 에이블리 프로덕트 디자이너님 세션정리 (4/9)

에이블리 프로덕트 디자이너님의 세션 '디자인 이론을 제품에 적용하는 방법'을 듣고,
의미있었던 강의 요약과 질의 응답을 정리하였습니다.

---

강의 요약

많은 디자인 이론, 레퍼런스들은 남의 이론이다. 서비스도 유저도 다르기 때문에 그 방법을 우리 안에 넣으면 성공하기가 어렵다.
참고는 하되 최대한 우리껄로 녹여서 자신만의 이론을 쌓는 것이 좀 더 좋다고 생각한다.
많은 실험을 통해 우리만의 데이터를 가지고 우리(팀) 만의 이론을 만드는 것이 중요하다.

실험할 때 고려할 점
1) 가설을 검증할 수 있는 최소 스펙인지, 기존의 디자인 시스템 같이 이미 가지고 있는 디자인 스펙을 활용하면 코스트가 낮아진다
2) 개발과 디자인을 적게하면서 비즈니스 임팩트를 주나
3) 우리의 의도를 유저들에게 명확하게 전달하나

질의응답

Q1. 에이블리에서 디자이너와 개발자가 함께 디자인 시스템을 구축하고 계신지, 디자인 토큰과 컴포넌트 분류에 대한 디자이너와 개발자의 관점이 다른데 어떤 과정으로 협업하시는지 궁금합니다. 개발자와의 협업 과정에서 어떤 어려움이 있는지

A1. 어려움이 많았다. 디자이너가 상상하는 디자인 시스템과 개발자가 상상하는 디자인 시스템이 다른데, 중간 지점을 찾는 것이 중요하다. 처음부터 구축하지는 않는데, 리소스가 많이 쓰이기 때문이다. 디자인 시스템에 리소스를 둔다면 다른 개발 리소스를 하지 못하는데 임팩트 대비 큰 효과를 많이 보지 못하는 편이다. 당장 공통적으로 쓰이는 패턴(ex, 버튼, 탭) 들부터 시작했고 새로운 페이지의 컴포넌트는 디자인 시스템에 추가한다. 다른 스쿼드에서 다른 화면을 개발할 때 기존 디자인 시스템을 활용해보고 싶다면 해당 컴포넌트를 더 고도화 하는 편이다. 그러다보면 n차적으로 사용하는 컴포넌트가 생길 때마다 얼라인 됨


Q1-2. 구체적으로 어떤 관점차이가 있었는지?

A. 확장성을 어디까지 고려하는지에 대한 차이가 있음. 디자이너는 리스트 컴포넌트를 만들면 텍스트가 앞에 있고 뒤에 텍스트가 달리고 등등,, 상상을 하고 만드는 경우가 많음. 지금 당장 사용하는건 하나인데 다른 5개를 미리 만들고 싶은 것이 예가 될 수 있음. 하지만 개발자 입장에서는 1개를 만들고 5개를 만드는 것이 개발 공수차이가 있기 때문에, 어디까지 개발해야하고 확장할 것인지 함께 맞춰가는 것이 중요함



Q3-1.데이터 드라이븐으로 유저테스트를 할 때 유의미한 데이터를 모았다고 할 수 있는 기간은?

A. 서비스마다 유의미한 정보에 대한 기간은 다르다. 서비스의 트래픽에 따라 달라진다.


Q3-2. 데이터 드라이븐으로 유저테스트를 할 때 디자인을 개선하는 것에 대한 기준은 ?

A. 실패하면 바로 종료한다. 조금이라도 미미하게 떨어지면 다음에 해보자고 백로그로 옮기되 우선순위를 높게 잡지 않는다. 다만 100명 미만일 경우에는 크게 의미가 없다.


Q3-3. 100명이면 데이터 드리븐은 크게 의미가 없다고 하셨는데 100명 미만일 경우에는 디자인 개선에 대한 기준이 무엇인지 ?


A. 아예 의미가 없진 않다. 100명 중 우리가 개선할 디자인을 지금 사용하는 사람을 타겟으로 할지, 안 쓰는 사람을 타겟으로 할 지 결정하는 것에 대한 지표가 될 수 있음. 다만 100명 미만일 경우는 대게 개인의 과거 경험에 의존하는 경우가 많다.


Q4. 이탈율을 낮아지는 것을 방지하기 위해 개인화 추천 기능은 어떤지?
A. 개인화 추천기능을 하면 좋아지겠지만 코스트가 많이 든다. 따라서 우선순위를 높게 잡기에는 리스크가 높다. 다만 코스트가 높아도 할만한지 판단하기 위해 개인화에 대한 타이틀만 걸어놓고 유저들이 선택하는지 안 하는지를 보면 알 수 있기도 하다.