2024. 1. 10. 17:23ㆍ기록/회고
1인 UX/UI 디자이너로써 다양한 프로젝트를 경험했다. 그 중 가장 기억에 남는 것은, 반응형 웹 디자인이었다.
사수없는 비전공자인 1년차 주니어 UX/UI 디자이너로써, 어떻게 반응형 웹 디자인을 했는지 그 과정과 임기응변(?), 그리고 회고를 해 보고자 한다.
1. 현업에서의 기회
우연한 기회로 반응형 웹을 설계하게 되었다. 사수도 없었고, 처음 접해보는 반응형 프로젝트였다.
평소에 UX/UI 강의를 듣는 편이었고, 다행히 반응형 강의를 들은 경험이 있었다.
당시 구성된 팀은 브랜드 디자이너 1명과 UX/UI디자이너 1명, 그리고 프론트 개발자 2명이었다.
브랜드 디자이너는 UX/UI와 개발 구현의 경험이 전무했고, 프론트 개발자 분도도 처음으로 반응형을 맡게된 상황이었다.
또한 오프라인 제품 오픈 일정에 맞춰 구축되어야 했기 때문에 일정은 매우 촉박할 수 밖에 없었다. 관련해서 브랜드 디자이너와 논의 끝에 메인페이지를 비롯한 골격은 UX/UI 디자이너인 내가 잡고, 2개의 서브 페이지는 브랜드 디자이너가 담당하는 것으로 진행되었다.
2. 사이즈 설정
모바일 사이즈는 갤럭시 폴드를 생각해서 320부터 잡는 것이 맞지만, 서브 페이지의 디자인을 파악했을 때 320에 담겨지기 어려웠다.
이를 해결하기 위해, 나는 간단하게 개발 구현과 사용성을 높이기 위한 설명을 하며 설득을 시도했다. 어느 부분은 수용되었지만, 320에 담을 수 있을 정도로 디자인이 변모되지는 못했다.
320에 담겨진다면, 제시된 이미지의 통일성이 깨지고, 폰트 스크롤이 매우 길어질 수 밖에 없는 상황이었다.
고민 끝에 나는 홈페이지에 진입하는 고객의 주 기기를 확인했다. 폴드 보유자가 낮고, '오픈일에 맞춰 구축되어야 한다'는 프로젝트의 최우선 목표와 일정이 매우 촉박하다는 현재의 상황을 고려하여 이번 프로젝트에서는 과감히 320은 제외하는 것으로 결정했다. (하지만 고도화 때는 폴드까지 고려된 디자인으로 잡아나가야할 것이다.)
그렇게 모바일은 360~767까지 사이즈를 설정했다.
태블릿은 768~1200까지 설정했다. 그 이유는, 아이패드의 사이즈가 768이었기 때문이다.
하지만 서브페이지의 디자인이 변경되어, 태블릿의 최소 사이즈를 640으로 재설정 하기도 했다. (결국 다시 기존 디자인으로 진행하는 것으로 되어 768로 최종 결정되었다. - 다행히도 변경된 시점에는 모바일만 개발이 진행되고 있었다.휴...)
웹사이트의 경우 1200~ 반응되는 것으로 사이즈를 설정했다.
일반적으로 1440, 1920으로 잡는 경우가 많은 것 같지만, 반응형이기 때문에 최소 사이즈만 잡으면 되었다.
다만, 가장 보편적으로 보여질 사이즈인 1440에서는 1:1로 보여질 수 있도록 신경을 많이 썼다.
3. 피그마의 속성 값
반응형 뿐만 아니라 어떤 프로덕트를 피그마로 만들 경우에 해당되는 내용일 것이다.
피그마의 요소는 Fill과 Fix, hug에 따라 반응될 때의 형태가 달라진다. 특히 이 속성은 반응형에서 매우 중요하다.
속성값에 따라 반응 사이즈에서 보여지는 것이 달라지기 때문이다. 꼭 어떻게 보여지는지 확인하며 디자인 의도에 맞게 속성값을 주는 것이 중요하다.
만약 피그마 내에서 아무리 설정을 해도, 디자인 의도대로 보여지지 않는다면 별도로 따로 기재하여 개발팀이 알 수 있도록 했다.
(대체적으로 피그마 코멘트에 기재했지만, 중요한 사항들은 요소의 바로 옆이나 큰 폰트로 상단에 배치해 잘 보일 수 있도록 했다.)
4. 브레이크별 마진
반응형의 목적은, 어떤 사이즈로 봐도 일관성 있는 경험을 사용자에게 제공하기 위함에 있다.
그래서 초반에는 이 부분이 헷갈렸다.
결론부터 말하자면, 마진은 동일하게 가져가지 않아도 된다.
개발 공수가 큰 항목도 아니지만, 기기별 특징으로 인해서 별도로 가져갈 수 밖에 없는 상황이 되버린다.
(모바일 환경과 웹의 환경에서 보편적으로 사용되는 값을 생각하면 된다.)
하지만 스페이싱은 명시하는 것이 개발 편의를 위해서 설정되는 것이 좋다.
5. 폰트 사이즈
위의 반응형 목적을 본다면, 당연하게 폰트는 동일하게 가져가야 하는 것 아닌가? 라는 생각이 들 것이다.
하지만, 폰트 사이즈는 묶을 수 있는 것은 최대한 묶고, 별도로 가져가야하는 것만 별도로 설정하는 게 좋다.
모바일에서 사용되는 폰트 사이즈와 웹에서 사용되는 폰트 사이즈는 다른 경우를 생각해 보면 된다.
(물론 동일하게 가져가는 경우도 있기도 하다.)
아래는 정답은 아니고, 보편적인 수치이다.
본문 폰트
- 모바일 : 14~16px
- 웹 : 16~18px
헤드 폰트
- 모바일 : 20~24px, (더 크면 28까지도 간다)
- 웹 : 28~최대 40px (32px도 큰 편이기는 하지만, 요즘 40도 은근 보이는 편이다)
이런 식으로 폰트 사이즈는 환경에 따라 다르게 가져갈 수 밖에 없다.
하지만, 폰트 스타일은 동일하면서도 단일이 좋다.
(영문 혹은 숫자 별도로 포함하여 최대 2개가 이상적이다. 이는 IT프로덕트에 모두 적용된다.)
6. 묶는다는 것의 의미
간략하게 정리하자면, 반응형의 경우 별도로 가져가는 것은 별도로 하되, 묶을 수 있는 것은 최대한 묶어서 가져가면 좋다.
그것이 폰트이든, UI 사이즈든, 패딩이든 말이다.
다시 한번 말하지만, 반응형의 목적은 일관성 있는 경험을 위한 것이다. 그렇기 때문에 환경에 따라 별도로 가져가는 불가피한 상황이 일어날 수 밖에 없다. 그러나, 이 의미는 모든 것을 다 별도로 가져가야 한다는 것은 아니다.
묶어야 하는 이유는 단순하다. 그래야 일관적인 디자인을 경험할 수 있고, 효율적인 개발과 디자인을 할 수 있기 때문이다.
환경 별 나눠서 디자인과 개발을 하는 것은 1개의 페이지를 만드는 것이 아닌, 3개의 페이지를 만드는 것이 되버린다.
즉, 굉장히 비효율적인 방법이다.
대체로 태블릿&웹을 묶는 경우가 많고, 이 두 환경은 모바일과 다르게 그 격차가 크지 않다.
물론 모든 요소, 구성의 태블릿&웹을 묶어야 한다는 정해진 규칙은 없다.
디자인에 따라 어떤 요소는 별도로 가져갈 것인지를 판단하고, 설정값을 직접 결정해야한다.
이 부분은 많이 경험하면서 알 수 밖에 없는 사항이다.
7. 커뮤니케이션 리딩
현업에서 프로젝트를 진행할 때마다 매번 깨닫는 것은, 커뮤니케이션의 중요도이다.
위에서 언급했듯이, 당시 프로젝트는 구현에 대한 이해가 전무한 브랜드 디자이너와 함께 했다. 또한 분할 작업으로 이뤄졌기 때문에, 개발자와 브랜드 디자이너의 중간에서 커뮤니케이션도 담당했다.
사수도 없었고, 개발과 브랜드 디자인 모두 이해하는 사람은 나 밖에 없었기에, 자연스럽게 중간에서 커뮤니케이션을 리딩했었다.
(이하 브랜드 디자이너는 '브디'로 기재하겠다.)
당시 나의 커뮤니케이션 과정은 이러했다.
1. 브디가 디자인 제안 -> 구현 여부 파악(직접 판단 or 개발팀 확인 요청) -> 개발팀 가능 여부 파악 내용 전달
2. 개발팀에서 구현 불가로 인한 수정 제안 -> 브디에게 내용 전달, 아이디어 제공 -> 브디의 의 결정 or 디자인 수정
당시 브랜드 디자인과 개발 구현의 이해도가 있는 사람은 나 밖에 없었기에, 자연스럽게 중간에서 커뮤니케이션을 리딩했었다.
이 과정에서, 설득과 커뮤니케이션의 쿠션어, 그리고 개발에 대한 이해도를 많이 이해하게 되었다.
브디에게는 개발 구현에 대한 원리 설명과 함께 디자인 수정 제안을 위한 설득도 필요했고, 왜 현재 상황에서 개발이 어려운지, 해당 디자인이 왜 구현이 어려운지에 대해서 함께 설명해야 했다. 그래서 모르는 부분은 개발자 분에게 물어봐서 확인하는 과정을 거칠 수 밖에 없었다.
중간에서 홀로 커뮤니케이션을 리딩하는 것에 어려움을 느끼기도 했지만, 결과적으로는 이해도를 넓힐 수 있는 경험이었다.
개발팀과의 커뮤니케이션은 나에게 있어 더 없이 값진 경험이 되었다. 구현이 어려운 디자인은 오히려 문제를 해결하기 위한 논의로 이어지게 되었다. 개발자 분이 특정 구간에서 어떠한 현상이 일어나면 그것에 대해 논의가 되었고, 상황에 따라 결정의 순간들이 왔다.
촉박한 일정이 주는 장점은, 빠르게 실속있는 해결책을 찾아낸다는 것일거다. 우리의 대부분의 결정은 최소한의 공수로 해결할 수 있는 방법이었다. 그것이 디자인이나 UX를 조금 변형하게 된다고 하더라도 나는 그 방법으로 결정했다.
그 이유는, 프로젝트의 핵심 목표는 빠르게 선 배포를 한다는 것이었기에, 차후 고도화가 예정되어 있었다. (고도화가 될 수 밖에 없는 상황이기도 했다.)
물론 그렇다고 해서 완전히 사용성을 낮추는 방법으로 채택은 당연하게 하지 않는다.
프로젝트와 상황과 사용성으로 인해 사용자 시나리오를 빠르게 생각하여 최적의 방법으로 결정하기 위해 신경썼다.
단순하게 설명하자면 이런 해결법들을 결정했다.
- 이미지 크기를 조금 줄여서 줄바꿈이 일어나는 현상을 해결한다.
- 문제되는 구간에서만 마진을 조정한다.
- 폰트와 이미지가 별도인 것을 이미지로 통합해서 묶는다.
이렇게 아주 단순한 방법을 찾아 해결해 나갔다. (워딩으로만 보면 매우 단순한데, 당시엔 개발자와 함께 고민을 했었다.)
물론 디자이너이기에, 이런 상황 속에서도 크리티컬한 디자인 디테일은 놓치지 않기 위해 개발팀에 의뢰한 경우도 몇 있다.
이 경우엔, 개발팀의 가능 여부를 먼저 확인 후 의견을 공유하는 과정으로 진행했다. 개발팀에서는 의견을 듣고 가능 여부 혹은 의견과 이유를 말해주었다.
이렇게 우리는 빠르게 의견을 나누고 해결법을 결정해 나갔다.
8. 결과
우여곡절 끝에 배포가 되었다.
골격과 메인페이지를 담당했지만, 후반부에 들어서 브랜드 팀의 시각 기준으로 변경되어 전반적으로 UX/UI가 많이 고려되지 못한 결과물이었다. 이 부분에 있어서는 나름대로 이유와 함께 설득을 시도했지만, 사내 상황으로 반영되기엔 어려움이 있었다.
하지만 그럼에도 각자 나름대로 논의와 이해를 거쳐 나왔기에 개발팀에 감사함이 너무나 컸다. (정말 고생이 많으셨다..ㅠㅠ...)
처음 마주했을 때 뿌듯함이 느껴졌다면 정말 좋았겠지만, UX/UI 디테일의 오류, 낮은 사용성에 대한 우려가 먼저 보이고 찾아나서게 되는 것은 어쩔 수 없는 것 같다.
9. 회고
이렇게 나의 반응형 페이지에 대한 경험이 마무리 되었다.
과정을 진행하면서 답답함이 없었다면 거짓말일 것이다. 그리고 어려움도 없었다면 그 또한 거짓말일 것이다.
그럼에도 불구하고, 커뮤니케이션과 프론티 개발 지식에 관한 이해력의 깊이가 한층 더 넓어지게 되는 경험이었다.
개발팀에 핸드 오프할 때 어디까지 신경써야 하는지, UX/UI에 대한 이해도가 낮은 팀과의 커뮤니케이션은 어떻게 해야하는지 등 짧은 기간이었지만 여러가지를 꺠달을 수 있었다.
신경쓸 요소들이 많지만, 그 만큼 재미있는 것이 또 반응형 디자인인 것 같다.
반응형 사이즈에 대한 내용은 아래 아티클에 자세하게 나와있다.
참고해 보면 좋을 것이다.