글쓰기의 어려움

4370개의 글자를 쓰는데 11일이 걸렸다. 그나마 공백을 제외하면 3404이다. 하나의 프로젝트를 마치고 본사에 복귀한 후, 어차피 요청되어질 업무라는 것을 알기에 먼저 물었다. 써야 하냐고. 써달라고 그런다. 그래서 시작했다.  프로젝트 원고. 

처음도 아니고 이미 몇번의 경험이 있어 그냥 빨리 마무리 지으려 했다. 언제나처럼 대략 몇개의 키워드를 끄적이고, 순서를 정하고. 생각나는 대로 기계적인 타이핑을 한다. 그렇게 한줄 한줄 쓰다보면 초안이 나오고. 다시 몇번 읽으면서 퇴고를 거듭하다 보면 마무리를 할 수 있으리라 생각했다. 

잘 안된다. 그럴 수 있다. 억지로 하지 않으려고 미뤘다. 그리고 다시 끄적이기를 반복한다. 주말 동안 머리를 비워내면 괜찮겠지. 월요일이 되니 더 안써진다. 그렇게 며칠이 지난다. 이제는 고통이다. 일단 엉성하게라도 초안을 만들어 보려고 안간힘을 쓴다. 더 안된다. 

다시 주말이 지났다. 이젠 다른 것들도 손에 잡히지 않는다. 더 미뤘다간 큰일이다 싶다. 자리에서 일어나 옥상으로 올라가 한참을 서성인다. 

결국 알았다. 모르는데 아는 척 하려 했다는 것을.  1년 동안 한 일인데…

아는 만큼만 쓰기로 하고 내려왔다. 

주절주절 늘어 놓은 것들 정리하다 보면 또 쓰여지겠지.

UX Writing 왜 할까?

Writing 교정, 교열, 윤문, 편집.. 만 생각하다가. 왜? 라는 문제로 새버렸다. image from pixabay

UX Writing에 대해서 몇가지 떠오르는 생각이 있었다. 그 중 지난 몇년간 프로젝트에서 쌓아온 경험으로 ‘SI 프로젝트에서 UX Writing’이란 다소 거창한 주제도 있었는데. 막상 쓰려고 이것저것 자료를 찾다 보니. 꼬리에 꼬리를 무는 검색질로 시간 가는 줄 모르다가 우선 현재까지의 생각만 정리해 본다.

UX Writing이란 무엇일까?

사용자(User)가 상품 또는 서비스를 이용하는 과정에서 글자로 표현하는 모든 것을 말한다. 그러므로 어느 한 화면이나 한 페이지에만 적용되는 것이 아니다. 사진, 아이콘, 일러스트 등의 이미지를 이용한 정보 전달도 가능하지만, 여러가지 해석이 가능할 수 있으므로 정확한 정보 전달을 위해서는 글자가 필요하다.

여기서 사용자는 정보 소비자(Consumer)로 읽힌다. 글을 읽고 정보를 얻고 다음의 행동으로 나아가는 과정에 고객(Customer)으로 진화되기를 바라는. 이미 고객이 된 경우라도 지속적인 구매를 유도하거나 유지가 필요하다는 개념에서 고객이기 보다 소비자로 보는 것이 적합하다.

UX Writing의 목적

소비자에서 고객으로 전환되기 위해. 단순히 정보를 제공하는데 그치는 것이 아니라, 이를 이용한 소비자가 다음 행동으로 이어지게 하기 위한 적극적인 의지가 개입된다. 쉬운 용어 사용, 친절한 어투의 문체, 일관된 표기법 등 만으로는 UX Writing을 설명할 수 없다. 핵심은 상품과 서비스에 호감을 느끼고(또는 유지하고) 계속해서 경험이 이어지도록 하는데 있다.

토스의 UX Writer에 대한 포지션 소개를 참고해 보자.

두 번째는 토스에 대해 더 좋은 마음이 들게끔 하고 있어요. 제품을 잘 안내하는 것을 넘어, 사용자가 원하는 정보를 추천하거나 감정에 공감하는 등 마음을 사로잡는 시도를 하는 거예요.

https://blog.toss.im/article/uxwriter-interview

위 토스 피드에서 첫번째(고객이 더 편리하게 사용할 수 있도록 안내)는 사실 두번째 마음을 사로잡기 위한 기초 과정으로 보인다. 세번째(동료들과의 협업 효율을 높이는 일)는 UX Writing이 한 회사내에서 일관성을 유지되도록 하는 역할로 보이고. 결국 UX Writer의 포지션(Position)은 제품을 잘 안내하는 것을 넘어, 마음을 사로잡는 시도를 하는거다.

관계와 소통

내가 만들어서 혼자 쓰고 마는 것에 Writing은 필요하지 않다. Writing은 제품이나 서비스를 제공하는 존재를 전제한다. 그러면 관계(relation)가 형성되고 소통(Communication)이 필요하다. 소통은 단방향의 의사 전달이 아니라 주고 받는 과정이다.

애플의 Siri나 아마존의 Alexa와 같은 AI Speaker를 이용한 대화형 서비스가 있으나 아직은 ‘글’에 의한 정보의 전달이 주류를 이룬다. 단순히 전달만 하고 그치면 소통이 되지 않는다. 마음을 사로 잡아야 그 다음 대화가 이어진다.

닐슨 노먼 그룹의 자료 “How Little Do Users Read?” 에 따르면 사용자들은 (웹)페이지에 머물면서 20%의 단어를 읽는 것으로 가정된다. 소규모 엘리트 그룹을 대상으로 한 연구이므로 실제는 더 낮을 것으로 본다고 한다. (https://brunch.co.kr/@margrit74/107에서 재인용)

주절주절 혼잣말을 하는 것으로는 마음을 사로잡을 수가 없다. 언제 자리를 박차고 일어설지 모르는 상대방을 붙잡기 위해. 한 글자도 낭비함 없이. 그래서 UX Writing이 필요하다.

내가 프로젝트에서 쫓겨난 이유

모난 돌이 정 맞는다. image from pixabay

‘티나 실리그(Tina Seelig)’의 『인지니어스(INGENIUS)』서문에 나오는 이야기다.

수업 첫날은 매우 간단한 도전으로 시작한다. 이름표를 재디자인 하는 것이다. 나는 학생들에게 지금 착용하고 있는 이름표가 전혀 마음에 들지 않는다고 말한다. 글자가 너무 작아서 읽기 힘들다, 알고 싶은 정보를 담고 있지 않다. 착용자의 벨트 버클에 매달려 있는 경우도 종종 있는데 보기 흉하다 등등. 그들도 역시 그런 점들에 짜증 났던 적이 있다는 걸 깨닫고는 웃음을 터뜨린다.

15분 후에 학생들의 목에 걸린 이름표는 커다란 글씨로 이름이 적힌, 예쁘게 장식된 종이로 대체됐다. 새로운 이름표는 각자의 셔츠에 단정하게 고정되었다. 그들은 성공적으로 문제를 해결하고 다음 단계로 나갈 준비가 되었다며 흐뭇해했다. 하지만 내가 마음에 둔 건 다른 것이었다. 나는 새로운 이름표를 전부 모아서 서류 분쇄기에 넣는다. 학생들은 미치기나 한 듯 쳐다본다. 그러면 난 아무렇지 않은 듯 다시 학생들에게 묻는다.

“애초에 이름표는 왜 사용한 걸까요?”

그들은 황당한 표정으로 나를 쳐다본다. 대답은 뻔하지 않나? 당연히, 남들이 우리의 이름을 볼 수 있게 하기 위해서다. 하지만 그들은 곧 이 질문에 대해 제대로 생각해본 적이 없다는 것을 깨닫는다. 짧은 토론 후에, 그들은 이름표가 세세한 기능들을 맡고 있다는 것을 알게 된다. 서로 모르는 사람들 간의 대화를 촉진하고, 누군가의 이름을 잊어버리는 실수를 막아 주고, 대화 상대에 대한 정보를 알게 해주는 것이다.

이름표의 역할에 대한 이해를 이렇게 확장 시킨 뒤, 그들은 서로를 인터뷰해서 새로운 사람들과 어떻게 관계를 시작하고 싶은지, 남들이 그들과 어떻게 관계를 시작했으면 하는지를 알아낸다. 이런 인터뷰는 창의적이고 새로운 해결책, 전통적인 이름표의 제한을 훌쩍 뛰어넘는 참신한 시각으로 이어졌다.

인지니어스, p13~14 中

위에서 말하는 ‘수업’은 스탠퍼드대학교 하소플래트너디자인연구소(Hasso Plattner Institute of Design, 애칭 D.School)에서 진행되는 ‘디자인 사고(Design Thinking) 수업 이다.

이어지는 창의적이고 새로운 해결책은 다음과 같다.

한 팀은 이름표의 크기에서 벗어나, 글자와 그림으로 착용자의 정보를 나타낸 맞춤형 티셔츠를 디자인했다. 다른 팀은 그 사람의 이름을 발음하는 법(이거 때문에 소리 기반의 이어폰을 생각한듯)과 근무지, 서로 아는 친구들의 이름 같은 정보를 포함하여 들려주는 이어폰 모형을 만들었다. 또 다른 팀은 의미 있는 대화를 촉진하기 위해서 상대의 기분이 어떤지 아는 것이 종종 더 중요하다 생각하여 기분을 나타내는 여러 색깔의 팔찌를 디자인했다.

저자는 이 과제의 핵심을, 어디서나 창조적으로 문제를 해결할 기회가 있다는 것을 드러내기 위한 것이라고 한다. 나는 이 기회가 “왜?”라는 문제의 핵심을 돌아보는 질문에서 시작된다고 본다. 그러나 이런 질문이 언제나 환영 받는 것은 아니다.

언젠가 프로젝트에서 ‘쫓겨난 적’이 있다. 처음엔 내가 무엇인가 잘못을 저지른 것이라 생각했다. 그것이 무엇일까 한참을 고민했다. 그런데 딱히 찾을 수 없었다. 그 사이 계속 들려오는 여러 이야기로 하나씩 조각을 맞춰볼 수 밖에 없었다. 그러나 한 가지 분명한 것은 내가 ‘그들’을 불편하게 했던 거다. “왜?”라는 질문으로.

추정컨대 내게 원했던 것은 ‘why?’가 아니라 ‘how?’였다. 그저 손 끝을 보고 따라가면 되는데 저기가 맞냐고 묻고 있으니 쫓겨날 수 밖에.

그러나 기존에 없던 새로운 서비스를 만드는 작업으로 계속 새로운 아이디어가 필요했고. 스스로 이해되지 않고, 동의되지 않는 것을 시킨대로만 하는 것도 내 역할은 아니었으니. 과정의 아쉬움은 있으나 후회는 없다.

다시 쫓겨나더라도 나는 “왜?”라고 물어보겠다.

UX 설계 어디에서 출발할까?

그림 부터 그리고 있지 않는가? 충분한 재료 없이. image from pixabay

어떤 이가 내게 묻는다. “○ ○ ○ ○ 는 왜 그 프로젝트를 한 건가요?” 내 생각을 바로 이야기 하려다 잠시 멈췄다. 그러고 “검색을 해보세요”라고 답했다.

물고기를 주기 보다 잡는 법을 가르치겠다는 고상한 의도는 아니다. 내 생각이 맞을 수도 아닐 수도 있거니와. 스스로 필요해서 찾아 보지 않으면 소용이 없음을 알기 때문이다.

아래는 내가 프로젝트를 시작할 때 거치는 과정이다. 그것이 폭포수이든 애자일이든.

그 회사의 업의 속성을 먼저 알아본다. 예를 들어 보험회사이면 ‘보험’이 무엇인지. 대개 간단한 검색만으로도 알 수 있다. 위키 사이트를 이용하면 좀 더 자세한 정보도 나오고, 짧은 경우 영문 위키 사이트를 찾아봐도 좋다. 개요부터 역사와 세부적인 분류까지 알 수 있다.

기본 속성을 파악했다면 최근의 이슈나 동향 자료를 찾아본다. 뉴스 검색만으로도 어떤 것이 관심사가 되고 있는지 알 수 있다. 산업동향이나 기술동향 자료의 경우 riss.kr 같은 학술연구정보 사이트도 도움이 된다.

회사의 홈페이지 등을 통해서 회사의 기본 정보를 찾아본다. 개요와 연혁, 현황 등을 알아볼 수 있다. 주요 제품이나 서비스를 확인할 수 있고 홍보자료나 공지사항 등을 통해 최신 소식도 확인할 수 있다. 특히 신년사나 창립기념일 등에 게시되는 자료들을 보면 주요 경영 현황에 대한 방향을 알 수 있다.

책으로 출판된 것이 있다면 읽어볼 필요가 있다. 대개 해당 회사에서 직접 관여를 하거나, 비공식적으로라도 협의를 거친 내용들이기에 회사의 문화나 추구하는 중장기적인 과제와 방향에 대해서 한번에 많은 정보를 얻을 수 있다. 때로 경쟁사와 비교 자료도 얻을 수 있다.

뉴스를 다시 검색해보는 것도 필요하다. 신제품에 대한 것부터 업계의 이슈에 대한 회사의 대응 내용이나 이후 진행 방향을 알 수 있다. 그러다 보면 자연스레 경쟁사들의 동향도 알 수 있다. 뉴스 중에서는 경영진의 인터뷰 기사가 있다면 가능한 많이 찾아보면 좋다.

이쯤에서 RFP를 읽어보면 왜 프로젝트가 시작되었는지 큰 그림은 맞춰볼 수 있다.

UX(사용자 경험)은 사용자가 회사, 제품, 서비스로부터 얻는 상호 작용의 모든 측면을 포함한다. 프로젝트는 UX를 향상시키기 위한 수많은 과제들의 집합체이다. 달을 보라고 손가락으로 가르켰더니 손가락만 보는 우를 범하지 않으려면. 사용자만 볼 것이 아니라 회사도, 제품도, 서비스도 그 본질부터 알아야 하지 않을까.

결국 Desk Research 단계에서 이런 조사 활동들이 활발히 이루어져야 한다.

개인화, UX에 어떻게 담을 것인가?

자세히 보면 조금씩 다른 모습일지도 모른다. 개인화란 이런 것이 아닐까? image from pixabay

이 글은 ‘개인화, 맞춤서비스 메모‘의 후속이다. 여전히 예정된 프로젝트는 불확실하지만, 어느 곳에 가더라도 유사한 과제(개인화)는 있을 것이기에 계속 이어 본다.

앞서 ‘개인화’가 상품에 따라 어떤 효과가 있을 것인지에 대해 참고할 만한 자료로 논문 하나를 찾았고 길지 않은 분량이기에 금방 읽을 수 있었다. 해당 논문에서 원했던 결과를 찾을 수는 없었으나 탐구는 이어질 수 있었다. 본 글에서는 논문의 일부 내용을 인용하면서 해당 부분에서 이어진 사고의 흐름과 탐색 과정을 기록한다.

상품은 소비자가 상품을 경험(사용)하기 전에 상품의 품질이나 가격과 같은 특성을 알 수 있는지의 여부에 따라 경험재(experience goods)와 탐색재(search goods)로 구분된다. 경험재는 사용하기 전에는 특성을 잘 알 수 없는 상품을 의미하며 도서나 의료 서비스 등이 해당된다. 반면, 탐색재는 구매 전에 쉽게 특성을 알 수 있는 상품을 의미하며, 각종 소모품이나 컴퓨터와 같이 표준화된 제품이 예가 된다.

오프라인 매장과는 달리 전자상거래에서는 일반적으로 소비자가 직접 상품을 눈으로 확인하거나 만져보고 조작해 보기가 어렵다는 측면에서 상품에 대한 정보가 제한되는 측면이 있다. 이러한 전자상거래의 특성은 경험재와 탐색재의 구매에 있어서 각기 다른 정도의 영향을 가질 것이며 따라서, 상품 구매 상황에 있어서 인지된 개인화가 갖는 영향에 대해서도 다르게 작용할 것으로 예상된다.

이동주. 전자상거래의 수용에서의 개인화의 역할에 대한 연구: 기술 수용 이론과 정보 프라이버시 이론의 통합. NRF KRM(Korean Research Memory), 2008.

경험재와 탐색재에 대한 정의는 이전에도 읽은 적이 있다. 주목한 것은 전자상거래(나아가 비대면 서비스 전반에 걸쳐)에 있어 이에 따라 개인화가 갖는 영향이 다르게 작용할 것이라 예상한 부분이다. 그러나 초록에서 밝힌 것과 달리 본문 내용에서 위 내용은 상세하게 다뤄지지 않는다.

이 부분에서 경험재와 탐색재에 대한 정의를 조금더 상세히 찾았다. 검색 등을 통해 대개 유사한 내용들이 반복되었고, 비대면 공간에서는 경험재가 상대적으로 더 판매가 어렵다는 결론이 나왔다. 그리고 이를 보완하기 위한 방법들에 대한 논의도.

인터넷에서는 일반적으로 탐색재를 판매하는 것이 유리하다. 상품을 직접 만져보고 살 수 없는 쇼핑몰로서는 사진이나 텍스트를 통한 정보만으로도 충분히 그 제품을 설명할 수 있어야 한다. 화장품이나 고추장처럼 경험을 하기 전에는 도저히 품질을 알 수 없는 제품을 아이템으로 한다면 도대체 그 품질을 무엇으로 설명할 수 있을 것인가?

https://ebizbooks.tistory.com/503

위 글에서는 ‘스타, 공신력 있는 기관, 대기업과의 제휴에 의한 브랜드 편승’의 3가지 방법과 ‘상세한 사진과 상품설명’을 중요한 대안으로 제시한다. 그런데 경험재는 구체적인 형상을 가진 상품 뿐만 아니라 금융상품과 같이 무형의 서비스도 대상이 될 수 있다. 이와 같은 경우에는 연상 되는 인물이나 (자연을 포함한) 장면 사진 등을 이용하거나 일러스트 이미지를 사용하기도 한다. 대개의 금융 프로젝트에서 상품 상세 화면을 제작하기 위한 디자이너들의 고충이 여기에서 시작된다.

논문에서는 경험재와 탐색재의 차이에 따른 개인화 영향도에 대해 자세히 다뤄지지 않지만 몇 번의 검색 과정을 거치면서 제시된 개인화 결과(추천상품 등)를 수용하기 위해서는 결국 상품 정보에 대한 신뢰가 필요함을 알게 된다.

그런데 이 상품의 정보는 어느 단계에서 어떻게 제시되어야 할까? 다음을 읽으며 고민을 계속 한다.

개인화의 유형을 고려하고자 한다. 개인화의 유형과 관련해서는 다양한 분류가 존재하지만 본 연구에서 적용하고자 하는 개인화의 유형은 Surprenant and Solomon(1987)이 제시한 과정의 개인화(process personalization)와 결과의 개인화 (outcome personalization)의 구분이다. 과정의 개인화는 상품에 대한 정보가 제공되고 구매자의 평가와 비교를 통한 선택이 이루어지는 구매 과정에 대해 개인화가 이루어지는 것을 의미한다. 반면에 결과의 개인화는 구매자가 선택할 수 있는 상품들을 개인화된 메뉴의 형태로 제시하거나, 극단적인 경우 구매자의 선호에 가장 부합된다고 판단되는 하나의 상품을 제시하는 방식이다.

이러한 개인화 유형의 차이는 구매자가 전자상거래를 통한 구매과정에서 수행하는 역할과 노력의 차이를 가져올 것으로 예상되며, 따라서 인지된 개인화가 갖는 영향에 대해서도 다르게 작용할 것으로 기대된다.

이동주. 전자상거래의 수용에서의 개인화의 역할에 대한 연구: 기술 수용 이론과 정보 프라이버시 이론의 통합. NRF KRM(Korean Research Memory), 2008.

여기서 개인화는 ‘과정’과 ‘결과’로 유형을 분류하고 있다. 처음 이 부분에서 주목했던 것은 ‘유형의 차이에 따라 개인화가 갖는 영향에 대해서 다르게 작용할 것’이라는 가설이었는데 역시 이 부분에 대해서는 자세히 다뤄지지 않고 있다. 그러나 ‘과정’에서 재차 주목한 것은 ‘구매자의 평가와 비교를 통한 선택’이다. 이는 개인화가 일방적으로 제공되는 것이 아니라, 수용자의 의지가 개입될 수 있음을 말한다. 그리고 ‘추천상품’과 같은 극단적인 ‘결과의 개인화’에 치중하는 경향을 반성케 한다.

돌아보니 어쩌면 UX에서 개인화는 이미 정해진 상품을 화면 내 배치하는 것에 그치지 않고, 사용자에 의한 정보 수집과 선택의 과정(Process)을 위한 것일지도 모른다는 생각을 한다. (그러기 위해서는 UI 기획자의 틀을 벗어나 Product Designer가 되어야 할지도. 이에 대해서는 앞서 작성한 ‘나는 왜 프로토타입 툴을 쓰는가?‘에서 소개한 브런치글 을 참고)

그리고 다시 ‘데이터 기반 개인화 추천 (3/3): UX편‘을 훑어보니 흐름이 맞아 떨어진다. 이 부분에 대해서는 다시 한번 더 정리를 해봐야겠다.

라디오버튼, 드롭다운 사용 구분

Radio buttons allow users to select one option from a set. – material.io

지인이 페북에 공유한 브런치글(https://brunch.co.kr/@toqha7822/10 中 3. 옵션이 적을 경우 라디오, 옵션이 많을 경우 셀렉트 UI를 활용하자)을 보면서, 예전부터 정리하려고 했던 내용이 떠올랐다. (위 브런치글에서 셀렉트 UI라고 지칭한 것을 아래에서는 ‘드롭다운-dropdown’으로 지칭한다.)

고객사에서 만든 UI Guide Document(굳이 구분한 것은 GUI 작업은 수행사에서 했기 때문)를 전달 받아 화면설계서(스토리보드)를 작성한 적이 있다. 거기는 프로젝트 준비를 오랫동안 준비하면서 UX 전문인력을 채용하여 TF에 있었고, 운영 경험도 많아 세부적인 UI Component까지 사전 정의가 되어 있었다. 물론 서비스 전면개편으로 적용하다 보니 세부 항목들이 수정, 추가되기도 하고, Guide에 정의된 각 Component를 어떤 경우에 사용할 지는 계속 논의를 했는데 그 중 대표적인 것이 선택 UI였다.

체크박스(Checkboxes)는 다중 선택이 가능한 경우, 라디오버튼(Radio buttons)은 단일 선택이 가능한 경우로 하여 기능적인 차이가 명확하여 별 이견이 없었다. 그러나 드롭다운 역시 단일 선택 기능을 제공하므로 라디오버튼과 드롭다운의 경우는 구분이 필요했다.

초기 정리되었던 기본 원칙은 다음과 같다.

  1. 선택 항목이 적고 단답형인 경우 라디오버튼으로 한다. ex) 예/아니오, 남/여, 동의/미동의
  2. 선택 항목이 많은 경우 드롭다운으로 한다. ex) 출생년도, 전화국번, 이메일 목록

그러나 선택사항의 많고 적음으로만 구분하는 경우 몇개까지를 라디오버튼으로 할지에 대한 추가 논의가 필요하다. 또한 선택 항목의 내용이 긴 문장형으로 구성이 필요한 경우 드롭다운 형태로 할 때 문장 길이에 따라 들쭉날쭉하고 보기가 불편한 점이 발생한다(모바일 UI일 때 더욱 그러하다). 하여 선택 항목에 대한 사용자의 인지 여부와 가독성을 두고 다음과 같이 보완을 한다.

선택 항목을 한눈에 파악하고 빠르게 판단이 필요한(가능한) 경우 라디오 버튼으로 한다.

  • 예/아니오, 동의/비동의는 부정(아니오)에 대한 선택이 가능함을 보여주기 위해서 라디오 버튼 형식이 유효하다.
  • 설문 문항과 같이 선택항목의 내용이 긴 문장형으로 구성되거나 항목간 비교가 필요한 경우 라디오 버튼 형식이 효율적이다.
  • ‘예’만 선택 가능한 경우에는 체크박스 형태로 구성한다. ex) 약관동의 UI

선택 항목에 대해 이미 인지하고 있고, 단순 선택하는 경우 드롭다운으로 한다.

  • 전화국번, 이메일주소-도메인, 국적, 은행, 통화 등 항목은 다수이나 선택 내용이 명확하고 무엇을 선택해야 하는지 관습적으로 이미 아는 경우
  • 성별(남/여) 선택과 같이 항목이 적은 경우는 드롭다운 형태도 가능하나 터치(클릭) 액션을 한번 줄이는 효과를 고려하여 라디오 버튼으로 한다.

대략 위와 같이 기준을 정하고 UI 설계를 진행하면서 필요한 경우 개별 논의를 하기로 했으나, 추가 검토는 발생하지 않았던 것으로 기억한다. 이후 다른 프로젝트에서 UI Guide를 논의할 때 위 내용으로 제안하였고 큰 이견들 없이 진행되었다.

정보의 양에 따라 위 기준처럼 각 항목을 단순히 나열(드롭다운)해도 될 것이고, 해당 항목에 대한 보다 자세한 설명을 제공(라디오버튼)할 필요도 있다. PC 또는 모바일 기기별 해상도에 따라 구성이 달라질 수도 있을 것이다. 중요한 것은 기능적인 접근이 아니라 ‘선택(Select)의 순간에 필요한 정보를 어떻게 보여주는 것이 사용자의 결정에 도움이 될까?’라는 질문인 것 같다.

뱀발1: material.io Component에 selection-control(체크박스, 라디오버튼, 스위치)이 별도의 메뉴로 제공되었는데 현재는 사라지고 각각의 메뉴로 제공된다. 다만 구글에서 검색을 하면 다음 url로 접속이 가능하다. https://material.io/components/selection-controls meterial.io 내용이 수시로 바뀌는 것 같으니 가끔 찾아봐야겠다.

뱀발2: select box와 dropdown 의 차이에 대해서도 정리해봐야겠다.

나는 왜 프로토타입 툴을 쓰는가?

언제나 Why? 를 먼저 생각한다. 그러니 힘들지만 차근차근 한 걸음 한 걸음 나아간다.

이 질문에 대한 답은 프로토타입(prototype)에 대한 정의에서 시작된다.

프로토타입(prototype)은 원래의 형태 또는 전형적인 예, 기초 또는 표준이다. 시제품이 나오기 전의 제품의 원형으로 개발검증과 양산 검증을 거쳐야 시제품이 될 수 있다. 프로토타입은 ‘정보시스템의 미완성 버전 또는 중요한 기능들이 포함되어 있는 시스템의 초기모델’이다. 이 프로토타입은 사용자의 모든 요구사항이 정확하게 반영할 때까지 계속해서 개선/보완 된다. 실제로 많은 애플리케이션들이 지속적인 프로토타입의 확장과 보강을 통해 최종 설계가 승인된다.

https://ko.wikipedia.org/wiki/프로토타입

나는 오랜 동안 SI 프로젝트에서 ‘기획자’로 일해왔다. 그동안 파워포인트로 설계서(스토리보드)를 작성하고 아래와 같은 과정을 거친 후에야 동작하는 실체를 볼 수 있었다.

  1. 디자인 – 그래픽 이미지로 제작되어 시각적인 확인은 되지만 브라우저(또는 앱)에서 어떻게 동작 될 지는 알 수 없다.
  2. 퍼블리싱 – 브라우저에서 화면 단위로 볼 수 있지만 연결될 화면을 하나씩 지정해 주는 것은 별도로 필요하다. 화면 연결과 효과는 별도로 정의를 해줘야 한다.
  3. 개발 – 실제 화면에 보여질 데이터를 연동하고 기능 요건까지 적용한 상태로 볼 수 있다.

내가 만들고 싶은 어떤 것(그것이 하나의 화면이든, 연속된 화면으로 이루어진 서비스 또는 기능, 그리고 이의 합체인 제품이든)이 구체화 되려면 이렇게 여러 사람의 손을 거쳐야 한다.

그리고 짠! 하고 보여주면 여기저기서 말들이 나온다.

“제가 생각한 것과 다른데요…”

이런 말 안 들으려면 프로토타입이 필요하다. 그런데 제한된 시간 내에 개선/보완을 통해 사용자의 요구사항을 정확히 반영하려면 빨리 만들어야 한다. 디자인, 퍼블리싱을 기다릴 시간이 없다.

전통적인 워터폴 방식의 기획-디자인-퍼블-개발로 이어지는 단계적 접근으로 이 문제를 해결할 수 없다. 이제는 UI 기획자가 화면 디자인과 프로토타입까지 제작하는 방식이 필요하다.

이런 생각은 한 스타트업과 일을 준비하며 읽은 글(https://brunch.co.kr/@nyeric/29)이 참고가 되었다. 그리고 실제 원격에서 Figma를 이용해 화면을 디자인하고 개발자들과 논의하며 서비스를 만들어가는 동안 즐거웠다.(이때의 경험으로 Framer에 대한 관심이 좀더 커졌다. 이에 대한 이야기는 다음 기회에.)

SI 프로젝트에서, 외부 접속이 차단된 환경의 문제로 실제 업무에서 사용해볼 기회는 제한적이겠지만. 가능한 계속해서 프로토타입 툴을 써보려고 한다. 계속 진화하기 위해.

새 장난감, Framer 시작

그냥 create code file 을 시도하면 자동으로 제공되는 기본 소스다. 겁먹을 필요 없다. 덜덜..

Framer(https://www.framer.com)를 시작했다.

기존 사용하던 Figma로 UI를 그려내는 데는 별다른 부족함이 없었다. 가끔 아쉬운 점이 있었다면 내가 충분히 활용하지 못해서 일거다. 그럼에도 새로운 툴을 만지작 거린 것은 어디선가 읽은 code 기반으로 interatction을 좀더 효과적(?)으로 구현할 수 있다는 설명 때문일 거다.

전업 개발자로 code를 다룬 것은 오래전이지만 여전히 한두시간 정도는 지치지 않고 가지고 놀 수 있기도 하고. 무엇보다 해보지 않은 거니까.

Figma와 마찬가지로 시작은 무료이다. 어차피 혼자 가지고 놀거니까 굳이 당장 결제할 필요도 없다.

비용이 궁금하다면 여기를 https://www.framer.com/pricing/