정신없이 기획서에 있는 기능들을 개발하다보면 정작 어플리케이션을 사용하는 유저를 까먹는 경우가 많은 것 같습니다. 다른 웹사이트, 앱에서 그렇게 하니까 의례적으로 기능을 추가한다든지, 아는 선상에

정신없이 기획서에 있는 기능들을 개발하다보면 정작 어플리케이션을 사용하는 유저를 까먹는 경우가 많은 것 같습니다. 다른 웹사이트, 앱에서 그렇게 하니까 의례적으로 기능을 추가한다든지, 아는 선상에서 예외케이스를 대비한다든지요. 사용자가 어떤 맥락에서 혹은 어떤 목적을 가지고 이 기능을 사용하는지를 모르면 만들어 놓은 기능을 사용자가 안 쓰는 일이 생기거나 케이스별 대응과 예외처리가 부실해질 겁니다. 해당 글은 프로덕트 디자인 가이드북이지만 프론트엔드 개발자에게도 필요한 지식이라 생각이 듭니다. ------- ▪️ 패턴이란 ? - 사용자가 디바이스(구체적으로 어플리케이션)과 상호작용하여 목적을 달성하는 일반적인 과정 ▪️ 패턴의 속성 1. 맥락(context) 사용자가 처한 상황과 원하는 바를 육하원칙에 따라 한 문장으로 정리 [ 예시 ] 사용자가(Who) 레시피를 찾기 위해(Why) 첫 화면에서(Where) 레시피를(What) 키워드로 찾기(How) 2. 흐름(flow) 맥락을 바탕으로 목표를 달성하기 위한 사용자의 상호작용 흐름 설계 [예시] 키워드 입력 > 검색 결과 > 레시피 선택 3. 형태(shape) 사용자가 구체적으로 사용할 화면 설계, 단계별 목적을 달성하기 위한 시각 요소 설계 [예시] - 입력 단계의 목적 = 레시피를 키워드로 입력하기 - 입력 단계의 목적 달성을 위한 형태 : 키워드 입력 키보드,키워드 확인창, 키워드 자동완성창 3 - 1. 케이스(Case) 화면을 구성하는 요소의 변수 정의와 변수에 따른 화면 설계 [예시] 입력 단계의 변수 - 첫 글자 입력 - 입력 중 - 입력 완료 - 입력 오류 3-2. 로직(Logic) 단독 변수의 정의(케이스)보다 더 큰 단계로 서로 영향을 주는 변수들에 대한 알고리즘 설계 [예시] 키워드 입력 => 일치하는 결과가 있는가? => 아니오: 추천키워드 출력 => 예: 결과리스트 출력