Riido 프로젝트는 KHUX와 SWYG 산학협력에서 진행한 UX 컨설팅이었습니다. 저는 이미 운영 중인 생산성 서비스의 템플릿 관리 경험을 보며, 화면의 미감보다 사용자가 상태를 이해하고 다음 행동을 고를 수 있는지를 중심으로 개선안을 만들었습니다.
운영 중인 제품을 보는 태도
새 서비스를 기획할 때와 운영 중인 서비스를 개선할 때는 질문이 다릅니다. Riido에서는 "무엇을 새로 만들까"보다 "이미 있는 흐름에서 어디가 끊기는가"를 먼저 봐야 했습니다. 그래서 저희는 Riido AI, 회의 추가 플로우, 템플릿 개선, 작업 현황 페이지처럼 사용자가 반복해서 만나는 지점을 나눠 살폈습니다.
운영 중인 제품에는 이미 쌓인 규칙과 제약이 있습니다. 그래서 제안도 새 화면을 마음대로 붙이는 방식이면 안 됩니다. 저는 기존 흐름 안에서 사용자가 무엇을 보고, 어떤 상태라고 이해하며, 어떤 버튼을 눌러야 한다고 느끼는지를 따라가려고 했습니다.
발견한 문제
가장 크게 보인 것은 UI 톤과 UX writing의 흔들림이었습니다. 같은 종류의 상태가 화면마다 다르게 보이거나, 동적으로 바뀌는 상황을 문장이 충분히 설명하지 못하면 사용자는 기능을 못 쓰는 것이 아니라 망설이게 됩니다. 특히 AI가 개입하는 서비스에서는 결과가 생성 중인지, 수정 가능한지, 저장됐는지 같은 상태가 더 중요합니다.
템플릿 관리 화면도 단순한 목록이 아니었습니다. 사용자는 템플릿을 찾고, 만들고, 적용하고, 수정하면서 계속 상태를 판단합니다. 문구 하나가 모호하면 사용자는 "지금 저장된 건가", "바로 적용되는 건가", "다시 되돌릴 수 있나"를 알기 어렵습니다. 저희는 이 지점을 UX writing과 UI guideline의 문제로 정리했습니다.
제안으로 정리한 것
개선안은 UI 가이드라인, UX writing 원칙, AI 서비스 벤치마킹, 상호작용 제안으로 나눠 정리했습니다. 저는 문구와 구조가 따로 움직이지 않도록, 사용자가 보는 상태와 문장이 같은 방향을 가리키게 만드는 데 신경 썼습니다. 예를 들어 버튼 이름 하나를 바꾸는 것도 단순한 카피 수정이 아니라, 사용자가 지금 저장하는지, 생성하는지, 적용하는지 구분하게 만드는 설계였습니다.
AI 서비스 벤치마킹도 "비슷한 기능을 가져오자"가 아니었습니다. AI가 결과를 만드는 동안 사용자가 기다리는 방식, 결과를 확인하는 방식, 수정하거나 재생성하는 방식이 Riido의 작업 맥락과 맞는지 보려고 했습니다. 제안의 목표는 화려한 AI 인터랙션이 아니라, 템플릿 관리에서 불안한 순간을 줄이는 것이었습니다.
배운 점
이 프로젝트의 결과물은 구현 코드가 아니라 컨설팅 제안이었습니다. 그래서 성과를 과장하기보다, 운영 중인 제품에 제안을 넣을 때 어떤 언어가 필요한지 배웠다고 말하는 편이 정확합니다. 좋은 UX 제안은 "이 화면이 별로입니다"에서 끝나지 않습니다. 왜 헷갈리는지, 어떤 원칙으로 바꿀지, 제품의 기존 제약 안에서 무엇부터 손볼지까지 말해야 합니다. Riido는 제가 그 감각을 익힌 프로젝트였습니다.
