2024. 11. 21.
2024 인프콘 Infcon UX 세션 정리
ux/세상은 넓고

2024년 8월 2일 인프콘에 참여해 UX 세션을 들으며 개인 노션에 메모한 글을 재발행 했습니다.

 

UX writing (배달의민족)

> UX writing이 왜 어려울까?

  1. 가이드가 모든 것을 커버할 수 없음
    • 같은 표현도 맥락에 따라 지향/지양이 갈린다. ex) ‘불가’ 와 같은 부정의 표현.
    • 임시로 브레이크타임이라 주문이 불가한 상황 등
    • 맥락에 따라 결정하기 어려움
    • 한국어의 미묘한 톤 문제
  2. 누구나 개입하기 쉬움
    • ux라이팅 → 결정하기 / 설득하기 어렵다!
  3. 라이팅 작업 시간 <<< 이해관계자 미팅 및 슬랙 커뮤니케이션 
  4. 느낌만으로 결정하기 어렵다. 탄탄한 라이팅 논리가 필요함.

> UX writing에서 가장 중요한 두 가지

  1. 말투에서 정보로 관점을 바꾼다
    • 말투 (어떻게 말할지) how to say < 정보 (무엇을 말할지) what to say
    • 말투 : 주관적일 수 있음 (친절해요 vs 진심같지 않음)
    • 정보 : 기획/디자인 목적에 따라 어느 정도 답이 있는 정보 위계
      - 배달 지연 때문에 보상을 전달하는 것이 메인이라는 목적을 전달하는게 중요
    • Ex) 3000원 더 담으면 5000원 할인 가능!!
      - 말투 관점 : 할인가능 → 할인 받을 수 있어요 / 할인 돼요
      - 정보 관점 : 이 컴포넌트의 목적은 뭐지? 목적 달성을 위해 필요한 정보는 무엇이고, 지금 빠진 건 뭐지?
      => 정작 쿠폰이라는 말이 안들어갔었음
    • 말투를 아예 안 보는 것은 아님. 정보를 먼저 짠 다음에 본다는 뜻.
  2. 사용자 동기와 기대 결과를 분명히 한다
    • 상황/맥락 - 사용자동기 - 기대결과 (jobs to be done)
    • 3천원 더 담으면 5천원 할인 가능!
      - 상황 : 장바구니에 상품을 담고 결제 단계로 넘어가려는 상황
      - 사용자 동기 : 할인 받을 수 있는 방법이 있다는 걸 이해한다
      - 기대 결과 : 상품을 더 담는다
      - to be: 3천원 더 담으면 5천원 쿠폰할인!

> UX writing이란 : 사용자의 문제를 해결하는 글쓰기

 

방향성 자체를 다르게 생각하는건지? 방향성은 같으나 더 나은 라이팅 표현을 바라는 건지? 생각해보기

“가장 중요한 정보가 뭐예요?”

  • 공간의 제약 및 사용자가 많은 정보를 한 번에 인지하기 어려움을 상기하기.
  • 질문은 많을수록 좋아요!

성공적인 UX 솔루션 (여기어때)

“무엇이 성공적인 UX를 만들까요?”

→ 가장 중요한 것은 공감대의 형성

  • PO UX Dev 끼리 / 팀 끼리 / 팀과 리더 끼리 …
  • 더 나아가서 고객과의 접점이 만들어져야하고, 그 공감대가 필요

1. UX - PO - Dev 다방면으로 접근해서 공감대 만들기

  • UX : 고객 문제
  • PO : 비즈니스 임팩트
  • Dev : 구현 타당성

⇒ win - win - win 솔루션 탄생

 

step1. 문제점/요구사항 수집

  • UX : 관련 ab 실험 데이터 + 관련 솔루션 ut / idi 데이터
  • PO : 비즈니스 요구사항 수집
  • Dev : 시스템 문제점 파악

step2. alignment

step3. 컨셉3 Phrases 정의

step4. crazy1 아이데이션

step5. 솔루션 finalize

  1. 고객입장에서 공감대 만들기
    • 우선순위 산정의 필요성
    • BRICE 모델 (BRI*C / E)
      • B : Business Importance 비즈니스 가치 예측치
      • R : Reach 도달 정도
      • I : Impoact 발생 고객 가치 예측치
      • C : Confidence 성공에 대한 신뢰
      • E : Effort 들어가는 공수
    • BRICE 점수로 우선순위 (Priority) 선정→ 더 나은 방법이 있을까?
    • → BRICE로 우선순위를 정했는데 솔루션이 달라지면? 치명적인 문제가 발견된다면?
    • 딜레마
      • 고객 문제부터 치명성을 판단해보자 → PPF 도입
      • PPF = Problem Prioritization Formula (고객 문제의 치명성 판단)
      • 최대한 객관적으로 산정하기
  2. 협동 프로그램으로 솔루션 만들기
    → 주요 프로젝트말고 사이드로 공감대 만들 수 있음
  3. 공감대를 형성하는 커뮤니케이션
    • 되도록 안건 및 자료를 미리 준비하고, 숙지한다.
      → 10분이라도 미리 내용을 검토해보는 것은 잘못된 커뮤니케이션이 될 확률을 낮출 뿐 아니라, 더욱 더 깊이있는 논의를 가능케 한다.
    • 돌려 말하지 않고 직접적으로 전달하되, 무례하거나 공격적으로 말하지 않는다.
      → 다만, 직접적으로 얘기하는것과 무례하게 얘기하는건 다른 것임을 반드시 인지.
      → 간접적으로 표현하면 정보 전달이 비효율적/불필요한 오해를 불러일으킬 수 있음.
    • 추상적이거나 감각에 의거한 피드백은 최대한 자제한다. 구체적이고 현실적인 피드백을 지향한다.
    • 긍정적인 점도 반드시 이야기한다.
      → the compliment sandwich
    • 발화시 ‘필러’를 쓰지 않도록 노력하라.
      → 사족을 붙이면 이는 메시지의 전달력을 약화시킬 수 있으며, 자신감이 부족해보일 수 있음.
    • 내용 요약 및 액션 아이템을 명확히 전달한다.
      → 최종 액션아이템 정리로 세션을 마무리함으로써, next step에 대해 모두가 명확히 인지할 수 있도록.
  4. 마지막 핵심
    → 고객 문제 - 비즈니스 임팩트 - 구현 타당성까지, 다방면으로 접근해보자 / 치명성 기준으로 우선순위화 하자 / 직접적, 구체적, 긍정적인 점을 포함하여 컴케하자
  5. 이 모든것의 핵심은 실행력이다.

디자인 시스템의 명과 암 (원티드랩)

> 디자인관점

 

서로다른 제품/기획/맥락/스타일/관점 …

  • 문제? → 똑같은 버튼 (ui) 만드느라 시간이 너무 오래 걸림
  • 해결 → 디자인 시스템으로 디자인 작업 속도와 퀄리티를 혁신한다

 

명 : 작업 속도와 퀄리티 높이기 성공

  • 예시 ) AI 면접 코칭이라는 case
    • 디자인 없이 프로토타입만으로 구체화된 상황이었음 (by AI 엔지니어)
    • 미리 만들어둔 디자인 시스템을 활용해서 빠르게 고퀄리티로 내보내보자!
    • 1시간 만에 디자인 시스템 기반으로 초안 제작
    • 3일 후 FE 개발 & Dev 배포
    • 10일 후 상세 기획, 디자인, 개발 동시 작업..
    • 그 후 출시 성공
    • 디자인 라이브러리 → figma에 배포

but.. 암 : 끝없는 맞추기

 

예상과 다르게 TF 이외 구성원들 싱크 맞추기, 뭐가 최신이야, 러닝커브, 새로운 케이스 맥락 발생, 유연성 하락…

→ 많아진 케이스를 어떻게 대응? 어디까지?

  • 사례 기반으로 베스트 프렉티스 제안
    • 프디 시안 기반의 사례 수집, 의견 상시 수렴
    • 그것들 취합하기
  • 복잡해진 구조, 어떻게 이해시키지?
    • 캐주얼 미팅과 (프디) 직접 기여로 시너지 내기
    • figjam으로 문의 모으기
  • 디자인 & 개발 싱크
    • 컴포넌트 배경 색상을 통해 1차적으로 인지시키기
    • 피그마 기능 : 섹션 & dev mode 적극 활용
  • 맞출 건 많은데 자꾸 밀리는 우선순위
    • 회사에서 충분한 개발 자원 받기 어려움
    • 열정에 기대야 함
    → 신뢰를 얻기 위한 활동 필요
    • 내부에 알리기 - 전사발표 & 구성원 온보딩
    • 외부에 알리기 - 브런치, 커뮤니티, 인프콘 등
    • 프로젝트로 검증하기 - 다양한 프로젝트에 시스템 선제적용
    • 데이터로 알려주기 - 팀별 컴포넌트 사용량, 코드 적용비율 측정
  • 결과적으로,
    • 최소 인력 & 메인 담당자 지정
    • 구성원의 이해도 & 기여도 상승
    • 리소스 추가 지원

> 개발 관점

 

<태초에서 시스템에서 발전시키기>

최초 : 단일 프로젝트에서 공통 컴포넌트 제작으로 가볍게 시작!

→ 하다 보니까 꽤많은 컴포넌트 제작하게 됨… → 고도화 도중 TF 해산… → TF 인원 해산됐지만 패키지화 진행

 

명 : UI 개발 시간 단축

  • 컴포넌트 재사용성 & 일관성 증가
  • 디자이너와 개발자 간 협업 효율 향상
  • 기존 : 기존 작업의 레거시화 → 이후 : 간결한 이름으로 압축 가능

암 : 환경별 대응 어려움, 개발자 경험 낮다

  • 현 패키지를 못쓰는 것이 많음
    • 컨벤션 안맞음, 반응형 불편함….
    • 태초의 시스템은 단일 프로젝트 용으로만 설계되어 패키지화를 했다 해도 타 서비스에서 쓰기 어려움
  • 따라서 TF 재개
    • 레퍼런스 찾기
      : MUI, Chakra-UI, Primer… → 공통 : Box + SxProp 사용
      - Box 컴포넌트 안에 sx라는 조건부 style
      - 이걸 적용시켜 개발자 경험 향상
      - but 개선만 하다가 신규 컴포넌트 제작을 못하는 상황 발생
    • headless ui : 라이브러리
      - 스타일 없음, 컴포넌트 기능 구현, 접근성 처리까지 한번에 가능
      - radix primitives : 골라서 사용 가능

 

> 결론

조니 아이브의 명언..  "어느 직업이든 돈을 버는 일은 끊임없이 조율하고 협의하고 부딪히는 노동의 대가이다"

  • Dev
    • 지속적인 업데이트 및 개선 필요
    • 개발자와 디자이너 간 적극적인 커뮤니케이션 필요
    • 급하게 다른 시스템을 따라가려 할 필요 없음
  • Design
    • 지속적인 업데이트 및 개선 필요 → 한번 만들었다고 끝이 아니라 프로덕트가 계속 변화하기에 새로운 유저 경험이 필요
    • 효율성과 퀄리티의 정반합 - 디자이너들이 생각하는 퀄리티와 개발이 생각하는 퀄리티를 같이 고려하면서 발전시켜가야 함
    • 상황에 맞는 방법은 조직마다 다 다름. 다양한 방식 고려 필요.

 

> 사전질문 QnA

 

Q1. 제작 원칙에 어긋나는 케이스 대처

→ 디자인 : 원칙을 벗어나는 사례는 무조건 존재. 수정을 막기 위해 속성을 숨겼음에도 커스텀하는 경우 빈번히 발생. 디자인 조금만 커스텀 돼도 개발쪽에서 디자인시스템을 쓸 수 없는 경우가 발생함. 여기까지만 커스텀 가능하다는 것을 정의해둠.

→ 개발 : 커스터마이징 이슈는 매우 일반적인 상황. 일관성 vs 유연성 선택

무분별한 커스터마이징은 지양해야하지만, 어느정도의 유연성은 열어두어야 함. 무분별한 커스터마이징을 막기 위해 feedback 채널을 열어두어야 함. 사용자들의 피드백을 수집하고, 피드백의 패턴이 보인다면 디자인 시스템에 녹이는 roof 가 필요

 

Q2-1. 소규모 팀에서도 디자인 시스템이 필요할까요?

→ 필요성이 느껴지지 않는다면, 할 필요없다. 시스템은 만드는것부터가 시작이기 때문에 만들어놔도 쓰지 않는 경우가 발생할 수 있음.

→ 디자인 시스템의 개념을 어디까지로 정의하느냐에 따라 다를듯. 어려우니까 안한다! 해버리면 안됨. 개발이나 디자인 리소스를 받기 어렵다면 혼자 조금씩 해보기. figma 컴포넌트나 라이브러리….

 

Q2-2. 필요하면 피그마 유료플랜도 필요하고, 그런데 어떻게 의사결정권자를 효과적으로 설득할 수 있을까요?

→ 이미 쓰고 있는 툴이나 체계를 먼저 살펴보고, 도입하고 싶은 플랜과 기술이 어떤 효용을 가져다 줄 수 있는지 설명해보기. 재무 쪽은 금액을 먼저 정리해보고, 현재와 기대효과를 비교하면서 제안.

 

Q2-3. 별도로 시간을 태워넣어서 구축하는게 아니라, 일반적인 근무 시간 내에서 효율적으로 디자인 시스템을 구축할 수 있을까요?

→ 한 번에 완벽하게 구현하려고 하지 말고, 간소화된 디자인 시스템을 구축해봐라.

→ 컬러 팔레트를 만들어보든가.. 아이콘.. 타이포 등 가장 자주 사용하는 항목들을 만들어보자. 컬러 토큰의 값이 바뀌면, 다른 값들도 바뀌는 그런 구조 (figma로는 variants)를 먼저 구축해두는 것을 추천.

→ 크게 보면 막막해보이지만 작게 보면 실현불가한 것은 아님. 내 일을 빨리 하기 위함이라고 생각하고 점진적으로 진행.

 

Q4. 디자인 시스템이 없는 조직에서 디자인 시스템을 만든다면 어떤 시기가 적절할까?

→ 완벽한 시기는 없다. MVP 제품이 출시되고부터 준비하면 좋겠단 의견. 디자인 부채나 코드 리팩토링이 가장 적은 시기같음.

 

Q5. 만든다고 해도, 어떻게 효과적으로 전파하는지에 대한 고민이 있다. 기존에 사용하지 않았던 사람들을 어떻게 설득해야 할지? 설득 후 실제 활용에 불편이 없도록 문서화하거나 가이드를 주어야 할텐데, 어떤 방식이 제일 효과적일지?

→ 실제로 도움이 된다는 것을 말해야 함. 이런 것들을 도입하면 속도가 빨라질거다, 남은 시간을 flow 개선 등에 쓸 수 있다 라는 것을 전달드릴 수 있음. 익숙하게 쓸 수 있도록 도와줌. 공감대를 형성해야 함.

 

작은 조직을 위한 효과적인 디자인 시스템 - 또자인시스템 (인프랩)

  1. 배경
    • 다양한 페이지와 채널을 걸쳐 공통의 언어 구축
    • 이점
      • 공통된 언어를 생성할 수 있다. 부서 및 팀을 넘어서
      • 시각적 일관성을 유지할 수 있다. 제품, 채널을 넘어서
      • 디자인/개발 작업을 신속하게, 대규모로 만들 수 있따
      • 더 크고 복잡한 문제에 집중하게 한다.
    • 작은 조직
      • 왜 디자인시스템 조직이 없을까? → 인식 부족, 우선순위 문제 (당장의 제품이 급함), 구조의 관성(이미 구축된 팀이 있는데 굳이.?), 리소스 제약, 규모의 문제(효율성을 발휘할 정도로 큰 프로덕트가 아닐 수 있음)
    • 리소스 레버리지
      • 외부에서 리소스를 빌려온다. 그리고 더 중요한 곳에 리소스를 사용한다. 이미 밖엔 충분히 좋은 리소스가 많다. 선택지도 다양하다.
      • 비즈니스와 사용자가 결국은 가장 중요.
  2. 시작하기
    • 오픈소스 UI 라이브러리
      • 디자인시스템이 필요한데, 여기에 시간이 뺏기면 안되기때문에 여러 오픈소스 라이브러리를 가져온다.
      • 고려 사항
        • 리액트 라이브러리 지원여부
        • 스타일 정의된 다양한 컴포넌트
        • 커스터마이징 가능여부
        • 개발 빌드 환경, 번들크기 로딩시간, 브라우저 호환성
      • Ant Design
        • 장점 : 60개의 컴포넌트
        • 단점 : 커스텀불가
      • Flowbite
        • 장점 : 시각적으로 돋보임
        • 리액트 미지원, 브라우저 호환성 문제
      • MUI
        • 장점 : 머터리얼 앱 디자인, 웹 반응형도 지원
        • 단점 : 모바일 사용성, 스타일 수정 방법의 복잡함
      • chakra
        • 장점 : 커스터마이징 용이
        • 단점 : 다양하지 않은 컴포넌트, 업뎃이 뜸함
      • Mantine 선택
        • 그리드 시스템, 문서 잘 나와있음,.. 등
    • 공식 Figma 키트 지원 안함
      1. 피그마 키트가 없는게 그렇게 큰 치명적인 단점은 아녔음
      2. 스토리북에 있는걸 피그마로 변환해주는 플러그인 발견 → anima?애니마
      3. 만사천개를 600개로 줄임
    • 요약 : 작고 빠르게 시작하고, 하면서 정리하기
  3. 사용하기
    • 핸드오프 → 사진찍어둠 ㅎ
  4. 다듬기
    • 아이콘 사례
      • 만타인에서는 아이콘 따로 제공 X. 아이콘 라이브러리를 가져와서 사용해라. (어떤 거든 다 )
      • 폰트어썸 = 전세계에서 가장 많이 사용되고 있는 아이콘 라이브러리
        • 폰트어썸 찾고 내려받기
        • svg 파일로 다운로드
        • 피그마에 업로드
        • 컴포넌트로 귀속시키기
        • 배포하기
      • 근데 fe 입장에서는…
        • 아이콘 로컬에 내려받고
        • 리소스 서버에 업로드하고
        • 서버에서 불러오기
      • 폰트어썸 폰트를 쓰면.. 아이콘 변수를 써서… 텍스트입력.. 대체텍스트로 …
        • 그렇게 하면 그냥 클래스명만 복붙하면 됨
        • 빌려오는것만큼 다듬는 것도 중요하다.
    • UX Writing 사례
      • 인터페이스는 사용자와 끝없이 대화한다
  5. 끝

티스토리툴바