디자인 개발을 모르는 디자이너가 GitHub PR을 설계하게 되었을 때 1/ 개발 지식이 없지만 GitHub를 설계해야 한다면, 무엇부터 이해해야 할까요? PR 제목과 상태만 보이던 기존 흐름에서는 ‘무슨 작업인지’, ‘왜 시간이 걸리는지’ 알 수 없었습니다. 이 한계가 프로젝트 관리자의 효율적 의사결정을 막고 있었고 이는 프로젝트 지연으로 이어졌습니다. 그래서 GitHub PR 내용을 뤼이도로 가져오는 것을 설계해야 했습니다. 하지만 저는 GitHub를 써본 적이
디자인 왜 라벨을 고치기 전에 '문제'부터 다시 정의했을까 1/ 단순한 태그처럼 보이지만, 작업을 이해하는 방식입니다 뤼이도에서 라벨은 작업 옆에 붙는 단순한 입력 값이 아닙니다. 어떤 팀에게 라벨은 * 우선순위(P0,P1)이고 * 어떤 팀에게는 작업의 성격(디자인, 프론트엔드, 백엔드)이며 * 또 다른 팀에게는 배포 단위나 이슈의 맥락이 되기도 합니다. 즉, 라벨은 각 팀이 작업을 어떻게 분류하고, 무엇을 중요하게 보고,
디자인 사용자의 '첫 이탈'을 막은 방법: 회원가입 과정 개선하기 “회원가입하다가 귀찮아서 그냥 닫아본 적 없으신가요?” 대부분의 SaaS는 이 첫 화면에서 사용자를 잃습니다. 뤼이도 역시 예외는 아니었습니다. 저는 뤼이도 합류 전, 순수한 사용자로 처음 접했을 때 회원가입부터 실제로 일을 시작하기까지의 과정이 유난히 길게 느껴졌습니다. 입사 후 이 경험이 개인적인 인상이었는지 확인하기 위해 데이터를 살펴보았고, 실제로 많은 사용자가 온보딩 단계에서 이탈하고
