지극히 개인적인 기획자의 체크리스트 (4~5)

 

---

업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다.

그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다.

 

아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다.

작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다.

 

---

 

4. Backoffice (Admin) 사이트 구성 시, CRUD 를 지켜라

Backoffice 와 같이 관리자 웹 사이트나 서비스의 경우 Database를 기준으로 화면을 구성하게 된다. 
이 경우, 비지니스 로직보다는 단순 조회, 수정, 삭제 기능이 메인이다.

기본 기능은 CRUD

• C (create) : 신규 생성 (new)
• R (read) : 조회 (search)
• U (update) : 수정 (modify, update)
• D (delete) : 삭제

기본(사이트) 구조는

Menu
> Sub Menu
>> List
>>> Detail View
>>>> ADD / Modify / Delete

메뉴에 접근하면 데이터 리스트가 노출되고,
리스트를 선택하면 상세 내용이 노출되고,
데이터를 수정하거나 삭제할 수 있는 액션이 주어짐.
데이터 추가는 리스트나 상세 뷰에서도 가능하다.

List, 

즉 그리드 or 테이블은 관리자 페이지 UX의 핵심이다.
어떤 데이터를 표시할 것인가, 순서와 정렬, 검색 조건을 고민해야 한다.
조회된 데이터는 사용자에게 유용한 정보를 즉각적으로 줄 수 있어야 한다.
조회된 데이터에서 다음 액션이 필요한 경우 UI를 통해 명시해서 다음 행동을 유도하는 것도 좋다.

 

검색창은 통일성을 유지하는 것이 좋다. 
매번 바뀌는 검색창 UI는 사용자로 하여금 리소스 소모를 발생시키고 실수를 야기시킬 수 있다.
중요하고 자주 쓰는 검색 조건은 Shortcut 또는 검색조건 저장을 통해 생산성을 향상해라

 

---

 

5. Backoffice (Admin) 구성 고민.

 

관리자 페이지는 용도에 따라 서비스 분리도 고려해볼 만하다.

보통 3개의 서비스로 구분이 보편적이라 생각한다.

(하나의 사이트에서 권한 분리도 좋은 방법이기는 하나 보안 취약점이 노출될 수 있기에 도메인 분리가 좋다.)

• 서비스, 시스템 설정 사이트 : 서비스나 시스템 관련된 설정 정보를 다루는 민감한 부분 별도 도메인 분리, 개발/운영
• 파트너, 유저 관리 : 판매를 위한 CRM 사이트 분리, 영업
• 통계, 분석 : 사용 패턴 분석 및 데이터를 활용하는 사이트 분리 (DB 분리를 통한 실서버 영향 주지 않기 등), 마케터

 

대시 보드 구성 

이 부분은 좋은 기사가 있어서 그대로 옮겨 왔다.

• 전략형 대시보드(strategic company dashboard)
• 작업형 대시보드(operational dashboard)
• 분석형 대시보드(analytical dashboard)

https://www.bloter.net/archives/311848

효과적인 대시보드를 만들기 위해 고려해야 할 6가지

#1. 대시보드의 잠재 사용자 이해하기 
#2. 대시보드 목적과 활용 방식 결정하기 
  - 임원 등 조직의 주요 의사결정자가 전체 데이터를 보는 전략형 대시보드(strategic company dashboard) 
  - 비상상황이나 이상치를 빠르게 인지하고 반응하도록 하는 작업형 대시보드(operational dashboard) 
  - 트렌드를 이해하고 분석하는 분석형 대시보드(analytical dashboard) 
  - 실시간성과 탐색(Depth) 
#3. 정보 영역 구성하기 
#4. 정보 표현 방식 결정하기 
  - 1. 이 정보 영역에 차트를 사용할 것인가? 
2. 차트를 쓰기로 했다면 어떤 차트를 쓸 것인가? 
3. 차트 간의 이동이 있어야 한다면 어떤 인터랙션이 적합할까? 
#5. 시각적인 가독성·이해력 높이기 
#6. 결국 계속 만들고 테스트하고 고치기

 

 

---

 

 

 

필자가 본 대부분의 관리자 페이지는 제한된 사용자가 이용한다는 이유로

UX 측면을 고려하지 않는 경우가 많았다.

 

하지만 관리자 페이지에서 실수를 하게 될 경우 서비스 장애나 오류로 이어질 확률이 높다.

1 % 의 리스크라도 있다면 반드시 신경 써야 할 서비스 분야임에 틀림없다.

 

아래 두 항목은 직접 눈으로 본 내용이고 관리자 사이트에서 실수하나

기획자가 실서비스와 개발서비스를 구분 못해서 발생한 경우일 것이다.

 

첫 번째, 국내 2대 잡포털 사이트(잡***, 사**)의 구직 이력서에 해당 업체의 기획자가 테스트로 올린 이력서가 "기획" 으로 검색하여 노출된 적이 있었다. 나는 그 이력서를 평생 교보재로 사용하기 위해 캡처본을 저장해 두었다.

 

두 번째, 제 1금융권의(하***) 푸시 메시지 전송 실수이다. FCM 이나 자체 메시지 서버를 이용한다 하여도 대상을 테스트와 실서비스를 구분 못하고 발송되는 메시지는 관리자 페이지에서 실수를 유발할 수 있도록 구성되어 있기 때문이다.

 

Backoffice 는 반드시 Front Servie 기획 시 함께 고려할 수 있도록 하자.

 

 

 

 

지극히 개인적인 기획자의 체크리스트 (1~3, 6~8)

 

---