유저인터페이스(UI)설계와 그 산출물 작업은 시간낭비?

오렌지쥬스의 이미지

프로젝트 초반인데 현재 기존 시스템 분석과 앞으로의 시스템 설계를 병행하는 과정에 있습니다.
분석이 어느정도 진행된 업무는 UI 설계를 하는데 비지오와 파워포인트를 사용합니다.
양이 얼마나 많냐면 4명이서 한달동안 휴일없이 밤11시까지 작업을 해도 될까 말까 할 정도입니다.
제 예상으론 한달내 UI 설계와 그 산출물 출력 작업은 절대 불가능합니다.
설령 된다해도 이렇게해서 현업하고 컴펌해서 수정들어가면 경험상 분명히 시간에 쫓겨서 흐지부지 구렁이 담넘어가듯 아니면 클라이언트가 그만 때려치우고 이제 구현하라고 난리 칠겁니다.
이번달이 지나고 단 두달만에 구현을 완료해서 시스템을 설치해야 하는데
두달안에 설치못하면 설치하려고 해도 못하는 상황이 발생해서
프로젝트 쫑납니다.

제 소견으로는 UI설계와 그 산출물 작업은 필요하다 생각은 되나
방법론에 문제가 있는것 같습니다.
현재 DB분석과 설계에 투입된 사람이 단 1명입니다.
테이블만 457개이고 걸러내고 수정하고 추가해야 되는 작업도 있는데 기존 DB의 ERD도 전혀 없는 상태라서 이 사람은 지금 죽어납니다.
그나마 다행인것은 PB로 만들어진 기존 C/S 프로그램의 소스를 보고 어림짐작으로
ERD를 그려내고 있는데 당연할수도 있지만 지금 일주일이 다 되도록 아직 감도 못잡고 있습니다.

저는 이마당에 UI 설계 산출물 작업한다고 비지오에 파워포인트 잡고 있는거
다 때려치우고 당장 업무분석한 내용을 바탕으로
DB부터 잡고 늘어져야 된다고 봅니다.
그중 분석력이 떨어지는 사람에겐 UI 산출물 작업을 맡기고요.
물론 한사람에게 그 많은 양을 전담시키기엔 터무니 없어 보입니다.
그래서 비지오와 파워포인트는 끄고 종이와 연필을 사용해서 그려서 디자이너와 애기하고
현업들과는 가장 흔한 패턴을 보이는 몇가지 표준적인 UI만으로 앞으로 개발될 시스템의 UI에대해 간략히 애기하고 끝냈으면 합니다.

이미 2주나 지난 시점이고 그동안 비지오와 파워포인트로 작업한
분량도 적지 않은 마당에 이런 애기를 꺼내어서 괜히 리더의 기분만 상하게 하고
부정적이고 비관적인 사고방식의 사람으로 낙인찍힐까 싶어 말도 못꺼내는 형편입니다.
리더는 현업들 비위맞추느라 산출물 작업을 많이해서 뭔가 진행과정을 보여주고 싶어하지만 그 작업들을 모두에게 떠맡기고 있는 상태이고 이렇게가다가 정작 구현할 시간이 부족해서 납기일을 못맞출수도 있다는 위기감같은걸 느끼고 있을꺼라 봅니다.

과연 UI 설계에 비지오와 파워포인트를 사용해서 출력한 다음
바인딩해야 하는지를 여러 개발자들에게 묻고 싶고
UI 설계방식과 산출물 작업은 어느정도 선까지 해야하는지 애기해봤으면 합니다.
좋은 의견들 많이 부탁드립니다.

익명 사용자의 이미지

CS 구조를 웹으로 포팅하시는 군요.

언급하신 것처럼 DB가 우선이겠지요...
ERD가 안나온 마당에 UI라니...
불만을 가지실 만은 합니다.

하여튼, UI든 뭐든 간에
잘짜여진 기획과 든든한 도큐먼트가 있다는 것은
나중의 작업의 일관성을 유지와 진행속도 향상에
매우 큰 힘이 된다는 점은 매우 분명합니다.

그간의 경험을 보자면, UI 디자인에 소모되는 시간은 언제나 일정했습니다.
미리 안하면, 코딩하면서 고민하게 되더군요.
문서를 작성한다 해도, 문서를 작성하지 않았을 때의 작업분량의
10~20% 정도의 시간이 더 소모되는 정도였습니다.
그에 비해 코딩이 들어갔을 때 효율 향상과 절약되는 시간이 많아지고,
코딩에 디자인이 따라가게 되는 모순도 미연에 막을수도 있으며,
미리 디자인이 마무리 되기 때문에, 전체적으로 필요한 UI 구현 기반 설계도
편하죠.

다만, 비지오, 파워포인트는 설계 도큐먼트 작성 툴로서는 썩 마음에
들지는 않군요...

pool007의 이미지

일단 웹을 처음부터 개발한다고 하면, 파워포인트로 UI를 그리는 작업은 반드시 필요합니다. 그 이유는, (1) 고객이 자신의 requirement를 스스로 잘 모르고 있는데 이를 명확히 이해하게 해줌, (2) 개발자가 비즈니스 로직을 확실하게 이해하게 해 줌, (3) 필요한 기능을 편리하게 명시함 정도가 될 듯 합니다. 스토리 보드라는 말 들어보셨는지 모르지만.. UI는 껍데기만 그리는게 아니라, 사용자의 use case를 따라서 그리게 됩니다. 따라서 요구 사항과 이에 필요한 로직, 스키마를 생각하는데 필수적입니다. 질문하신 분은 UI 산출물을 '디자인'의 관점에서만 생각하시는 듯 싶은데, 실제로는 '개발'의 관점에서도 필요한 산출물입니다. 특히나, WEB은 C/S와 같은 리치 클라이언트 환경이 아니므로 가능한 동작이 무척이나 제한되어있기 때문에, 미리 UI에 대한 컨펌을 잘 받아놔야합니다.

다만 문제는 이걸 얼마나 빡시게 만드는가 하는 점이 될 듯 싶은데, VISIO까지 쓰신다는 걸 보니 너무 이쁘게 그리느라 시간을 많이 소비하는게 아닌가 하는 생각이 듭니다. 적당한 네모 세모 화살표 텍스트박스 정도면 길지 않은 시간으로 그릴 수 있을텐데라는 생각이 드는군요. 스토리보드는 어디까지나 사용자 입장에서 '스토리'를 잡으면 되는 일입니다.

개인적으로는 설계 문서를 만들어야 하느냐 말아야 하느냐를 생각하기 이전에, 500개 테이블이 있는 C/S를 단 네사람이 두달 안에 만드는게 처음부터 벅찼던게 아닌가 생각이 드네요.......

--
Passion is like genius; a miracle.

지리즈의 이미지

pool007 wrote:
개인적으로는 설계 문서를 만들어야 하느냐 말아야 하느냐를 생각하기 이전에, 500개 테이블이 있는 C/S를 단 네사람이 두달 안에 만드는게 처음부터 벅찼던게 아닌가 생각이 드네요.......

아주 날카로운 지적이시네요.....
고개가 절로 끄더겨집니다.

There is no spoon. Neo from the Matrix 1999.

kicom95의 이미지

Quote:

테이블만 457개이고 걸러내고 수정하고 추가해야 되는 작업도 있는데 기존 DB의 ERD도 전혀 없는 상태라서 이 사람은 지금 죽어납니다.
그나마 다행인것은 PB로 만들어진 기존 C/S 프로그램의 소스를 보고 어림짐작으로
ERD를 그려내고 있는데 당연할수도 있지만 지금 일주일이 다 되도록 아직 감도 못잡고 있습니다.

결론적으로 DB 구조의 완벽한 분석이 안됩니다...

기존의 C/S 를 만든 업체는 문을 닫은것으로 보이는데....

고객이 몇몇 기능을 요구하는데 어떤것은 단순해 보여도 처리가 힘든것도..

왜냐하면 DB 구조와 트리거 인테그러티 등을 정확히 모르면.....

DB 조작은 엄청난 일을 야기 시킬수 있습니다......

애초에 2달이라고 잡은 프로젝트는 문제가 있군요....불가능한 것으로......

그리고 개발자가 봉인가요 ?? 11시 까지 매일 일을 시킨다니.....

알아서 하는거 지만 결국은 시키는거 아닌가요 ?

그리고 디자인 좀 힘드시더라두 꼭 하셔야 합니다. 그 업체 전산 담당자의

OK 를 받는것두 좋지만... 실질적으로 사용하시는 분들이 OK 를 해야하며

화면 설계 OK 받으면 받드시 도장 받으시길.....

저도 이와 비숫한 작업을 했는데... 좀 허접하게 진행하다가....

디자인에서 빠꾸가 되어서 죽을 썻다는 ...... OTL

가자 해외로 ~ .. 돈 벌러.

pool007의 이미지

kicom95 wrote:
Quote:

테이블만 457개이고 걸러내고 수정하고 추가해야 되는 작업도 있는데 기존 DB의 ERD도 전혀 없는 상태라서 이 사람은 지금 죽어납니다.
그나마 다행인것은 PB로 만들어진 기존 C/S 프로그램의 소스를 보고 어림짐작으로
ERD를 그려내고 있는데 당연할수도 있지만 지금 일주일이 다 되도록 아직 감도 못잡고 있습니다.

결론적으로 DB 구조의 완벽한 분석이 안됩니다...

기존의 C/S 를 만든 업체는 문을 닫은것으로 보이는데....

고객이 몇몇 기능을 요구하는데 어떤것은 단순해 보여도 처리가 힘든것도..

왜냐하면 DB 구조와 트리거 인테그러티 등을 정확히 모르면.....

DB 조작은 엄청난 일을 야기 시킬수 있습니다......

애초에 2달이라고 잡은 프로젝트는 문제가 있군요....불가능한 것으로......

그리고 개발자가 봉인가요 ?? 11시 까지 매일 일을 시킨다니.....

알아서 하는거 지만 결국은 시키는거 아닌가요 ?

그리고 디자인 좀 힘드시더라두 꼭 하셔야 합니다. 그 업체 전산 담당자의

OK 를 받는것두 좋지만... 실질적으로 사용하시는 분들이 OK 를 해야하며

화면 설계 OK 받으면 받드시 도장 받으시길.....

저도 이와 비숫한 작업을 했는데... 좀 허접하게 진행하다가....

디자인에서 빠꾸가 되어서 죽을 썻다는 ...... OTL

저도 유사한 경험이있는데, UI에서 빠꾸되면 정말 망합니다. 업무용 웹이면 UI가 보통 복잡한게 아닌데, UI고치는 일이 정말 보통일이 아니예요..

--
Passion is like genius; a miracle.

creativeidler의 이미지

웹이면 그냥 HTML로 프로토타입을 만드는 게 더 나을 텐데요. 그러면 나중에 코딩할 때 그대로 활용할 수 있거든요. 나중에 할 일을 지금 하는 거라고 생각하면서 하면 한결 마음이 편합니다. 요즘은 웹 프로젝트들은 다 HTML로 프로토타이핑 하지 않나요?

지리즈의 이미지

creativeidler wrote:
웹이면 그냥 HTML로 프로토타입을 만드는 게 더 나을 텐데요. 그러면 나중에 코딩할 때 그대로 활용할 수 있거든요. 나중에 할 일을 지금 하는 거라고 생각하면서 하면 한결 마음이 편합니다. 요즘은 웹 프로젝트들은 다 HTML로 프로토타이핑 하지 않나요?

디자인을 외주를 주게 되면... 어쩔 수가 없더군요...
디자이너에게 선입관을 주지 않게 하기 위해...
다른 문서형태로 넘겨주는 것이 바람직한 것 같습니다.

물론 디자인도 개발자들이 병행해야 한다던가,
디자인 프로토타입이 나와 있다면, 별외지만요...

There is no spoon. Neo from the Matrix 1999.

익명 사용자의 이미지

개발자에게 편한건 사실이지만, 문서로 만들면 가능한 주석이나 부가적인 설명을 달곳이 없어집니다. 프로세스에서 페이지간의 흐름이나, 버튼의 기능, 연결되는 데이타베이스 필드등을 표시하기 위해서는 먼저 스토리보드나 화면설계를 하는게 맞습니다.

설계도 없이 프로토타이핑을 할수는 없지 않나요?

지리즈의 이미지

alvarez wrote:
개발자에게 편한건 사실이지만, 문서로 만들면 가능한 주석이나 부가적인 설명을 달곳이 없어집니다. 프로세스에서 페이지간의 흐름이나, 버튼의 기능, 연결되는 데이타베이스 필드등을 표시하기 위해서는 먼저 스토리보드나 화면설계를 하는게 맞습니다.

설계도 없이 프로토타이핑을 할수는 없지 않나요?

만약, 디자인 양식이 먼저 나와 있으면,
copy&paste로 작업한 통 HTML을 작성합니다.
그리고, 이것을 캡쳐 받아서 파워포인트같은데서 추가 설명을 기입하죠...

그리고, 나중에 이 통 HTML을 이용해서 코딩에 들어갑니다.

아무래도 프로그래머들이라, 문서작업보다는 이쪽이..
이게 시간이 오히려 절약되기도 하더군요.

There is no spoon. Neo from the Matrix 1999.

오렌지쥬스의 이미지

개발기간이 두달은 아니구요. 구현기간이 두달입니다. 구현후 테스트 기간은 석달입니다.
분석, 설계는 몇달전에 모업체에서 이 프로젝트 하러 들어왔다가
무슨일이 있었는지 손빼고 나갔답니다. 위약금까지 물리고..
앞으로 이쪽 바닥으로 영업하는데 애로사항이 있을꺼란걸 알면서도..
결국 앞에서 시간 다 까먹고 저희는 뒤늦게 들어와서 시간이 정말 촉박해요..
총 개발인원은 6명이고 팀장과 리더가 각각 두명씩이니 10명이라 보면 됩니다.

애기를 UI 설계는 어떤식으로 하고 툴을 사용해서 산출물 작업을 한다면
어떤 툴이 좋은지등을 애기했으면 좋겠습니다. 경험담을 들려주셔도 좋구요. ^^

익명 사용자의 이미지

윗분들 이야기 듣고 나니..

it 가 무지막지한 스트레스의 노가다라는걸 새삼느낍니다.

이 속에서 무슨 코딩의 아트니 하는걸 따지겠습니까.

시스템의 최적화 같은 것도 별로 기대하기 힘들것같고..

앞으로 학문을 하는게 더 나을거 같은 생각이 불현듯...
듭니다....ㅠ.ㅠ

saxboy의 이미지

이럴수가 wrote:
윗분들 이야기 듣고 나니..

it 가 무지막지한 스트레스의 노가다라는걸 새삼느낍니다.

이 속에서 무슨 코딩의 아트니 하는걸 따지겠습니까.

시스템의 최적화 같은 것도 별로 기대하기 힘들것같고..

앞으로 학문을 하는게 더 나을거 같은 생각이 불현듯...
듭니다....ㅠ.ㅠ

글쎄요. IT에는 SI일만 있는 것은 아니지요.
IT중에서도 소프트웨어 엔지니어라는 직업이 꽤 큰 노가다인 것은 틀림없지만, 다른 직업이라고 크게 다를 것도 없지요.

저는 임베디드 어쩌구라는 쪽의 일을 하고 있다보니 최적화때문에 골머리를 썩는 경우가 많더군요. 일의 특성이기는 하지만 저희는 제품을 개발하면서 양이 많은 일보다는 답이 없는 한문제를 붙들고 시간을 보내는 경우가 많습니다. 사실은 일의 양도 좀 많기는 하지만... 쩝.

ikong의 이미지

저도 2년 넘게 웹기반 임베디드 시스템(말이 임베디드 시스템이지 서버 솔루션을 임베디드화 하는 것이었음)하다
결국 실패했는데요..

관건은 해당 제품 비즈니스 로직의 불확실(정확히 아는 사람이 없었음)과 UI 프로토타이핑이었습니다.
경쟁사 제품을 벤치마킹해서 기본기능 뽑아서 구현해야 되는데 비즈니스 로직과 UI가 제대로 되어 있지 않으니
DB가 제대로 나오지 않았고 UI와 비즈니스 로직을 수정하면서 계속 시간만 잡아먹은 거지요..

그래서 초기 UI 분석과 프로토타이핑이 중요하다는 것을 뼈저리게 느꼈죠.^^..
특히 잘 모르는 분야는 UI 프로토타이핑과 이의 데모 및 분석을 통해서 비즈니스 로직을 정립한 뒤
DB 설계 및 로직 설계를 진행해야 될 것입니다.

5년전 글에 댓글을 다는 이유는 다른분들에게 조금이나마 도움이 되고 싶어서구요,
최근에 3년전에 이 툴이 나왔으면 정말 도움이 됐을 것으로 생각하는 개발툴이 나와서 알려드리고 싶어서입니다.

MS의 SketchFlow라는 UI 프로토타이핑 툴인데 구글링 또는 네이년에서 찾아보시면 정보를 얻으실 수 있을 겁니다.
http://www.microsoft.com/korea/expression/products/Sketchflow_Overview.aspx

이 쓰레드를 보시는 분께 행운이..

━━━━━━━━━━━━━━━━━━━━━━━
Good luck~~. ikong.
jpkong@gmail.com
━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━ Good luck~~. ikong.
ikong@korea.com ━━━━━━━━━━━━━━━━━━━━━━━