저는 몇년간 여러 프로젝트를 진행하면서, 그 프로젝트들 사이에서 주로 개발을, 때로는 설계를 진행해보기도 했는데요, (어떤때는 혼자 프로젝트를 진행하며 모든걸 해보기도 하고..)
경험속에서 어떠한 상황이 있었고, 이러한 경우에는 어떤 방식을 택해 해결을 해볼 수 있는지 고민해보고자 글을 작성해봅니다!
보통 요즘의 기업들이 에자일 방식(소프트웨어 개발론으로 생각해보자면)을 택하고 있는 이상 기존의 요구사항을 토대로 프로토타입성의 결과물을 만들어내고 이후 추가적인 요구사항을 받아 보완해나아가는 형식을 취하고 있습니다.
에자일 방식은 그만큼 유저가 필요한 기능을 파악하고 검토 그리고 다시 수정을 하기 위한 프로젝트에서 가장 적합한 프로세스이기는 하지만, 문제는 이 에자일 방식에서의 설계 방식에 많은 어려움을 겪기도 합니다.
(에자일방식이라고 해서 설계자료 없이 개발을 할 순 없으니 말이죠.)
시스템 개발이라는건 상황에 따라서는 기존 개발방식을 깨고 새로운 개발방식이 필요한 경우가 있습니다.
이러한 경우는 기존 요구사항에서 새로운 요구사항으로 변경되면서 어쩔수없이 시스템의 구조가 변경되어야하는 경우인데,
이런 경우에는 개발자들은 리팩토링이나, 그냥 새로 개발하는 경우가 종종 발생하곤 합니다. (그냥 새로 만드는게 더 빠른 경우)
큰 문제는 리팩토링이 되었건, 새로 만드는 만드는 경우가 되었건 시간적, 인력적 코스트는 엄청나게 들곤 하죠..(결국엔 Money!)
그렇다면 설계자는 이러한 경우를 피하기 위해서는 어떻게 해야할까요?
기획의 명확한 의도를 파악하고(요구사항을 정확히 파악), 그 의도에서 새로 생길 수 있는 수정사항을 미리 고려하는 것입니다.
말이 어려울 수 있으니, 쉽게 설명해보자면.. 흠..
기획단계에서 나온 모든 요구사항을 전부 고려를 하는겁니다.
더 쉽게 말하면 확장성을 모두 고려해서 설계를 해야한다는 말이 가장 와닿을 수 있겠네요.
물론, 그 모든 요구사항을 충족할만한 시스템은 만들기 어렵겠지만,
확장성을 고려한 한번의 설계로 나중에도 문제 없이 개발을 진행할 수 있는 견고한 시스템(확장성이 쉬운)이 만들어진다면
개발자에게 있어서는 너무 감사하게도 나중에 생성될 야근시간이(시간적 코스트) 줄어들테고,
투입될 인력적인 부분(인력적 코스트)에 있어서도 많은 최적화를 이뤄낼 수 있을겁니다.
여기서 중요한건 설계뿐만이 아니라는 겁니다.
당연하게도 기획자는 기획의 의도를 명확히 해야할 필요가 있으며,
그 기획의 의도속에서도 추가적인 아이디어가 있다면 미리미리 첨언해준다면(그냥 툭 튀어나온 반영하지 않을 요구사항도 따로 정리해서) 설계에 있어 미리 확장성을 고려할 여지를 남겨두게 된다는 겁니다.
여기서 제 경험상으론 단순 아이디어(그냥 툭 내뱉은 아이디어)는 결코 단순 아이디어가 아닙니다.
그저 후보군으로 나왔었던 아이디어더라도, 추후 어떠한 결과로 다시 구현하게 될 지 모르는 암흑속의 존재(?)일지 모르기 때문에
기획자는 번거롭겠지만, 추후에 확장이 될 여지가 단 0.0000001%라도 있다면 설계자에게 어떠한 상황으로든 알려주는 것이 좋습니다.
이런 면에 있어서 저는 보통 기획부분과 설계부분을 엮어서 생각하는 경우가 있는데요,
보통 기획단에서 사용하는 Wireframe을 저는 개발하기에 좀 더 편한 저만의 Wireframe으로 조금 변형을 해서 쓰곤 합니다.
이러한 이유는 기획자의 의도가 개발단으로 넘어가면서 변질되지 않는것을 추구하기 때문이기는 하는데..
사실 개발자(저)의 시선으로 보면 기획 단의 Wireframe은 개발에 참고하기 위한 부분이 많이 부족하다고 느껴집니다. (구체적일수록 좋은데 말이죠..)
화면설계서라는 설계문서가 중간에 들어가기는 하지만, 이러한 화면설계서에서도 단순히 Wireframe과 요구사항만 보고 설계문서를 만들어내기란 쉽지 않기에 사람이 보기 편한 이미지적인 요소인 Wireframe을 좀 더 개발자에게도 확 와닿는 하나의 개발문서가 되었으면 좋겠다는 생각으로 커스텀을 해보게 되었습니다. (제가 본 블로그에 작성한 Wireframe에 관한 내용도 있으니, 하단의 링크를 통해 구경해보셔도 좋을 것 같습니다.)
깔끔하게 휴식을 마치고 와서 그런지 그나마 머리가 말끔해져서 오늘은 Wireframe을 소개해볼까 합니다. (?! 갑자기 ?!)
사실 제가 쓰는 이런 설계단의 문서들은 어려워하시거나 모르시는 분들이 많을 수 있습니다.
개발을 진행하시는 분들은 문서를 받아서 볼 수 있겠지만, 보기보다는 그냥 고객의 설명이나 상급 개발자의 설명만 듣고(회의 등) 변경된 내용으로 진행하는 경우가 많은 것 같더라구요.
그만큼 폭포수 모형보다도 애자일 방식을 택하는 기업도 많다는 의미이기도 하구요. (Prototype 만들고 수정하고 반복적인..)
사실 이 설계라는게 생각보다 시간도 잡아먹는거기도하고, 개발자에게 대충 '대략적인 혹은 완성된 UI' 그림만 던져주면 된다! 이런 부분이 없지않아 있어서 개발자는 그 대략적이거나 완성된 UI를 시작으로 개발-수정작업을 거쳐 완성본을 만드는 경우가 많은 것 같습니다. (ㅠㅠ)
저는 개인적으로 이런 부분들을 보완하고자 제가 개발하면서 개인적으로 만드는 문서들이기 때문에 어려워하시거나 잘 모르시는 분들도 많은 것 같습니다.
(사실 잘 찾아보면 소프트웨어 공학적인 부분에서 많은 내용을 찾아볼 수 있지만.. 개발 문서가 우선이다보니..)
근데 웃긴 사실은 이런 문서를 미리 만들어 두면 몇번의 수정만 거치면 완료 보고서 제출시에 편리해진다는 점이 장점이있습니다. (우려먹기? ㅋㅋㅋ)
또 설계서가 있는 만큼 개발을 진행해야하는 사람들에게도 이렇게 개발을 해야한다! 라는 프로젝트 개발 가이드 라인이 잡히다보니 같이 개발하는 동료나 후배들에게 입아프게 말할 필요도 많이 줄어 만족도는 꽤나 높은 편입니다. (개인적으로는 말이죠 ㅋㅋ)
물론 이해가 안되는 부분은 커뮤니케이션을 진행해야하지만 말이죠 ㅎ
음.. 벌써부터 말이 너무 많네요. 이런 주저리 거리는 부분은 본론에 들어가서 추가적으로 하도록 하고! 지금! 바로! 본론으로 들어가보겠습니다.
Wireframe?
Wireframe...? 그게.. 뭐예요...?
협업 중에 있어서도 Wireframe의 존재를 잘 모르시는 분들은 생각보다 많습니다.
그만큼 분석 및 설계시에 화면설계로 바로 넘어가는 경우는 많아도, Wireframe을 잡고 넘어가는 경우는 생각보다 드물기 때문에(ㅠ..ㅠ) 이런 경우가 생각보다 많이 발생하는 것 같습니다.
음.. 화면설계가 나오면 그나마 낫긴하지만, 이보다 더 심각한건 Wireframe이 확정되지 않은 상태에서 바로 디자인을 진행하는 경우는 생각보다 여러모로 힘들어집니다. (이러한 경우 Wireframe이 불안정하다보니, 바로 디자인을 시작하는 경우 여러번의 디자인 변경을 체험할 수 있습니다... 심한경우에는 서로의 이해관계가 통하지 않아 만족도가 낮은 완성본이 나올 가능성도 있습니다.ㅠㅠㅠ)
이런 경우 UI를 디자인 하는 디자이너, UI 목업이나 화면설계서만 보고 개발을 진행하던 개발자는 날마다 다크써클이 생겨나기 일쑤입니다. ㅇ_ㅇ;;;
이런 변경을 초기에 잡는 방법 중 하나가 개인적으로는 Wireframe이라 생각합니다.
그래서 Wireframe이 무엇이죠?
우선 어려운 내용들 다 접어두고 쉽게 설명하자면 기본 설계를 위한 '뼈대'입니다.
Wireframe을 잡아주면 거기에 쌓아 올리는 디자인적 요소든 개발적 요소든 어느정도 기본적인 '뼈대'가 잡혀있기 때문에 이후 구조적인 요소에서는 큰 변동사항이 거의 없어지게 됩니다.
사실 그 내면을 들여다보면 기획적인 요소가 조금 섞여있을 수 있는데, 이는 프로젝트의 제작을 원하는 사람의 생각을 '명확'하게 해주는 작업이기 때문에 그럴겁니다.
이 '명확'해진 '뼈대'위에 *구조물을 쌓아올리는 작업이 바로 디자이너와 개발자의 협업을 통한 분석-설계-개발이 진행 되는 거죠.
그만큼 Wireframe을 잡는건 굉장히 어려운 작업이기도 하지만, 한번 확실하게 잡아진 Wireframe 하나만 있으면, 이후 분석 설계 디자인 등은 굉장히 편리하고 빠르게 넘어갈 수 있습니다.
음.. 이렇게 말로만 하면 어려우니까 이쯤에서 비장의 카드 이미지를 넣어봐야겠네요.
직접 보시죠!
백문이 불여일견
백번 듣는거보다 한번 보시죠!
Wireframe (장비 관리 - 장비 등록)
장비관리 Wireframe, 만든이 : Karzin
위 이미지는 제가 Project.다원 Ensemble을 진행하면서 그렸던 Wireframe입니다. (참고 링크)
사실 여기에는 제 개인적인 개발적 요소들이 들어가기도 했는데(Component의 종류), 이 문서 하나로 기획을 했던 저의 아이디어를 종합하고, 어떤식으로 개발을 해나가야할지 미리 '뼈대'가 잡아지고, 이렇게 진행을 해야겠다는 정보가 그림 하나로 완성이 된겁니다.
'뼈대'가 어느정도 작업이 완료되었다면, 이제 화면설계서가 굉장히 빠르게 나올 수 있는데, 이 화면설계서까지 나오면 사실 개발자에게 있어 이런 확정된(화먼설계서) 내용을 만드는 작업만큼 쉬운일은 또 없을겁니다.
그럼 Wireframe을 토대로 만들어진 화면설계서를 잠깐 구경을 해보실까요?
화면설계서(장비 관리 - 장비 등록)
장비관리 화면설계서, 만든이 : Karzin
화면설계서를 어떻게보면 한단계 위의 Wireframe과 비교를 해보면 크게 변경된 내용은 없어보입니다.
하지만 좀 더 그 내부를 살펴보면 Button Component는 '등록'이라는 text가지정되어 변경되었거나, 이외에도 각 Component들의 사용의 예시를 보여줌으로써 개발자는 Wireframe과 비교를 해가며 알맞는 개발 Component를 선택하여 개발해 나갈 수 있게 해주는 것을 알 수 있습니다.
사실 이런 부분들이 제 입맛대로 바꾼 부분이 있어 조금 변칙적일 수는 있으나, 저의 경우 'Wireframe'단에서는 어떠한 Component를 사용할지 명확하게 뼈대를 잡아주고, 이후 해당 화면에 DB를 연동했을 때 어떤식으로 화면에 보일것인지를(뿌려줄 것인지를) '화면설계서'를 통해서 보일 수 있게 화면설계서를 마치 Prototype인 마냥 설계를 진행하는데, 이렇게 해주면 좋은점이 개발자 입장에서는 이 정도의 설계서만 있으면 이후에는 걱정없이 개발에만 집중할 수 있다는 점입니다.
물론 제가 진행중인 개인 프로젝트에서는 Wireframe과 화면설계서만으로 개발을 진행하지만 이는 기본적으로 Bootstrap을 사용함으로써 어느정도 디자인 단계를 보완할 수 있는 부분이라서 그런거기도하지만, 사실 여러가지 따지자면 디자인도 들어갈테고, Diagram같은 좀 더 개발의 기초를 잡아주는 부분도 있을 수 있으나, 이러한 부분들은 디자이너나 개발자간에 서로 협업(커뮤니케이션)을 하며 어떠한 디자인을 어떠한 로직으로써 어떻게 구현을 할지 머릿속에 상상하며 그려가야하는 작업이라고 생각하기 때문에, 자세한 언급은 삼가했습니다. (또 주저리주저리 말만 길어져서 다들 졸리게됩니다 ㅠㅠ)
이처럼 Wireframe을 한번 그려두면 자신의 생각을 남들에게 명확하게 전달할 수 있기 때문에 좀 더 자신이 원하는 프로젝트로 진행이 될 수 있는데, 물론 아쉬운 부분이 생길수 없다는 보장은 못하지만(기술적 요소 등으로 Wireframe대로의 개발이 힘든 경우 등등), 서로간 계속되는 커뮤니케이션을 통해 보완을 해나간다면 마지막에는 기획물에 걸맞는 마음에 드는 결과물을 뽑아낼 수 있습니다.
그만큼 Wireframe 자체가 굉장히 중요하기도 하구요.
* 위에서도 언급했지만(개발적 요소-Component의 종류), 항상 그렇듯 저는 제 개인적인 입맛대로 문서작성을 진행하기에 기존 Wireframe보다 변칙적인 부분이 많을 수 있습니다.
* 이는 제가 좀더 개발자의 측면에서 바라보는 부분들과 개인적인 경험들을 토대로 변칙적인 부분으로써 발전한거이므로 양해부탁드립니다 ㅠ
그럼 Wireframe은 누가 만들어야 하나요??
이쯤오면 궁금해질겁니다. Wireframe은 매우 어려워보이는데 누가 만들어야할까요?
그 내면을 깊이 파고들면 Wireframe은 기획적인 요소가 많이 들어가 있기 때문에 기획자가 만들면 기획자가 원하는 굉장히 고퀄리티의 결과물을 뽑을 수 있을겁니다.
하지만, 생각보다 Wireframe을 쉽게 보기란 힘들 수 있는데요, 저는 생각합니다. 이럴때는 바로 유비무환(有備無患)이라는 사자성어가 있습니다.
그냥 누가 되었든 미리 준비해두시고 confirm을 받아야할 담당자에게 보여주는겁니다!
'우리는 지난 회의를 통해 이렇게 뼈대를 잡았으며, 때문에 담당자님께 이대로 진행해도 될지에 대해 confirm을 요청합니다. 맘에 드신다면 이대로 분석-설계-개발이 진행될 것입니다.' 라고요!
사실 이러한 경우에는 대체적으로 담당자에게도 아직 확고한 '뼈대'가 없거나, 어떻게 만들어야할지를 모르는 경우가 대다수입니다. 이럴때 이런식으로 만드려 하는데 진행해도 괜찮을까요? 라고 연락이 오는 만큼 반가운일은 특히나 없을겁니다.
분명 담당자는 확인을 하고 자신이 생각한(그려본) 내용과 비교를 해가며 어느정도의 피드백과 커뮤니케이션이 오가다보면 확고하게 '뼈대'가 잡혀나갈겁니다.
그만큼 커뮤니케이션에 시간이 많이 걸릴수도 있지만, 이런 확실한 '뼈대'가 완성되는 순간에는 분명 담당자에게 있어서는 굉장히 좋은 결과물로 남을 것입니다.
Wirframe의 장단점
마지막으로 Wireframe을 사용함으로써의 장단점을 한번 보시죠!
음.. 우선 단점부터 이야기해보겠습니다.
- 시간적 Cost
- 명확함의 어려움
하나씩 잡고 설명을 해보자면
첫번째로 시간적인 비용이 있습니다.
기획자-디자이너-개발자 간 서로의 커뮤니케이션으로 인해 잃을 수 있는 시간적인 비용을 말하는건데, 사실 이는 명확한 Wireframe의 설계로 분석/설계 단계에서 더 많은 시간적인 비용을 절약할 수 있어 어찌보면 양날의 검같은 존재입니다. 사실 이러한 부분은 제가 생각하고 경험하기로는 중간의 PM역할이 가장 중요하다고 생각을 하는데요, 커뮤니케이션의 중간에 서서 시간의 비용을 최대한 절약할 수 있는 방법을 숙련된 자신의 경험 등을 사용해 저울질해가며 작업을 원활하게 진행을 해주는 부분으로, 앞서 이야기 나온것처럼 경험에서 우러러 나오는 부분이 아닐까 생각하고 있습니다.
그만큼 분석/설계단계에서의 작업이 더뎌진다면 개발은 더더욱이 미뤄지게 될테니 시간적인 요소를 꼭 체크해가면서 커뮤니케이션을 하는게 가장 중요하지 않을까 합니다.
두번째로는 명확함의 어려움이 있습니다.
사실 명확하다는 말처럼 또 어려운게 어딨을까 싶네요. 말이 명확하다일뿐이지 보는 시각에 따라 명확하지 않음은 분명이 나타날테니 말이죠. 이러한 부분의 해결은 사실상 위에서 말한 커뮤니케이션을 통해 해결을 해나가는 방법밖에는 없다고 생각합니다. 분명 기획-디자인-개발- 등등 여러 관점에서의 시점은 각각 다르니까요.
그럼 이번에는 장점을 이야기해보도록 하겠습니다.
- 시간적 Cost
- 이후 작업이 용이 (스무스)
- 인력의 최적화
- 백문이 불여일견
첫번째 시간적인 비용부터 설명해보자면, 위의 단점처럼 장점과 단점이 될 수 있는 양날의 검인 부분입니다.
그만큼 잘 저울질해가면서 최상의 시간적 비용을 들이고 원하는 프로젝트로 이끌어가는 방법을 찾아가야하는게 최우선이라 보여집니다. 이런 부분은 어쩔수 없이 저에게는 부족한 경험에서 우러러나오는 부분이기 떄문에, 결국 조율은 경험자에게 유리할 수 있다 보여집니다.
두번째로는 이후의 작업이 용이(스무스)해진다는 부분입니다.
잘 만들어둔 Wireframe만 있다면, 이후 분석/설계문서는 기획의 의도가 정확하게 파악이 되었기 때문에 스무스하게 작업이 진행이 된다는 겁니다. 또 그만큼 잘 제작이 되었다면 개발까지도 큰 이슈없이 진행이 될거고, 빠른 Prototype이 나옴으로써 기획을 한 담당자도 검토를 통해 개발진등은 어느정도의 기간내 수용가능한 기능 변경이나 디자인 변경까지도 가능하다는 장점이 있을 수 있습니다. 물론 이런 기능이나 디자인의 변경에 한해서는 민감한 부분이 많이 있어서 변경에 대한 작업진행시에는 어느정도 서로의 커뮤니케이션을 통한 이해관계가 꼭 필요하겠지만 말이죠.
세번째는 인력의 최적화입니다.
인력이 많다면 분명 개발은 빠르게 진행될 수 있겠지만, 그렇다고해서 오버해서 넣을 필요는 없는 프로젝트가 많을텐데요, 이러한 경우 개발을 위한 설계문서가 제대로 잡힌다면 인력의 최적화 또한 이루어지게 됩니다. 해당 부분도 사실 경험자가 필요한 부분이긴 한데, 미리 각 인력의 시간당 개발 진행도를 미리 파악하고 알아둘 필요가 있고, 어느정도 파악이 된 경우 설계문서에 맞춘 각 개발인력을 최적화해서 배치할 수 있어 개발 인력을 정말 최적으로 부려(??)먹을 수 있습니다. 경험자가 필요한 만큼 이는 PL이나 PM의 역할이 중요한데, 그만큼 자신이 관리하는 인력의 실력등을 미리 파악하는 시간이 필요할 것입니다.
네번째로 백문이 불여일견입니다!
사실 이걸 저는 큰 장점으로 뽑고는 있는데, 이는 기획자의 의도를 백번의 말보다도 한번의 Wireframe으로써 상대방을 이해시킬 수 있다는 부분입니다. 우리는 커뮤니케이션을 진행할 때 항상 문제시 되는 부분은 서로 다른 성격의 사람들을 '이해'시켜야한다는 부분일겁니다. 자신의 의도를 명확하게 알려주고 상대를 이해시킴으로써 더 좋은 퀄리티의 프로젝트 완성물을 탄생시키는 것이죠. 사실 이러한 부분은 쉬운부분이 아닌만큼 굉장히 중요한 부분으로 자리잡고 있는데, 백번의 말보다 한번의 Wireframe으로 해결이 된다면? 이처럼 좋은 해결방법은 또 없을겁니다. (물론 이런 부분은 Wireframe의 완성도나, 추가적인 커뮤니케이션이 있을 수 있으나, 여러번의 커뮤니케이션을 최소화할 수 있는 좋은 방법이라고는 생각합니다.)
이처럼 우리에게 당장 필요한건 개발도 중요하지만, 분석/설계를 제대로 할줄 아는 기술도 중요하다고 생각합니다.
오늘은 Wireframe에 대해서 잠깐(???) 설명하는 시간을 가져봤는데, 좀 더 이미지를 많이 넣어서 졸음 방지를 해드릴껄(???) 하는 글이네요.
슬슬 졸음이 몰려올 시간일거라 오늘은 이쯤에서 마무리를 하도록 하겠습니다~
쓰면서도 알았지만 말 진짜 많이썼네요.
누가보려나 싶을정도로요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
글을 읽어보시는 분들에게 큰 도움이 되려나 모르겠지만 되었으면 좋겠네요.
음.. 그래도 개인적인 경험과 공부를 토대로 작성을 하다보니 프로그램쪽으로 진출하는 새내기들에게는 조금이나마 유익한 글이 되지 않을까 싶습니다. 저 꼬꼬마때는 개발도 개발이지만, 기획단계부터 시작해서 분석이나 설계 등등 이런한 글을 읽어보고싶었는데, 없었어가지구.. Google에 'JAVA OOO만들기' 같은건 검색하면 쉽게 쉽게 나온다지만, 이런 기획부터 설계관련 이야기를 풀어놓은곳이 (제가 찾아봤을땐) 없었거든요.ㅠㅠ 제가 가진 경험과 공부한 내용들을 토대로 짜집기해서 머릿속에 나온거라 많은 부분 부족할 수 있지만, 한번쯤 읽어보시면 유익할거라 생각듭니다.
혹시 수정해야할 부분이라던가 있으면 댓글이나 메일주시면 확인해서 수정해두도록하겠습니다.
물론 질문도 항상 받고 있구요~
그럼 오늘 하루도 고생 많으셨습니다!
버전정보 (v1.1)
- v1.0 2020.07.28 배포
- v1.1 2020.07.28 장점에 새로운 항목 추가
* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.
* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.
* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.
* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.
* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.
그래서 빠르게! 오늘 할 수 있는 부분만 정리하고 일찍 잠 좀(...) 자려고 합니다! (그러는 지금 시간은 0시 4분...)
아마 오늘 한 부분은 졸면서, 또 일단 주먹구구식으로 한 부분도 있어서 추후 변경될 부분이 많이 있을 것 같습니다.
무엇보다 이것저것 요구사항이 늘어지다보니 타협이 잘 안되더라구요. (자신이 자신한테 많은 요구사항을 던지다니..)
그래도 개발을 진행하기 위해서는 미뤄지면 안된다는 생각에 후딱 정리해보았습니다.
Wireframe (장비관리-장비목록)
Wireframe (장비관리 - 장비목록)
이 프로젝트에서의 저의 역할은 아무래도 기획자인 동시에 설계자이고 개발자이기 때문에 요구사항을 제가 직접 밀어(?) 넣을 수 있습니다. 그렇다보니, 장비 목록을 오픈마켓들과 같은 느낌으로 이미지와 정보를 한 눈에 볼 수 있는 화면을 요구사항으로 생각하게 되었습니다. 그래서 설계시에도 많은 고려를 했구요.
지금 Wireframe만 보고는 조금 판단이 어려울 수 있으나, 아래 화면설계서를 보시면 어딘가 살짝 오픈마켓과 같은 느낌을 받을 수 있을 것 같습니다.
화면설계서 - PC (장비관리-장비목록)
화면설계서 - PC (장비관리-장비목록)
이제 설명 3번을 눈으로 보고 있다보면 오픈마켓의 화면과 비슷한 느낌을 받으실 수 있습니다.
이로써 장비를 관리하는 관리자 입장에서는 어떤 장비인지 이미지를 통해 확실하게 확인을 할 수 있지 않을까 싶습니다.
또 각 상태별로 이미지를 신호등 색으로 보여줌으로써 어떠한 상태인지도 확인이 가능하게 하도록 생각중입니다.
추가적인 부분이지만, 아마 detail한 규격이나 사용용도도 Tooltip 형식등을 통하여 확인을 할 수 있도록 하려고 생각중입니다.
다만, 현재 화면설계서와 앞으로 나올 디자인된 UI와의 갭이 생길 수 있어 이 부분은 추후 다시한번 고려해볼 생각입니다.
화면설계서 - Mobile (장비관리-장비목록)
화면설계서 - Mobile (장비관리-장비목록)
마지막으로 모바일버전의 장비목록입니다.
여기서는 상태가 안보이는 모습으로 보이는데, 모바일로 볼 수 있는 정보는 PC보다는 적게 만들어볼까 합니다.
(PC보다는 적은양의 정보 - 대신 중요한 정보는 더 부각되어 볼 수 있도록)
어차피 목록은 목록일뿐 더 detail한 정보가 보고 싶다면 큰 화면으로 볼 수 있는 PC나 상세정보페이지에서 봐야하는게 맞다고 생각하고 있습니다.
어쩌면 PC와 Mobile에 차이를 두고 정보의 양을 제한한다는 점은 조금 위험한 생각일 수 있으나, 보이는 화면의 크기가 다르고, 물리적인 제약이 따를 수 밖에 없는 만큼 고려하고 있는 부분입니다.
음.. 11시에 시작은 했는데 (집 도착해서 밥먹고 씻고 준비하면 대략 이런시간..ㅋ) 아마 12시는 넘어서(내일) 업로드 될 것 같네요.ㅠㅠ 아쉽..
Mobile에 대한 Wireframe은 많이들 하지만 WebSite는 하는걸 본적이 없다! 하시는 분들 있을 수 있어요.
그 이유 중 하나는 WebSite가 아무래도 조금은 개발하기가 쉽고, 변경이 빠르기 때문은 아닐까 싶습니다. (뭐.. 이건 생각에 따라 다를지도 모르겠네요.) 추가로 아마 포화상태인 시장도 있다고 생각은 합니다.
느낌은 Mobile은 한번 fix되면 그 이후는 변경이 어렵다고 생각을 한다면, WebSite의 경우 조금 고객과 소통을하며 변경이 많이 일어난다는 느낌입니다.
뭐.. 이건 각자 경험에 따라 다르겠지만, 보통 Mobile의 경우 한번 fix된 Wireframe을 토대로 UI를 그리고 개발을 시작하는 느낌입니다. (음.. 글쎄요.. 이 부분은 느끼는 분들에 따라 다르지 않을까 싶습니다만..)
뭐 추가로 말한것처럼 포화상태인 시장도 한 몫을 하긴 하죠. 워낙 WebSite를 템플릿을 미리 구축한 회사들이 빠르게 개발을 진행해주는 만큼 사용자는 Wireframe보다는 대화를 하며 fix를 시키는 방향으로 나아가는건 아닌가 싶습니다.
다만 이는 조금은 기획쪽에 카테고리가 더 들어간다는 생각은 합니다.
이유는 사용자가 원하는 유저 인터페이스(UI)의 기능을 기획자는 어떻게 담을것이고, 어떻게 자신의 내공을 축적시키는지에 따라 Wireframe만으로도 충분한 프로토를 전달할 수 있다는 점에서입니다.
여기서 어? 당신! 개발자 아냐? 왜 기획을 해! 라는 말씀 나올수도 있는데, 기획도 개발의 일부라 생각합니다. (저만의 생각일지도 모르겠지만..)
그래서 저는 기획을 위한 기획 관련 서적도 읽어보고, 설계를 위한 소프트웨어 공학, 그리고 좀 더 다방면으로 바라보기 위한 안목을 기르려 노력하고 있습니다. 어플 한가지를 보고 사용할때에도 여러면에서 이 디자인은 이런면에서 좀 아쉽고, 유저 인터페이스(UI)부분에서 이런 부분이 아쉬우며, 이런건 이렇게 바뀌었으면 좋겠다라는 재밌는 생각들을 하곤 합니다.
또 별 이상한 소리를 내기 시작했으니, 다시 한번 오늘의 주제대로 장비관리 Wireframe의 설계를 시작하겠습니다.
우선 Wireframe을 보기 전에 장비관리의 SiteMap을 한번 보도록 합시다.
한 화면에 다 담으려하다보니 아무래도 너무 복잡해질 것 같다는 생각에 결국에는 SiteMap을 설계하게 되었습니다.
SiteMap 설계하는 김에 그냥 URL도 같이 설계했습니다.
SiteMap
SiteMap과 URL 설계
위에 SiteMap을 보면 장비 등록과 목록을 나눴습니다. 나누게 된 이유를 우선 말씀드리자면, 한가지 경우를 상정했습니다. 바로 Mobile이죠. 저는 Ensemble의 모든 개발은 PC뿐이 아닌 Mobile도 대응이 되도록 설계를 하고 개발을 하려합니다. 때문에 Mobile에서 편리하게 바로 장비등록만 할 수 있도록 생각을 했습니다.
(뭐,.. 추후에 장비관리 application을 만들면 되지만, application이 지원되지 않는 예전 폰 혹은 태블릿이라던가에서는 웹사이트 접속을 통해 모바일의 지원을 할 예정입니다.)
특이사항으로 상태변경이 점선인 이유는 바로 Modal이기 때문입니다.
기본 장비 상세정보에서는 Log등의 정보도 보여줄 예정이지만, 상태변경시에는 Modal로 숨겨져 있던 창을 열어 컨트롤을 할 수 있도록 할 예정입니다.
(참고로 이 모든 기능은 계속해서 언급했다시피 application에서도 지원을 할 예정입니다.)
자, 이번엔 기다리시던 Wireframe의 시간입니다!
Wireframe - 메뉴구성
Wireframe - 메뉴구성
에구.. 메뉴구성 하나에 너무 몰두해버렸네요.
11시에 자리에 앉아 설계만 잡는다는게 게시글에 말 주저리쓰고 SiteMap 설계하고 Wireframe-메뉴구성 딸랑하나..
아무래도 시간이 시간인 만큼(현재 시각 오전 1시 44분)
2편을 준비해야겠습니다.
(내일 회사갈 준비도 있고, 개인적인 공부시간도 또 필요하다보니.. 잠은 보통 3시~4시 잡니다 ㅋㅋㅋㅋ 기상은 8시.ㅋ)
아무래도 저의 나쁜부분이네요 한개 설계할때 집중해서 파고드는게 ㅋㅋㅋ
얼른얼른 쳐내고 다음 부분으로 넘어가야하는데 마음에 들때까지 가지고 있다보니..ㅋㅋㅋㅋㅋ
다음 Wireframe_2에서는 오늘 못한 장비 등록, 장비 목록, 장비 상세, 상태 변경을 다뤄보겠습니다.
그리고 그 다음 컨텐츠는 아마 화면설계서가 될 것 같아요.
화면설계서는 아무래도 Wireframe과는 조금 다르다보니 어떤부분이 다른지를 나타낼 수 있을 것 같습니다.
(사실 자세한 설명이 들어가는거 빼고는 별 다른게 없어 보이는 게...)
버전정보 (v1.2)
- v1.0 2020.07.07 배포
- v1.1 2020.07.07 내용 수정 (오타)
- v1.2 2020.07.08 제목 수정 (Wireframe(1) -> Wireframe(0))
* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.
* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.
* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.
* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.
* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.
Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등
