일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- ecto
- Flash
- 네이버
- Photos
- Apple
- blo9
- WordPress
- 웹표준
- Information Design
- RSS
- japan
- 출장
- 오픈API
- management
- 가족여행
- naver
- mashup
- Programming
- LG
- 팀 빌딩
- wired
- Life2.0
- MAC
- 다음
- SmallWorld
- nhn
- stereotype
- wp
- Book
- UI개발
- Today
- Total
ideapla.net
디자인 수정은 버그다 본문
UI개발자는 가장 밀접하게 일하는 사람이 디자이너다. 그만큼 대화가 잘 통해야 하고 서로의 분야에 대해 이해하고 존중하는 자세가 필요하다. 하지만 코딩이라는 업무를 디자이너의 입장에서 그만큼 전문분야라고 인정하고 있는지 의심스러울 때가 많다.
두 분야의 충돌이 발생할 때는 일정에 따라 작업을 진행하거나 수정작업이 이루어질 때이다. 전자의 문제는 디자인이 늦게 나오는 것이고, 후자는 빈번한 수정과 수정작업이 일정에 없다는 점이다. 수정 작업 기간이 일정에 포함되어야 하지만 대부분의 UI개발업무는 아직도 이부분을 간과하고 지나치기 일쑤다.
디자인이 늦게 나오는 점에 대해서는 일반적으로 '감성적이고 창조적인 작업이기 때문에 생각할 시간이 길어진다'는 입장을 펼친다. 다른 이유는 잘 모르겠다. 빡빡한 일정때문이라면 초기에 그만큼의 일정을 요구하지 못했기에 발생하는 문제이니 그건 타협(일정을 더 요청하거나 어느 정도 적절한 선에서 디자인 퀄리티를 마무리하는 것)을 해야 할 것이다.
전문가는 자신이 맡은 업무에 대해 대략의 예상 일정을 잘 수립해야 한다. 그리고 일정에 따라 적정 수위를 조절하여 업무를 마무리 한다. 그리고 일정이 늦어지는 것이 대해 '핑계'를 대서는 안된다. 이 원칙은 디자인뿐만 아니라 개발에 있어서의 전문성에도 동일하게 적용할 수 있다. 개발 작업(코딩이든 프로그래밍이든) 역시 창조적인 작업임을 인정한다면 이런 말이 변명이라고 인식하지 않을까? 그것이 감성과 논리로 갈린다 해도 어디까지나 개발에서도 창의성을 요구한다. 그럼 남는 문제는 애초에 어려운 일정에 잘못 동의한 점과 적절한 수위조절이 부족했다고 볼 수 있다.
수정 작업에 있어서 개발자가 느끼는 오해(실제로 진실일 수도 있다)는 디자이너의 변심으로 인한 수정이 많다는 것이다. '왜 확정된 디자인을 수정해야 하는가?'에 대해 고민해 볼 수 있다. 개발과 비교해 본다면, 아마 그건 잘못된 로직으로 인한 버그에 빗댈 수 있을 것이다.
본질적으로 완전한 디자인 결과물은 있을 수 없다. 코드 역시 버그 없이 완벽히 동작할 수 없다. IT에서 결과물의 모호성은 임계치(전문가들이 설정한 적정 만족 수준)를 상회하는 선에서 타협해야 한다.
그렇다면 이것이 왜 문제가 되는가?
개발 결과에 대한 수정은 오픈 후에 발생하는 건에 대해서 '문제'가 발생한 것으로 간주한다. 하지만 디자인 수정은 오픈 전에 더욱 빈번하게 일어나고, 개발 기간을 침범한다. 이것이 프로젝트 진행을 가로막는 위험한 충돌 상황이다.
이 문제를 해결하는 방법은?
아이러니 하게도 이러한 상황에 처했을 때 대부분의 해법은 '서로에 대한 존중'에서 나온다. 개발자(UI개발과 웹개발 등)를 그리고 디자이너를 서로 전문가라고 인식하고, 자신의 과오를 인정하고, 업무 프로세스에 장애가 발생한 상황을 서로 절충해 가면서 해결하려고 노력하면 아무런 문제가 없다(앞에선 웃고 뒤에선 까댈 수 있어도 크게 문제는 안된다). 하지만 '내 일이 중요하다'라고 아집을 부리며 요구하기에 나선다면 프로젝트는 교착상태에 빠진다.
결론은
- 프로젝트 초기에 일정 예상이 적절해야 한다(완벽할 수는 절대 없다).
- 서로 전문가이고 각자의 업무에 대한 가치판단이 정확하다고 인정해야 한다.
- 내 일만 하는 것이 아닌 함께 하는 프로젝트가 있다는 점을 계속 인식한다(기간이 길어지면 더더욱!).