예전의 SaaS 기획은 비교적 명확한 역할 분업을 전제로 했다. 기획자는 문제를 정의하고, 설계자는 구조를 만들고, 디자이너는 화면을 그리고, 개발자는 구현한다. 이 과정에서 기획자나 설계자가 디자인을 잘 몰라도 큰 문제는 없었다. "사용자 입장에서 불편하지 않게 만들어 주세요"라고 요청하면, 그걸 구체화하는 역할은 디자이너의 몫이었기 때문이다.
하지만 지금은 상황이 다르다
기술의 진입장벽이 낮아지면서 역할의 경계가 빠르게 흐려지고 있다. 노코드·로우코드 도구, AI 기반 생성 도구, 템플릿 중심의 개발 환경이 보편화되면서 SaaS를 기획하는 사람과 만드는 사람이 분리되지 않는 경우가 늘고 있다. 혼자서 기획하고, 구조를 짜고, 화면을 만들고, 배포까지 하는 상황에서 더 이상 "디자인은 디자이너의 영역"이라고 말하기는 어렵다.
그래서 중요한 건 '디자인을 잘하는 능력'이 아니다
여기서 말하는 디자인 이해는 포토샵을 잘 다루는 능력도 아니고, 컬러 감각이 뛰어난 미적 재능도 아니다.
핵심은 디자인을 '결과물'이 아니라 '사용자 경험의 언어'로 읽어낼 수 있는 능력이다.
이 버튼은 왜 여기 있을까?
이 화면에서 사용자는 무엇을 먼저 보게 될까?
이 정보 구조는 사용자의 사고 흐름과 맞을까?
클릭 한 번을 더 요구하는 순간, 사용자는 어떤 감정을 느낄까?
이 질문들을 던질 수 있느냐가 디자인 이해의 출발점이다. 즉, 디자인은 만드는 기술이 아니라 판단하는 기준에 가깝다. 이런 질문을 일상적으로 던질 수 있다면, 좋은 디자인을 알아보는 감각은 자연스럽게 따라온다.
기획자·설계자에게 디자인 감각이 필요한 진짜 이유
기획자나 설계자가 "사용자 입장을 고려했다"라고 말할 때, 그 말은 대부분 추상적이다. 사용자 친화적이다, 직관적이다, 깔끔하다. 하지만 이 표현들은 디자이너에게 넘기는 순간 해석의 문제가 된다. 반면, 디자인을 이해하는 기획자는 요청 방식부터 다르다.
사용자가 이 단계에서 멈출 가능성이 높다
정보가 많아지면 여기서 이탈한다
이 기능은 '보여주기'보다 '숨기는 것'이 낫다
이건 미적 취향의 문제가 아니라 행동 예측의 문제다. 디자인 감각은 곧 사용자의 행동을 미리 시뮬레이션하는 능력이다.
예를 들어보자. 같은 회원가입 기능이라도, 한 서비스는 화면 상단에 "무료 체험", "시작하기", "가입", "데모 보기", "문의하기" 버튼을 다섯 개나 배치한다. 다른 서비스는 사용자가 관심을 보이는 순간, 딱 하나의 명확한 액션만 제시한다. 어느 쪽이 실제로 더 많은 전환을 만들어낼까? 디자인을 이해한다는 건 이 차이를 설명할 수 있다는 뜻이다.
1인 SaaS 시대, 디자인은 선택이 아니다
앞으로 SaaS를 만드는 사람에게 가장 중요한 역량 중 하나는 "완벽한 기능 구현"이 아니라 "보는 순간 이해되는 구조"를 만드는 힘이다. AI는 코드를 대신 써주고, 화면도 대신 만들어 준다. 하지만 무엇을 보여주고, 무엇을 감출지 결정하는 기준은 여전히 사람의 몫이다. 그리고 그 기준이 바로 디자인에 대한 이해다.
디자인을 이해하지 못한 채 만드는 SaaS는 기능은 있지만, 사용되지 않는다. 반대로 디자인을 이해하는 사람이 만든 SaaS는 기능이 적어도, 계속 쓰인다.
그래서 무엇부터 시작할까
거창한 디자인 공부를 시작할 필요는 없다. 대신 이렇게 해보자.
매일 쓰는 서비스를 분석하라. 노션, 슬랙, 피그마, 구글 독스. 이 서비스들이 왜 편한지, 어떤 순간에 막힘 없이 흐르는지 의식적으로 관찰하라. 버튼의 위치, 정보의 순서, 색의 강약, 여백의 역할. 그냥 쓰지 말고, 뜯어보라.
나쁜 경험을 기록하라. 불편했던 순간, 헷갈렸던 화면, 클릭을 망설였던 버튼. 그 순간의 감정과 이유를 메모해 두면, 그게 곧 디자인 판단의 기준이 된다.
만들기 전에 그려보자. 종이든 피그마든 상관없다. 머릿속 아이디어를 화면으로 옮기는 순간, 애매했던 생각이 구체적인 문제로 드러난다. 그 과정에서 디자인은 자연스럽게 학습된다.
디자인은 제품을 만드는 사람이라면 누구나 가져야 할 기본 언어다. 그리고 그 언어를 익히는 가장 빠른 방법은, 매일 보고 쓰는 것들을 조금 더 의식적으로 바라보는 것이다.