목차

1. 주장 입증하기
2. 계획 세우기
3. 사이트 속도 높이기
4. 콘텐츠 정리하기
5. 협업하기
6. 테스트와 평가

2. 계획 세우기

스마트폰이나 태블릿에서 간단하고 효과적인 경험을 제공하기 위해 전체를 뜯어고치려면 전략적인 계획이 필요하다.
하지만 이를 능숙하게 해내는 기업은 아직 많지 않다.
- 이컨설턴시와 어도비 공동 연구, <모바일 성장을 위한 경로 찾기>

반응형 프로젝트는 단순히 웹사이트 제작에만 영향을 미치는 것이 아니라 팀을 훈련시키는 효과가 있다.
새로운 프로세스를 적용하고 조직에 새로운 문제 해결 방식을 교육하는 이런 활동이야말로 완성된 웹사이트가 다양한 기기에서 작동하게 되는 것보다 훨씬 더 큰 가치를 지닌다.

ROI 개념에서 계획에 소요되는 비용보다 그 계획을 통해 얻을 가치가 중요하다는 것을 잘 알 것이다.

반응형 리디자인을 성공한 기업들은 단순히 스마트폰에서 잘 작동하는 웹사이트를 완성한 것보다 더 큰 소득을 올렸다고 말한다.

바로, 기업의 사고방식과 업무 방식의 변화다.

2.1 범위 정하기

반응형 디자인에 반드시 더 많은 시간과 비용이 든다고 생각하는 사람들이 많다.

포레스터가 앱 개발과 출시를 담당하는 리더와 그들의 에이전시 파트너에게 수집한 정보에 따르면
전통적인 데스크톱 웹디자인보다 반응형 웹디자인에 20~50% 더 많은 수고가 따른다.
- 포레스터 보고서

20~50% 늘어나는 부분은 어디일까?

2.1.1 프로젝트 계획하기

반응형 프로젝트를 계획할 때도 웹디자인의 기본 원칙이 그대로 적용된다.

일단 여러분이 새로운 프로세스 도입에 대한 초반의 반발을 극복하고 나면 반응형 사이트 설계나 구축에 시간이나 비용이 더 들지는 않는다. 진짜 장애물은 자기 방식대로만 일하려는 디자이너와 개발자다.
- 제이 스톡스, 어도비 Typekit의 크리에이티브 디렉터

그렇다면, 20~50% 정도 늘어나게 된 변화는 무엇일까?

• 새로운 기술을 교육하기(디자이너, 개발자에게 점진적 향상이나 성능 최적화 기술)
• 기존 콘텐츠를 정리하고 줄이기(모바일 기기에서 작동하지 않는 PDF나 플래시 동영상 파일 변환 작업도 포함된다.)
• 의사결정 과정이 어떻게 변하는지 조직 전체에 교육하기(고정 폭 레이아웃 설계에서 가변적 설계로 변경하면서)
• 결과물보다 프로토타입 제작에 집중하는 작업 방식으로 변환하기(조직 전체에 더 협력을 필요로 하는 반복적 작업 방식 지도하기)
• 여러 브라우저, 기기 유형, 방향에 걸쳐 웹사이트를 테스트하기

초반에 작업 범위를 설정하고 정확한 추정치를 제공하는 것이 일종의 규칙이 되었다.
(...중략...)
실제 어떻게 동작할지 알아내기 위해 사람들과 이메일이나 스카이프로 연락하는 시간이 줄어들었다.
프로토타입이 실제 작동하는 모습을 바탕으로 설계를 이해할 수 있게 되었기 때문이다.
- 브래던 로세이지, Ushahidi의 크리에이티브 디렉터

2.1.2 장기적인 반응형 예산 계획

반응형 웹사이트로 리디자인시에는 실제로 조직이 하는 일이 늘어나기 때문에 비용도 늘어나는 것이라는 사실을 명심하라.

반응형 프로그램은 여러 문제를 고칠 훌륭한 기회이기도 하다. 사실 이것이 아주 큰 장점이었다.
- 리비아 리베이트, 매리엇

어떤 사항들이 늘어나는 것일까?

• 설계 시스템과 패턴 라이브러리를 만들거나 보강하기.(만들어두면 재사용으로 인해 장기적으로 볼 때 비용이 절감된다.)
• 콘텐츠 관리 시스템, 전자상거래 시스템 등 기존 백엔드 시스템을 교체하기
• 새로운 API, 디지털 자산 관리 시스템을 비롯해 모바일 기기를 지원하기 위한 그 밖의 미들웨어 실행하기.

2.2 반응형 디자인 공개하기

반응형 리디자인을 성공적으로 공개하는 데 단 하나의 정답이 존재하지 않는다.

• 기존 데스크톱 사이트 고객이 얼마나 걱정되는가?
  언론사 같은 일부 조직은 베타 버전을 출시하지 않고 상대적으로 자주 설계를 바꾼다.
  반면 은행과 같은 적응할 시간을 주지 않고 큰 변화를 도입해서 기존 고객의 불만을 일으키는 위험을 감수할 수는 없다고 생각하는 조직도 있다.
• 리디자인 대상이 웹 앱인가?
  웹 앱도 반응형으로 만들 수 있다. 다만 표로 정리한 대량의 데이터, 복잡한 폼으로 구성된 트랜잭션 흐름, 레거시 백엔드 시스템과의 까다로운 통합 등 난해한 작업이 포함된다면 시간이 추가로 들 것을 고려해야 한다.
• 콘텐츠에 변화를 줄 계획인가?
  반응형 리디자인은 기존 콘텐츠를 정리하고 줄일 아주 좋은 기회다.
  단, 모든 것을 한 번에 할 수 없음을 알고 콘텐츠 정리를 단계적으로 진행하는 조직이 많다는 것을 참고하길 바란다.
• 새로운 CMS나 API를 적용할 것인가?
  배포 시스템을 이전화는 과정에서 반응형으로 훨씬 쉽게 전화했다고 말하는 조직이 많다.
  하지만 새로운 CMS와 반응형 디자인 중 무엇을 먼저 도입할 것인지를 정해야 한다.
  두 가지 작업을 동시에 하려면 시간도 더 많이 들고 위험부담도 커진다.
• 이해관계자들이 검토 프로세스를 진행할 준비가 되어 있는가?

이러한 질문에 답할 수 있다면 반응형 디자인 도입 방법을 고려할 차례다.

2.2.1 보강

웹사이트를 반응형 디자인으로 보강하는 것

보강 작업이 효과적인 3가지 경우가 있다.

1. 콘텐츠가 (크게) 변하지 않는다.
2. 복잡한 웹 앱을 리디자인할 필요가 없다.
3. 이미 컴포넌트화된 프레임워크가 존재한다.

보강한 웹사이트를 잘 공개하는 방법은 무엇이 있을까?

• 반응형 팀에 '데스크톱을 건드리지 마라'는 명령같은 가이드라인은 팀의 권한을 매우 제한한다. 이런 강박관념 때문에 소형 화면에 잘 맞는 설계를 포기하는 결과로 이어진다.
• '데스크톱을 망가뜨리지 마라'는 말이 조금 더 현실적이고 성취가능성이 높은 목표다.
• 현실적인 기대치를 설정하고 장기적으로 변화를 줄 계획을 세우자.
• 한 섹션을 선택해서 반응형 디자인을 완벽하게 적용하는 것도 고려해보자.
  보강한 부분과 비교해볼 수 있다. 그리고 팀원들이 프로세스를 경험할 수 있고, 작업 범위 설정에 참고할 수 있도록 어느 정도의 수고가 드는지 파악하고, 보강한 결과물과 완전히 리디자인한 결과물이 각기 어떻게 작동하는지 비교할 실제 데이터를 얻게 된다.

2.2.2 베타 출시

'영원한 베타'라는 개념은 오늘날 지속적인 개발과 테스트를 지원하기 위해 많은 앱에서 사용되는 지속적 배포의 전조였다.
'평행 배타'방식은 개발과 검토에 많은 시간과 수고가 요구된다. 대신 리디자인을 천천히 공개하는 동안 사용자의 피드백과 분석 자료를 모을 수 있다는 것이 장점이다.

우리는 초반에 사람들이 잠시 와서 경험해볼 수 있는 베타 사이트를 만들었다.
사용자들은 이 사이트를 잠시 사용해보고 원래 사이트로 되돌아갈 수 있었다.
베타 사이트 제작에 추가적으로 엄청난 수고가 들기는 했지만 수백만의 열정적인 고객이 있는 사이트에 리디자인을 바로 적용하는 것은 그다지 현명한 방법이 아니었을 것이다.
다양한 변화를 빠르게 시도하고 많은 사용자의 피드백을 받을 수 있었던 것은 베타 사이트 덕분이었다.
- 스티븐 투르베크, 피델리티

베타를 성공적으로 출시하기 위해 필요한 사항은 다음과 같다.

• 조직 내에 테스트를 통해 배우는 문화가 조성되어야 한다.
• 기술적 아키텍쳐와 배포 인프라를 갖추어서 사용자가 베타 사용 여부를 정할 수 있게 해주어야 한다.(여기에는 큰 비용이 들 수 있다.)
• 이해관계자들이 동의해야 한다.(기존 사이트과 베타 사이트 2개를 유지하며 양쪽의 트래픽을 관리하는 데 투자할 의지를 보여야 한다.)
• 다양한 폼펙터를 대상으로 하는 품질 보증 테스트(QA)는 기하급수적으로 복잡해지고 있다. 두 사이트의 QA를 동시에 진행할 때 드는 시간과 인력을 과소평가해선 안 된다.
• 베타를 단계적으로 공개하면 베타에 접속하는 사람을 제어하는 데 도움이 된다.
• 초기 피드백은 부정적일 것으로 예상하는 편이 좋다. 사실 이런 피드백을 빨리 수집하는 것이 베타의 핵심이다.

2.2.3 모바일 전용 반응형 디자인

반응형 웹사이트를 다양한 스마트폰이나 태블릿 사이즈에 맞추어 개발하고 데스크톱 사용자만 기존 고정폭 사이트를 쓰게 하는 공개 전략도 있다.

모바일 전용 반응형 사이트 전략을 택하면 더 크고 복잡한 문제에 집중할 시간을 벌 수 있다.
하지만 서버 리디렉션으로 인한 성능 저하 등 여러 고려해야 할 사항이 있다.

• 단계적으로 공개하지 않더라도 모바일 전용 반응형 사이트를 베타로 정의해야 한다. 점진적으로 수정해아 나가면서 데스크톱 사용자에게 단계적으로 공개할 준비도 돼 있어야 한다.
• 콘텐츠와 기능을 단호하게 정리해야 한다. 단호하게 정리할 자신이 없다면 그냥 보강하는 방식을 사용하면 된다.
• 반응형 웹사이트를 성공적으로 구현하는 방법을 다른 직원들에게 가르쳐야 한다.
• 진짜 웹사이트를 만들어야 한다. '모바일' 웹사이트를 만드는 과정에 불과하다고 치부하지 말고 결국 데스크톱 사이트를 대체할 사이트를 만드는 과정이라고 보아야 한다.
• 데스크톱 사이트 투자를 멈춰야 할 시점을 알야아 한다. 데스크톱에 할당했던 자원도 반응형 사이트로 옮겨와야 한다.

2.2.4 섹션별 적용

특정 세션을 정해서 시작하는 방법

그럼 어떤 섹션에서 시작해야 할까?
다양한 선택지가 있다.

• 인기가 많지 않은 섹션
• 모바일 트랙픽이 불균형하게 많이 발생하는 섹션
• 홈페이지

다른 사이트들은 대체로 상향식 방법이나 눈에 잘 띄지 않는 섹션을 고르는 방식을 사용한다.
(...중략...)
대상이 홈페이지였던 덕에 상당히 시선을 끌었다.
비인기 섹션을 골라서 시작했다면 그렇게까지 눈에 띄긴 어려웠을 것이다.
클릭 한 번으로 반응형 경험이 사라져버렸을 테니 사용자로서는 좀 괴로웠을지 모르나
회사 내외부에서 정치적, 조직적으로 큰 반향을 일으켰다는 것이 중요하다.
나는 우리의 선택에 만족한다.
- 크리스 볼트, 마이크로소프트

섹션별로 공개할 때 고려해야 할 사항은 다음과 같다.

• 사이트의 다른 부분에서 발생하는 문제나 디자인 패턴이 '반영된' 섹션을 선택해야 한다.
  단순한 페이지는 쉽게 완성할 수 있기는 하지만 더 복잡한 문제를 다룰 방법을 배우기는 어려울 것이다.
• 핵심에 집중해야 한다.
  트래픽과 사용 현황 데이터를 보고 사용자에게 가장 중요한 페이지나 섹션이 어디인지 알아내고 그곳에 에너지를 집중해야 한다.
• 리디자인에 추가적인 수고가 드는 부분에 대해 직접적인 이해관계자의 동의를 확실히 받아두어야 한다.
  이들은 이 결정에 대한 이유를 팀원들에게 알리고 방어하는 역할을 해야 한다.
• 향후 계획을 세울 때 참고할 수 있도록 업무의 내용을 추적하고 기록해야 한다.
• 조직 전반에 영향을 미치는 결정을 내릴 때는 모두를 염두에 두어야 한다.
  다양하게 영향을 미치기 때문에 다양한 문제가 생길 수 있다는 것에 모두가 동의해야 한다.

2.3 조직 변화시키기

조직의 의사결정 방식을 고려한 반응형 리디자인 공개 계획을 완성했다.
예상보다 비용과 시간이 더 들어도 괜찮다는 동의도 얻었다.
다른 직원들이 맡은 역할에 변화가 생길 수 있다는 사실도 설명했다.

반응형 설계는 단순한 설계방식이 아니다.
알고 보면 업무 방식이나 협업 방식을 재고하고 조정하는 조직 수준의 변화를 요구한다.
- 트라이 브런드레트, Vox Media의 최고 제품 책임자

그렇다면 조직의 구조를 조정하고, 보고 체계를 수정하고, 새로운 직무를 수행할 직원을 선발할 계획을 어떻게 할 것인가?

2.3.1 모바일 팀 통합

스마트폰이 처음 나왔을 때 많은 기업이 '모바일' 팀을 구성했다.

하지만 모바일이 전체 트래픽의 50%가 된 후 이런 접근법은 수명을 다했다.

팀이 조직된 방식이 문제의 원인이다.
그동안 모바일 팀은 분리된 상태에서 모바일에 대해서만 생각하고 말하는 역할을 맡았다.
그래서 이들은 다양한 플랫폼에서 자연스럽게 경험이 이어질 수 있는 방법에 대해 고민하지 않았다.
네이티브 앱과 웹이 완벽히 분리되었고 웹은 데스크톱 정도로 여겨졌다.
- 빌 W.스콧, 페이팔

모바일은 사용자 경험이 조직의 구조를 그대로 반영해서는 안 된다는 것을 보여주는 또 하나의 예가 되었다.

2.3.2 디자이너와 개발자 통합

반응형 리디자인 관련 계획을 완성하려면 놀랍게도 디자인 팀, 개발 팀 개편까지 해야 한다.
반응형 리디자인 프로젝트에서는 이것이 성공 여부를 판가름하는 핵심이다.

"포토샵 파일이나 설명서를 만들어서 개발자에게 던져버리는 방식으로는 일이 진행되지 않는다."

더 좋은 제품을 만들고 싶다면,
개발 주기가 더 짧아지길 원한다면
개발 팀에 UX 전문가를 두고 정상적으로 작동하는 웹사이트 완성이라는 하나의 목표를 공동으로 책임지게 해야 된다.
- 톰 매슬런, BBC의 테크 리드

또한 디자인 팀과 개발 팀이 분리되어 있다고 해도 관리자는 양쪽 팀원을 교육해서 고차원적인 협력이 가능하도록 해야 한다.

반응형 디자인 프로세스에는 꽤 복잡한 부분이 존재한다.
모두 다른 언어로 이야기하는 불투명한 미래를 원하는 사람은 없다.
그런 상황에서는 생산성이 크게 저하되기 때문이다.
반응형 디자인이 제대로 이루어지려면 엔지니어링과 UX가 긴밀하게 통합되어야 한다.
- 제이슨 챈들러, 익스피디아의 클라이언트 엔지니어링 조직

피델리티에서는 'UX 개발자'라는 새로운 자리를 만들었다.
네이션와이드보험은 '크리에이티브 테크놀로지스트'라는 직책을 신설했다.
Cloud Four의 제이슨 그릭스비는 '프론트엔드 디자이너'라는 신규 직책에 맞는 인물을 구인 중이라고 했다.

이 시점에서 우리가 지향해야 하는 바는 서류, 포토샵파일 등이 아닌 작동하는 '프로토타입'이다.

2.3.3 기술 팀 교육

실제 반응형 디자인을 구축하는 역할을 맡은 디자이너와 개발자가 여러분의 핵심 인력이다.

유동현 그리드, 유동형 이미지, 미디어쿼리의 기초는 상대적으로 간단한다.
하지만 콘텐츠와 관련된 복잡한 문제를 처리하고 여러 기기에 걸쳐 테스트를 진행하고 각 플랫폼에서 빠른 성능을 내려면 실무 경험이 필요하다.

• 어떤 교육 과정을 제공할 것인가?
  여러 팀원이 참여한다면 콘퍼런스나 워크숍이 더 효과적이다.
• 이 일을 완성하기 위해 외부 에이전시와 함께 작업할 계획이 있는가?
  그렇다면 사내 인력을 훈련할 수 있는 시간을 따로 마련해야 한다. 그렇지 않으면 에이전시 팀이 모든 경험을 그대로 가지고 떠날 것이다.
• 반응형 디자인을 담당한 팀의 규모가 작은가?
  만약 그 팀이 해당 프로젝트를 통해 배운 내용을 다른 팀에 재교육할 계획이라면 중간에 지식을 공유하는 시간을 마련하자.
• 반응형 디자인이 업무 프로세스를 어떻게 변화시킬지에 대해 조직 전체를 교육할 필요가 있다고 보는가?(정답은 그래야 한다 이다.)
  반응형 디자인을 도입하면 포토샵 파일이나 문서를 활용하던 기존 방식은 버려야 할 것이다.
  업무를 진행하고 소통하는 방식도 바뀔 것이다.
  '반응형 리디자인'과 관계없어 보이는 프로젝트 관리자, 백엔드 개발자, QA 테스터의 업무 방식도 달라져야 한다.

교육은 중요하다. 하지만 그보다 실제 업무가 더 중요하다.
이렇게 새로운 방식으로 일하는 데 익숙해지기가 그리 쉽지만은 않을 것이다.

2.4 레벨 업하기

매리엇의 리비아 리베이트는 반응형 프로그램을 통해 다음 3가지 목표를 한꺼번에 이룰 수 있었다고 말한다.

1. 반응형 사이트 만들기
2. 팀원들에게 새로운 기술 교육하기
3. 새로운 프로세스 적용하기
   좀더 협력적이고 반복적인 방식으로 일하기 같은 새로운 가치가 중요해졌다.

반응형 디자인을 적용하는 과정에서 사업적으로도 엄청난 혜택을 얻었다.
이제는 사업 전략을 이야기하는 자리에 디자인 팀도 참여할 수 있게 된 것이다.
우리는 단순히 웹 페이지를 찍어내는 생산 조직이 아니라 사업적 가치를 실현하는 존재이다.
이제는 브랜드 전략과 사업 전략을 이야기할 때 우리에게도 영향력이 생겼다.
팀 내부에 정말 큰 변화가 일어났다.
- 로버트 허들스턴, 캐피털원의 시니어 크리에이티브 디렉터