좋은 UI설계서란 무엇일까?
그건 마치 연애편지 같은 보험약관이랄까...
옛날 전쟁 사극을 보면
인상을 잔뜩 구긴 장군 아저씨들이
블루마블 게임판 같은걸 탁자에 착! 깔아놓고
'네 말이 맞네 , 내 말이 맞네!' 하면서 작전 회의를 합니다.
그 실력으로 오더 하지 마!!!(0/7/2) - 출처 : 영화 명량 스틸컷우리가 매일 쓰는 앱 서비스의 회의에서도
기획자, 개발자, 디자이너, QA(품질 테스트)가
비슷한 표정을 지은 채
투닥투닥 의견 교환(말싸움)을 하는데요.
이때, 블루마블 게임판 대신
모니터에 띄워놓는 문서가
바로 'UI설계서'입니다.
이 문서를 부르는 이름은 굉장히 다양합니다.
UI설계서, 상세설계서, 와이어프레임
UID(User Interface Description) 등등,
많은 조직들이 비슷한 문서를
조금씩 다르게 부르곤 합니다.
물론, 이렇게 부르는 말은 각양각색일지라도
문서 자체는 거의 똑같습니다.
하나의 조직이
'앱 서비스'를 만들건데,
화면이 생긴 모양을
1. 그림으로 그리고
2. 옆에 설명을 달아 놓는 것이라면
모두 UI설계서라고 볼 수 있지요.
브런치의 [제안하기] 화면 샘플 - 출처 : 저자대개 이런 UI설계서는
서비스 기획자 (UX담당자)들이 만들어서
개발자, 디자이너, QA가 함께 봅니다.
그렇기 때문에 많은 담당자들이
이 문서를 진짜(!) 잘 만들고 싶어 하죠.
1. 개발자에게는 '와 너랑 일하면 진짜 편하다',
2. 디자이너에게는 '인터랙션 설계 굳굳!!'
3. QA에게 '정책이 꼼꼼해서 마이너 케이스가 없음!'
이라는 칭찬을 무척 듣고 싶기 때문입니다.
당신이.. 그 천재 기획자..? - 출처 : Giphy그러다 보니 초년차 기획자들은
UI설계서 작성에 엄청나게 공을 들여
1. 집 가서 양치하면서도 문서를 보고,
2. 버튼 하나에 설명을 10줄씩 달고,
3. 기능 하나 설계를 5페이지씩 하는,
소위 과몰입 경향을 보입니다.
(제 이야기입니다.)
하지만 어느 정도 IT서비스를 하다 보면
내 예상과 달리
개발자는 기능을 잘못 이해하고,
디자이너와 QA는 하루 종일
1. 이거 뭐예요?
2. 이거 왜 있어요?
3. 이거 무슨 뜻이에요?
하면서 슬랙 메시지 3 연타를 날리는
불행한 상황이 생깁니다.
개발: 말씀하신 '날으는 비둘기' 이런 거죠? / 기획: 오..!?(탄식)그제야
'음..?! 이거 설마 내 잘못인가..?'
라는 생각이 들죠.
이런 가슴 답답한 촌극을 막고,
정말 목적에 맞는 UI설계서를 작성하기 위해
스스로를 반성하는 의미에서
UI설계서 작성 시
주요 원칙 5가지를 적어보았습니다.
(앞으로 명칭은 UID로 통일하겠습니다.)
1. 흐름을 담습니다.
다음 내용이 궁금해!
좋은 UID는 흐름을 담아야 합니다.
페이지의 왼쪽 위부터 오른쪽 아래까지
눈동자가 이동하면서
이야기의 순서가 술술 읽혀야 합니다.
마치 KBS 주말드라마 대본처럼요.
다음화.. 다음화 주세요... 출처 : KBS 한번 다녀왔습니다.UID를 처음 작성할 때
완벽한 것은 전혀(!) 중요하지 않습니다.
정말 중요한 것은 UID를 읽는 사람이
1. 읽고 싶고
2. 기능을 이해할 수 있고
3. 피드백까지 주고 싶게끔
만드는 것입니다.
그렇게 하기 위해서는
문서 안에 흐름이 있어,
독자의 주의를 붙들어 둘 수 있어야 합니다.
이 점을 머리로 알고 있는 UX기획자는
UID를 쉽고 간단하게만 만들려 하지만,
막상 작업을 진행하다 보면
처음에 간단하게 생각했던 기능이
실제로는 훨씬 복잡한 경우가 보통입니다.
이것도 해야 할 것 같고
저것도 해야 할 것 같죠.
그래서 100일도 안된 풋풋한 연인이
새벽부터 9단 도시락을 만드는 것처럼
한 페이지에 온갖 요구사항을 다 구겨 넣습니다.
문서의 흐름은 점점 사라지고
쉽고 재미있던 동화책이
전문가의 해석이 필요한 로제타스톤으로 바뀌게 되죠.
결국 문서를 만든 기획자조차도
일주일 정도 시간이 흐르면,
'에이~ 거짓말하지 마세요. 이거 제가 안 했어요.'
하면서 기가 찬 소리를 하게 되고,
문서를 읽는 독자(개발/디자인)들은
'이 바보를 어떻게 믿고 일하나' 하며
매우 난감한 표정을 짓습니다.
즉등히흐라.. 진.. 쯔... -출처 : KBS 살아있는 지구최종적으로는 결과물의 이곳저곳에서
생각지도 못했던 오류가 생겨나,
1. 서비스의 퀄리티가 떨어지고
2. 정해진 일정을 맞출 수 없게 되며
3. 같이 일하는 사람 사이에 불신이 생깁니다.
그래서 어떻게?
첫째, 컴포넌트 번호는 위에서 아래로
시선 이동에 따라 차근차근 붙입니다.
문서를 작성하다가
나중에 아차차! 생각이 나
추가로 버튼을 붙이게 된다면,
전체적인 번호를 새로 매기고,
설명하는 순서도 조정하는 것이 좋습니다.
이렇게 화면 영역에
차례대로 버튼을 붙이고 나면
오른쪽 설명 영역에서는
차근차근 상세조건을 풀어줍니다.
이와 같이 정보의 순서가 잘 지켜졌을 때
UID를 읽은 독자는
'내가 혹시 빼먹은 것은 없겠지?' 하며
불안해하지 않을 수 있습니다.
아래 예시는 제가 '브런치' 서비스의
[작가소개 → 제안하기 화면]을
UID형태로 간단하게 작성한 것입니다.
좌측에는 화면과 번호, 우측에는 설명을 씁니다. 출처 : 저자둘째, 필요한 경우 줄글만 쓰지 않고
버튼 바로 옆에 동작의 흐름을 달아줍니다.
개발자, 디자이너가 설계된 화면을 처음 접하면
'새로운 버튼은 어떻게 작동하는 거지?'하고
궁금증을 가집니다.
이럴 때 무작정 화면의 모든 기능을
화면 영역과 설명 영역으로
무 자르듯이 구분해서 작성하면
오히려 내용의 전달력이 떨어집니다.
버튼 바로 옆에 간단한 알고리즘이나,
케이스 형태의 시나리오를 그려주면
단순히 줄글만 담긴 UID보다
기능의 흐름을 쾌적하게 보여줄 수 있습니다.
아래 예시처럼 말이죠.
화면에 주요 버튼이 있으면 우측에 동작 방식을 써줍니다. -출처 : 저자셋째, 예시를 들어주면 좋습니다.
백문이 불여일견이라했습니다.
말로만 100번 설명하는 것보다
실제 예시로 한번 그려주는 것이
모두에게 훨씬 정확한 이해를 줍니다.
버튼을 누르면 확장되는 방식을
오른편에 직접 그려줍니다.
말로만 쓰는 것보다 화면으로 보여줍니다. -출처 : 저자2. 위계를 담습니다.
밑줄 쫙! 별표 뙇!
좋은 UID는 위계를 담아야 합니다.
중요한 것과 덜 중요한 것을
확실하게 갈라줘야 한다는 뜻입니다.
사람이 한 번에 이해할 수 있는 범위는
굉장히 제한적입니다.
그래서 우리는 공부를 할 때
중요한 곳에는 형광펜을 덕지덕지 칠하고,
선생님이 강조한 곳에 포스트잇을 딱 붙이곤 하죠.
색깔과 포스트잇으로 잘 정리된 필기노트 출처 : 에듀윌UID도 마찬가지입니다.
중요한 것을 중요하다고
딱 부러지게 알려줘야 합니다.
얼마 전 유튜브에 '백종원의 요리비책'
이라는 채널이 대유행했었습니다.
백종원 선생님이
요리 초보자들도 쉽게 따라 할 수 있는
레시피를 알려주는 방송이었는데요.
'백종원의 요리비책'이
다른 요리 채널들보다 월등했던 포인트는
정보를 전달할 때 위계가 확실했다는 점입니다.
백 선생님은 요리의 재료를 설명할 때,
'이건 1. 진짜, 2. 무조건, 3. 꼭 들어가야 합니다'
'에이 이거 없으면 그냥 안느(?)셔도 돼요'
'이거 없으면 아무 고춧가루나 느(?)세요'
처럼 재료의 위계를 설명해줍니다.
대한민국 요리 방송 유일 '없어도 되는' 방송 -출처 : 백종원의 요리비책이렇게 정보를 전달하는 사람이
'이거 중요해', '이건 덜 중요해'와 같이
위계를 잡아주면
정보를 받아들이는 사람의 이해도가
껑충 상승할 수 있습니다.
UID에서도 비슷한 작업이 필요합니다.
물론, UID는 요리 레시피처럼
뭘 더하고 빼고 할 수 있는 문서는 아닙니다.
(하나라도 빠지면 맛이 없는 게 아니라
동작을 하지 않습니다.)
하지만 그 와중에도 뭐가 제일 핵심이고
어떤 게 곁가지인지를
시각적으로 보여주는 것은 필요합니다.
때로 무언가를 '덜' 강조한다는 것이
어쩐지 께름칙하게 느껴질 수 있습니다.
하지만 현실은 그 반대입니다.
오히려 위계가 있어야
개발자, 디자이너들이
작업을 쪼개고 일의 순서를 정확하게 정리해
최종적으로는 몽땅 '중요해'라고 소리치는 것보다
훨씬 좋은 결과물이 나옵니다.
노란 표시는 덜 중요한 재료들! -출처 : 백종원의 요리비책그리고 위계가 체계적인 UID가 있다면
결과물에서 오류가 발생했을 때,
이게 출시 전에 무조건 고쳐야 하는 심각한 오류인지,
아니면 출시 이후에 천천히 패치해도 되는
간단한 오류인지 빠르게 판단할 수 있습니다.
그래서 어떻게?
첫째, 시각적으로 보여줍니다.
도형, 붉은색 글씨, 알고리즘 등,
중요한 기능은 시각적으로 큼직하게 전합니다.
'이걸 안 보고 배길 거야?' 싶을 만큼요.
가끔 조금 무뚝뚝한 개발자 분과 일을 하면
[개발] : '몰라요, (그 기능을) 모릅니다. 본 적 없습니다'
[기획] : '말도 안 되는 소리 하지 마세요! (UID) 봤자나요!!'
처럼 대검찰청 취조실 같은 상황이 연출되는데요.
UID 봤잖아!!!!!!! -출처 : 비밀의 숲이때는 사실 개발자 분이 부주의했을 수 있지만
기획자가 중요한 내용을 콩알만 하게
적어 놓았을 경우도 있습니다.
이런 사태를 방지하기 위해 일시적으로라도
정말 강조하고 싶은 건
큼직하게 표시를 해서 주는 것이 좋습니다.
노란 원 / 붉은 글씨 이래도 못 보시면.... - 출처 : 저자둘째, 여백을 많이 줍니다.
학교 다닐 때 필기 잘하는 친구들의 노트를 보면
공통점이 하나 있습니다.
바로 여백을 충분히 둔다는 것입니다.
우리는 중학교 미술시간부터
겸재 정선의 한국화를 보며
'여백 = 정보'라는 것을 숱하게 배웠습니다.
여백이 충분하다는 것은
여백 옆에 남아있는 글/그림이
이만큼의 여백을 가질 만큼 중요하다는 뜻이니까요.
여백은 항상 많이 주고 싶지만.. 생각보다 쉽지 않습니다. 출처 : 저자더불어 여백이 충분해야
나중에 수정할 때도 쉽습니다.
공간이 부족하면
설명이 들어가지 말아야 할 공간에 글씨가 들어가고
위계질서가 흐트러집니다.
3. 영향도를 봅니다.
그럴 줄 알고 제가 싹 준비해뒀습니다.
시장에 탄생하는 90%의 서비스는
1년도 못 가 사라집니다.
하지만 살아남는 서비스들은
영속성을 가지고 아주 오랜 시간 유지되죠.
이런 장수 서비스들은
모든 화면이 서로 깊은 연관성을 가집니다.
예를 들어 네이버 지도를 한번 생각해볼까요.
네이버 지도는 무려 2002년(!)에
붉은 악마와 함께 처음 세상에 나왔습니다.
모바일 버전을 만든지도 10년이 넘었죠.
세월이 느껴진다 느껴져 - 출처 : 한겨레그동안 만들어진 화면만
이미 수백 장을 넘어갑니다.
이런 서비스가 '즐겨찾기 방식'을
개편하면 어떤 화면에 영향을 미칠까요?
지금 생각나는 것만 나열해 보아도
1. 지도 화면 즐겨찾기
2. 대중교통 길안내 즐겨찾기
3. 네비게이션 즐겨찾기
4. 내 정보 즐겨찾기 편집
5. 위젯 즐겨찾기 설정
6. PC웹 즐겨찾기 이동.. 등등등
엄청나게 많은 화면에 간섭이 생깁니다.
빨간 표시는 네이버 지도에서 즐겨찾기가 영향을 주는 화면입니다. - 출처 : 네이버 지도실제로 꼼꼼히 따져보기 시작하면
이것보다 2-3배는 많은 화면이
즐겨찾기 하나의 변경에 영향을 받을 겁니다.
만약 기획자가 영향도를
세심하게 살피지 않고
눈앞에 보이는 화면만 대충 슥슥 고쳐서
개발팀에게 건네주게 되면
개발자들은 굉장히 큰 스트레스를 받습니다.
내가 만든 코드가 어디서 어떤 오류를
만들어낼지 감도 잡을 수가 없기 때문이죠.
하지만 기획자가 서비스 전체의
1. 영향도를 꼼꼼히 확인하고
2. 개발자들도 깜짝 놀랄 만큼
다양한 화면의 예외 케이스들을 상세하게 확인해오고,
3. 행여 빠진 게 있을세라 개발 검토까지 요청하면
개발팀이 기획자에게 신뢰감을 가지고
작업에 몰두할 수 있습니다.
그래서 어떻게?
새로운 기능의 UID를 만들고 나면
전체적으로 모든 페이지를 점검해야 합니다.
처음에는 이 과정이 아-주 오래 걸립니다.
(그리고 아-주 재미없습니다.
레고 설명서를 읽는데 레고가 없다고 생각하시면 됩니다.)
부품만 1만 개인 밀레니엄 팔콘 - 출처 : LEGO보통 작은 서비스는 UID가 100페이지 이내지만
역사가 길고, 기능이 복잡한 서비스의 UID는
수백 장이 훌쩍 넘는 경우도 있습니다.
더불어 서비스 기획자는
1. 처음부터 서비스를 만드는 케이스보다
2. 이미 만들어져 있는 서비스에 참여하는 경우가
많기 때문에 자신이 애초에 설계하지 않은 서비스는
전체적인 구조를 잘 모르는 경우가 많습니다.
그렇다고 UID를
날 잡고 앉아서 고시공부를 하듯이
보는 것은 별 도움이 되지 않습니다.
(잠만 쏟아집니다)
이런 거 봐도 눈에 아무것도 안 들어옵니다. 출처 : 저자이럴 때는 조급한 마음을 버리고
1. 지금 등록된 문제점과
2. 조만간 업데이트할 신규 기능부터
최우선적으로 숙지해야 합니다.
그 과정에서 관련이 있는 UID부터
하나씩 알아나간다고 마음을 먹으면
3달쯤 뒤에는 무난하게 전체 구조가 들어옵니다.
그때부터는 기획자가 걸어 다니는 UID가 되어
신규 기능이 영향을 줄만한 페이지들을 30분 이내에
쏙쏙! 골라낼 수 있습니다.
4. 변화과정이 잘 보입니다.
아~ 이렇게 바뀐 거구나!
좋은 UID는 변화 과정이 잘 보입니다.
서비스는 끊임없이 발전합니다.
기획자는 사용자들이 재잘재잘 말하는 소리를
명탐정 코난처럼 받아 적고 고민 또 고민합니다.
그 결과를 바탕으로
1. 새로운 기능을 기획하고
2. 있는 기능을 개선하고
3. 안 쓰는 기능을 삭제하기도 하죠.
이렇게 서비스에서 변화가 발생하면
설계도인 UID도 변경해야 합니다.
피카츄의 UID버전관리... - 출처 : 포켓몬 골드 버전UID버전 관리는 얼핏 생각하기에
굉장히 쉬워 보이지만
1. 항상 꼼꼼히 하는 것은 어렵고
2. 한번 잘못되면 아주 골치 아프기 때문에
조심해야 합니다.
가장 흔한 잘못의 예로는
1. 예전에 빠져야 할 기능이 UID에 남아있는 것
2. 새로 들어간 기능이 UID에서 사라진 것
3. 서로 다른 화면의 정책이 출동하는 것
등이 있습니다.
앱을 검증하는 직무인 QA분들은
기본적으로 UID와 앱이 일치하는지를 확인합니다.
위에서 말한 것처럼 UID에 오류가 있다면
멀쩡한 앱이 잘못되었다는
이슈가 끊임없이 올라오죠
(기획자의 메일함이 꽉꽉 찹니다.)
QA가 신고한 이슈는
5분 만에 간단하게 해결되는 경우도 있지만
여러 화면이 정교하게(?) 잘못된 경우라면
기획자의 하루가 순식간에 증발하기도 합니다.
여기에 더해 중간에 담당자가 바뀌기라도 하면
인수인계를 받은 기획자는
매우 끔찍한 상황에 놓이게 되죠.
이런 식으로 이슈가 쌓이면
'아나.. 차라리 처음부터 다시 하자고 할까'
고민하는 상태가 됩니다.
그래서 어떻게?
UID의 변화과정을 확인하기 위해서는
3가지를 꼼꼼히 관리해야 합니다.
첫째는 업데이트 페이지 관리입니다.
UID마다 버전업을 할 때 어떤 내용이 변경되었는지
적어두는 페이지가 있습니다.
이 업데이트 페이지를 꼼꼼히 적기 위해서는
1. 지-인짜 조그만 수정사항 하나도
구글 스프레드시트나, 위키 문서처럼
여러 사람과 공유하는 툴에 적어두어야 하고
2. 일부만 변경한 UID를
하나의 폴더에 차곡차곡 쌓아두어야 합니다.
(Figma 툴이 프로젝트를 관리할 수 있어 편합니다.)
그러다가 2-3달에 한번 정도
UID 버전업을 진행할 때가 되면
여러 사람이 기록했던 것을 싹싹 긁어모아
통합 작업을 하면 됩니다.
1년만 지나도 1페이지가 채워집니다. - 출처 : 저자'난 머리가 좋으니 괜찮아 ㅎㅎ'처럼
기억력에 조금이라도 의존하다간
이때 바로 지옥행 열차를 타게 됩니다.
둘째는 업데이트 내용 표시입니다.
직전 버전에서 변경된 주요 내용을
UID내부에 잘 보이도록 표시해야 합니다.
빨간색으로 잘 보이게 표시해주세요 - 출처 : 저자위 UID에 보이는 것처럼
이번 버전이 이전 버전 대비
업데이트한 사항을 색깔/도형을 사용해
명확하게 보여줘야 합니다.
(그다음 버전이 나오면 그다음 버전 것만!)
그래야 혹시 나중에 잘못된 것을 찾더라도
언제부터 우리 사이가 틀어진 건지 확인할 수 있습니다.
마지막은 여백 관리입니다.
앞서 여백을 충분히 둬야 한다는
말씀을 드렸었죠.
이렇게 충분한 여백은
버전 관리를 할 때 가장 빛을 발합니다.
UID를 고칠 때 대대적으로 고치는 경우는 잘 없습니다.
보통 조금씩 조금씩 고치는데요.
여백이 많으면 전체적인 얼개를 수정하지 않아도
1. 빠른 시간 내에
2. 아주 잘 보이게
수정 사항을 반영하고
버전을 관리할 수 있습니다.
5. 충분히 들으려 노력합니다.
저런 저런.. 그러셨군요..
좋은 UID는 충분히 들으려 노력합니다.
굳이 '충분히 듣습니다'라고 적지 않은 이유는
실제로는 매번 시간에 쫓겨
충-분히 듣는 것이 무척 어렵기 때문입니다. (눈물)
기획자의 99%는 천재가 아닙니다.
1. 개발자보다는 개발을 모르고
2. 디자이너보다는 디자인을 모르고
3. QA보다는 테스트 케이스를 모릅니다.
때문에 처음부터
모두를 만족시키는 완벽한 UID가
나오는 것은 불가능합니다.
건축 설계에서는
현장의 공사 작업이
설계사가 처음 그린 도면 '그대로'
착착 진행된다고 들었습니다.
건축은 설계 도면대로 진행됩니다. - 출처 : 인천시하지만 모바일 서비스는
건축 설계와는 완전히 다른 방식을 따릅니다.
UID는 기획자(건축사) 혼자가 아니라
모든 참여자와 함께 그리는 것이기 때문입니다.
저희 팀의 선배 분도 그렇지만
제가 아는 좋은 기획자들은
혼자서 모든 일을 다 잘하는 사람이라기보다
다른 사람들 말을 경청하고 의견을 존중하며
전체적인 시점에서 기능을 정리하는 사람입니다.
그래서 어떻게?
좋은 UID는 크게 두 가지를 들어야 합니다.
첫째 기능에 대한 의견을 들어야 합니다.
서비스를 만드는 조직의 구성은 각양각색이지만
기획자, 개발자, 디자이너가 한데 모여
회의하는 시간은 어디에나 존재합니다.
상황에 따라 스크럼이라 부르기도 하고,
단순히 기획/개발회의라고 부르기도 하죠
UID가 한번 만들어지면
이렇게 다양한 사람이 모인 회의 자리에서
간단하게라도 내용을 공유해야 합니다.
그리고 새로 도입되는 기능에 대한
개발/디자인/QA의 의견을
열심히 받아 적습니다.
경험적으로 복잡하고 커다란 기능을 설계하는 경우
UID를 아무리 치밀하게 작성하더라도
개발 도중에 최소한 4-5개의
큰 장애물을 발견하게 됩니다.
중위님!! 여기 빠진 API 찾았습니다. - 출처 : 한겨레모든 난관을 사전에 발견할 수는 없겠지만
본격적인 개발에 들어가기 앞서
장애물의 일부라도 미리 탐지하고 제거할 수 있다면
개발 목표를 달성하는데 큰 도움이 됩니다.
두 번째로 UID 제작의 부족함을
허심탄회하게 들어야 합니다.
기획자가 만든 UID를 가장 오랜 시간 동안
꼼꼼히 읽는 사람은 백엔드와 프론트엔드의
개발자들입니다.
아무리 섬세한 UID라고 하더라도
정해진 독자가 읽기에 불편하다면
그것은 잘못된 문서입니다.
하지만 기획자들이 개발자를 존중하는 것처럼
많은 개발자들은 기획자의 작업을 존중해주기 때문에
불만족스러운 부분이 있더라도 말을 하지 않습니다.
이때 기획자가 먼저 나서서
'제가 작성한 UID를 읽을 때 혹시 불편한 점 있으신가요?'
'설명하는 방식에서 개선할 점이 있을까요?'
하고 공손하게 물어보면
UID가 점점 독자 위주로 발전할 수 있습니다.
개발자 : 그니까요! 이렇게!! 동그라미 크게 그려줘요!! - 출처 : 트와이스이런 과정을 꾸준히 반복해서
기획자와 개발자의 커뮤니케이션 비용을 낮춰야
제시간에 개발을 마치고
둘 다 행복하게 퇴근할 수 있습니다.
잘 만든 UID로 즐겁게
UID문서를 처음 작업하는 기획자들은
'도구'를 많이 물어봅니다.
1. PPT 써도 되나요?
2. 스케치 사용법 알려주세요.
3. XD가 좋나요? 피그마가 좋나요?
와 같은 질문이 대부분입니다.
무엇으로 보다 어떻게가 중요합니다.하지만 UID를 작성하다 보면
위와 같은 도구가 '생각보다는'
중요하지 않다고 느낍니다.
앞선 도구들이 '반복 작업', '수정'
혹은 팀원 간 '공유'나 '협업'에는 장점이 있지만
문서 자체의 가독성과는 직결되지 않기 때문입니다.
1. 흐름이 있는 글을
2. 무엇이 중요한지 딱 부러지게 알려주고
3. 앞뒤 영향을 주는 기능을 분석한 뒤
4. 변경한 내용을 잘 표시해서
5. 주위 사람과 소통하면서 만들면
설령 종이에 크레파스로 그렸을지라도
좋은 UID라 부를 수 있습니다.
UID는 기본적으로 보험약관처럼
꼼꼼한 문서가 되어야 하지만
위 내용들을 잘 지키려 노력하면
연애편지와 비슷한
'읽고 싶은 문서'가 됩니다.
좋은 기능을 잘 설계하면 모두 즐겁게 일합니다. - 출처 : 서울경제앞으로 좋은 UID가 많이 나와서
기획/개발/디자인/QA가
블루마블 게임하듯이 깔깔 웃으며
작업하는 팀이 많아지면 좋겠습니다.
[표지출처] : 아이유 - 밤편지 뮤직비디오 스틸컷
