UX기획자가 아닌데 UI를 설계하라고?
덜컥 ERP / BO 화면을 기획하게 된 모든 이들을 위한 가이드
UX기획자가 아닌데 화면을 기획하게 되었다면?
입사를 하면 가장 먼저 주어지는 것은 무엇일까? 그건 회사내에서 사용될 ID다.
회사내에서 ERP라고 부르든, Back Office라고 부르든 줄여서 BO라고 부르듯 어드민이라고 하든 뜻은 관계없다. 여튼 뭔가를 하려면 이제는 인트라넷에 연결된 무언가를 켜야하고, 회사일을 하려면 회사에서 주어준 ID로 로그인을 해야하고, 그리고 회사 사람들만 아는 화면을 사용해야 한다.
그런데, 어떤 회사에서는 분명 UX기획자가 아님에도 UI기획을 해야하는 경우가 있다. 아무리 대고객으로 오픈되는 것이 하나도 없는 비즈니스라고 해도, 필요한 화면이 신규로 필요할 때가 있기 때문이다. 사내에 운이 좋으면 UX기획자가 있어서 요청을 할테지만 운이 없다면, 혹은 UX기획자가 너무 바쁘다면, 또는 너무 전문적이라서 UX기획자에게 알려주기가 어려운 부분이라면. 어쨌거나 직접 그림을 그려서 요청해야만 하는 상황이 온다.
제조업 회계팀에서 근무하는 우리 남편도 같은 상황이다. 제조업의 '전산팀'으로 퉁쳐진 개발자분과 둘이서 끙끙대며 화면을 만들고 있단다.
"UI 그리는거 도와줄까?"
내 분야의 일을 남편이 하니 괜히 마음이 쓰였다. 나의 말에 남편이 도리질을 친다.
"이 화면은 나만 볼거라 나만 잘 알면돼. 그리고 모양보다는 계산 로직이 중요한 화면이라 괜찮아."
"흠, 그럼 여보 어제 야근하고 그러던데 무슨 문제가 있는거야?"
"아 내가 뭔가 내용을 보냈는데 전산팀분이 더 자세히 해오라고 해서 말이야."
사랑하는 내 남편이지만 내 속에서는 마음의 소리가 울리고 있었다.
'남편!! ERP화면 기획에도 룰이 있어 ㅠ_ ㅠ '
여보, '나만 보는 화면'이라고 생각마요.
회계, 재무, 법무 등 회사에는 굉장히 전문적인 직무부서들이 있다.
그런 팀에서 사용하는 화면은 요청이 굉장히 디테일한 편이다. 그리고 그런 팀하고 일할 때 가장 많이 듣는 말 중 하나가 바로 이 문장이다.
"어차피 저만 사용할 거니까, 저만 잘 알아보면 되요~~"
처음에 주니어때는 그냥 "그렇구나"하면서 고개를 끄덕이며 그냥 원하는대로 개발자에게 거의 바이패스 했었다. 그러다가 몇년이 지나고 나서 그때 그렇게 했던 것이 잘못임을 깨닫게 됐다.
어느날 다른 업무로 BO를 살펴보다보니 유사한 기능을 하는 비슷한 화면이 2개가 있었다. 화면 접속이력을 보니 예전에 만든 그 화면은 더이상 접속하지 않았고, 새로 만들어진 비슷한 화면만 쓰이고 있었다.
담당부서에 왜 화면이 2개인지 신규 화면은 왜 만들었는지 물어봤더니, 돌아온 대답은 황당했다.
"그런 화면이 있었어요? 저는 없는 줄 알고 새로 만들었는데요!"
알고보니, 처음에 어차피 저만 사용할 거라던 담당자가 퇴사하면서 아무런 인수인계도 제대로 이루어지지 않았던 것. 화면이 걸려있으니 보이기는 보이는데 본인만 알 수 있는 레이블명에 본인만 해석할 수 있는 로직으로 되어 있는 화면을 업무 인수인계자가 그 기능을 하는 것인지 이해하지 못했던 것이다.
UX기획의 관리밖에 벗어난 ERP화면들에는 그런 것들이 많다. 아예 몰라서 새로 만들거나 담당자가 바뀌면 무조건 개선해야되거나. 혹은 처음 담당자가 필요없다고 해서 아예 데이터 테이블조차 많들지 않았는데 나중 담당자는 왜 기본적인 것도 없냐며 말할 때도 있다.
화면이 인트라넷에 배포가 되는 순간 나 혼자만 보는 것이란 없다. 나는 영원히 그 회사를 다닐 것도 아니고 내가 계속 그 직무의 직급인 것도 아니고, 상황에 따라 봐야할 데이터도 바뀔 수 있다.
본인이 기획했어도 개발되서 나온 순간 화면은 공공재가 된다. 그게 바로 사내 소프트웨어의 속성이다.
여보 개발자는 독심술사가 아니에요
얼마전 만난 기획자가 그런 소리를 했다. 기획자 직무가 딱히 없어서 개발자에게 아예 정책문서를 던져준 사람이 있다고 한다. 개발자분은 아마 어이가 없었겠지ㅜㅜ
개발자와 대화를 하는 것은 생각보다 어렵다. 원활한 기획의도 전달을 위해서는 요건을 세분화해서 전달해줄 필요가 있다.
현업 업무자에게 상식인 것도 개발자에게는 아닐 수 있다. 애초에 개발할 화면을 완벽히 이해시키는 것은 서로가 노력해야할 부분이지만 다수의 운영개발건을 진행중일 가능성이 높은 개발자에게 자신만큼의 이해도를 요구해서는 안된다.
디스크립션에 대해서는 이전에 썼던 글을 참고하길!
http://brunch.co.kr/@windydog/73
이런 상황에서 백오피스 화면 기획하는 것에 적합한 팁을 떠올려보자
남편처럼 숫자를 다루는 팀이라고 가정했다.
모든 기능버튼은 업무순서에 맞게 좌에서 우로, 위에서 아래로 배치한다. 갑자기 앞으로갔다 뒤로 갔다하게 버튼 배치 하지말아요ㅜㅜ
그리드상에 데이터 표기 기준에 정책은 가능하면 화면내에 안내영역을 넣어주자. 특히 회사별 기준의 계산방식 등은 나중 담당자가 맞는지 의심하게되니 명확하게 표현해두는 것이 좋다.
만약 그리드상에 금액을 백분율화한 수치를 보여준다면 소수점 몇째짜리에서 올림/버림/반올림할지 정해줘야한다.
그리드에 항목 레이블은 가급적 ERP의 다른 메뉴들을 참고해서 통일한다. 개발자도 편하고 다른 이용자도 편해질 수 있는 길이다.
확장 가능성이 있는 요건이면 현재 필요하지 않더라도 일단 최대치의 요구사항을 생각해내고 실제 개발여부를 통해 협의하자. 최고 사양의 모습을 생각해낸다면 개발자는 애초에 서비스의 확장가능성을 고려한 설계를 할 수 있다. 이건 나중을 위해 중요한 부분이다.
기능 사용시 마지막 제어자의 히스토리가 남도록 꼭 작성자나 수정자의 ID가 화면에 보이도록 기획하자. 업무용화면은 뭔가 문제사항이 발생했을 때 역추적이 가능해야 운영시 용이하다.
계산 데이터의 변경가능성을 고려하자. 정산화면의 경우 여러가지 이유로 현재 조회시점마다 데이터가 바뀔 수 있다. 만약 마감처리 후에는 데이터가 변경되지 않기를 원한다면 미리 이야기해야한다. 개발자가 마감처리 후 데이터를 별도 저장하여 언제든 마감건 조회시 동일한 데이터가 조회되도록 처리해줄 것이다.
합계 그리드가 있다면 실제 데이터의 합인지 이미 자리수정리가 된 수의 합인지를 정해줘야하고 그리드 리스트가 길어서 페이징처리가 된다면 보이는 부분까지의 합인지 아니면 전체 데이터의 합인지 꼭 개발자에게 알려주자. 나중에 정산시즌에 실제와 달라 고생하지 않으려면 상식적이겠지 생각지말고 완벽하게 확인해두는게 좋다.
그러나 여튼 이 말은 내안으로만 삭여본다. 남편의 사회적인 몫에 와이프가 잔소리하는 건 별로 우리 관계에는 도움이 안되는 것 같으니까.ㅜㅜ
혹시 UX기획자가 아닌데 갑자기 업무용화면을 기획하게 되었다면 꼭 기억해주셨으면 좋겠다.
사실 대고객 서비스가 아니라도 내부 화면을 기획하는 것은 비지니스 프로세스를 설계하고 병목현상을 줄여주는 굉장히 중요한 UX적으로 관리해야할 영역이다. 꼭 고객만이 아니라 내부사용자도 분명 USER니까.
지금 진짜 직무는 아니라도 잠시나마 UX적 사고를 해보는 것은 어떨까?
