반응형
모바일 서비스를 위한 앱 개발 과정
네이티브 앱
- 하나의 운영체제에서만 동작.
- 모든 운영체제에서 동작하게 하려면 각 운영체제에 맞는 언어로 각각 개발해야만 함.
- 그래서 모든 사용자를 고려하면 개발 리소스 2배 이상 늘어남
- 사용자가 직접 다운로드해야 하기 때문에 실시간 업데이트가 쉽지 않음.
- + 각 운영체제에서 제공하는 강력한 기능을 활용 가능
- + 높은 사양의 그래픽을 구현할 수 있고 빠른 속도!
- 초기 스마트폰 시장 때도, 지금도, 가장 대중적인 모바일 개발 형식.
- + 사용자 기기에 저장된 사진, 카메라, 캘린더, 주소록에 접근 권한을 가질 수 있다 (가장 큰 장점)
- ⬆️ 이러한 특징으로 고성능 게임이나 카메라, GPS 등 센서를 활용한 앱 제작에 많이 활용
모바일 웹앱
- 사파리나 크롬 같은 인터넷 브라우저에 실행되는 웹사이트.
- 유저가 스토어에서 앱을 다운로드 하지 않아도 브라우저에 접속하면 연결되기 때문에 실시간으로 업데이트 가능
- 애플의 앱스토어나 구글의 플레이 스토어 같은 플랫폼을 거치지 않기 때문에 유지 보수에 유리
- HTML5 같은 표준 웹 언어로 만들어 개발 기간도 네이티브 앱에 비해 빠른 편
HTML5 (Hyper Text Markup Language)
웹 표준 기관인 W3C가 만든 웹 언어 규격. 웹 문서 작성에 반드시 필요한 마크업 언어.
- (-) 웹앱은 웹 기반 → 모바일 기기에 최적화되어 있지 않기 때문에 네이티브 앱에 비해 속도 SLOW 성능도 떨어짐.
요즘은 비용이 드는 네이티브 앱 개발을 웹앱으로 유저 확보 후에 하는 서비스가 많음. 접근성이 (스토어에서 새로운 앱 설치 보다는) 검색으로 접속하는 것이 접근성이 더 높기 때문.
하이브리드 앱
- 네이티브 앱과 웹앱의 장점을 모두 가짐.
- 겉은 네이티브 앱, 실제는 웹 기반.
- 콘텐츠는 HTML 방식으로 제작.
- 최종 앱 배포에 필요한 *패키징 처리는 안드로이드, iOS에서 개발.
- 앱스토어나 구글 플레이 스토어 같은 플랫폼에서만 다운로드 가능
- 앱 안에서 웹페이지를 불러오는 방식 → 한 번 설치하면 네이티브 앱의 번거로운 업데이트 문제 해결.
- (-) 사용자의 네트워크 환경에 따라 속도가 일정하지 않음
- 하나의 앱으로 다양한 웹 환경에 대응할 수 있어서 '대형 쇼핑몰'이나 '포털 사이트'가 하이브리드 앱을 선호.
*패키징 : 최종 앱 배포를 위해 기능별로 실행 파일을 묶어 만든 설치 파일. 예를 들어 안드로이드 패키지 파일의 확장자는 .aab, .apk다.
와이어프레임 & 프로토타입 이해
웹/앱 서비스의 기능과 디자인을 검증하고 개선하기 위한 단계.
실무에서 혼동하지만 와이어프레임과 프로토타입은 정확히 구별해야함.
와이어프레임
와이어프레임 : '선wire로 틀frame을 잡는다.'는 뜻.
건축 설계 도면 처럼 이미지만으로 웹/앱의 구조와 용도를 파악하는 것이 목표
- 기능과 구조 등을 '대략적으로' 이해할 수 있으면' 된다.
- 화면 간 흐름을 쉽게 파악할 수 있도록 각 페이지를 따로 설계하는 것이 원칙 (한 장에 모든 내용이 있으면 이해하기 어려움)
- 와이어프레임은 협업을 위한 공유 문서의 일종 → 누가 봐도 이해할 수 있어야 함
- 내용, 구조, 흐름, 기능 included
- 실무에서는 손그림이나 PPT를 이용한 가벼운 형식 선호 (와이어프레임 제작에 들이는 비용과 시간을 최소화 하기 때문)
- 서비스 출시 전에도, 기존 서비스 보완 시에도 유용
프로토타입
- 와이어프레임 → 설계도면 , 프로토타입 → 실제와 비슷하게 입체적으로 구현한 모형
- 구현 단계에 따라 피델리티 레벨을 나눌 수 있음. (Fidelity : 성실도, 충실도) 얼마나 충실하게 구현했나.
- 구현 수준에 따라 Low fidelity, High fidelity로 구분됨.
- 로우 피델리티는 간단한 인터렉션을 테스트 할 수 있는 정도 화려한 모션이나 세세한 기능 보다는 페이지와 페이지의 상관관계, 이를 통해 페이지 간 어색한 흐름을 잡아내는 것이 목표
- 하이 피델리티는 실제 출시할 서비스와 거의 유사할 정도로 대부분 기능을 구현한 수준.
- 하이 피델리티 프로토타입 제작 이유 : 개발 비용 낮추고 높은 수준의 피드백을 얻기 위함. 이 때 부터는 제대로 된 사용성 평가를 할 수 있음. 참여자가 프로토 타입으로 주어진 과제를 수행하는 과정을 지켜보는 형태로 평가가 진행됨. 제작자는 참여하는 사람이 의도와는 다르게 제품을 이용하는 모습을 보며 객관성을 확보함. 사용할 때 느끼는 어려움, 답답한 부분들을 관찰함. 이 단계에서 문제 발생 시ㅣ, 빠르게 프로토타입만 수정해 다시 테스트 가능. 그러나 복잡한 하이 피델러티 프로토타입 수정은 개발보다 비용이 더 많이 발생할 수 있기에 팀의 상황, 자원 파악 뒤 진행해야 함.
프로토타입 제작 툴
프로토타입 툴 없었을 대는 UI 디자인에 안맞는 포토샵 등의 프로그램을 써야 했다. 리사이징에 제한이 있는 비트맵 기반의 포토샵...ㅠㅠ 하지만 벡터 기반의 툴(스케치, 피그마 등)들이 나타나서 1 배율로 작업할 수 있게 됨.
효과적인 유저 스토리 작성법
- 와이어 프레임 제작이 끝나고, 이를 개발자에게 효과적으로 전달할 방법 → '유저 스토리' 설명 방식
- 유저 스토리란 개발에서 '요구 사항'이라고 부르는 시스템의 기능 설명을 '사용자 관점에서 이야기하는 것'
- 서비스의 다양한 Tasks → 각각 유저 스토리로 작성하면 개발자와 완성도 높은 커뮤니케이션을 할 수 있음.
유저스토리 틀
[사용자는] [태스크]를 수행할 수 있다.
지금부터 인스타그램 하이라이트에 사진을 추가하는 예시를 통해 유저 스토리 작성법을 자세히 알아보자.
<인스타그램 하이라이트 업로드 과정>
1. 인스타 앱 열기
2. 하단 탭의 프로필 사진을 눌러 프로필로 이동
3. 프로필 바이오 아래 '새로 만들기'를 선택
4. 게시해 둔 스토리 중에서 하나 선택
5. 표지 추가하고, 하이라이트 이름 쓰기
6. '만들기' 클릭
이 과정을 유저 스토리의 기본 틀로 만들면 다음과 같다.
[사용자]는 [인스타 하이라이트에 사진 업로드]를 수행할 수 있다.
As a (사용자), I want to ( ), So that ( ).
사용자는, 인스타그램에 하이라이트를 업로드 하고 싶다, 그렇게 해서 일상을 기록하고 싶다.
[인수 조건]을 유저 스토리에 추가하면 디자이너가 원하는 기능을 더 확실하게 전달 할 수 있음
Acceptance Criteria (인수 조건)
Where [인스타 프로필 페이지에 진입한 상태에서]
When [ 프로필 하단 "+" 버튼을 확인 후 클릭하면]
Then [사진 선택 후 하이라이트를 추가할 수 있다]
or [사진을 복수 선택하고 싶을 때]
And [하이라이트에 있는 기존 사진에서 1개 이상 선택할 수 있다.]
반응형
'디자인 > UX UI' 카테고리의 다른 글
[UX/UI 스터디] 더블 다이아몬드 (디자인씽킹을 지탱하는 다이어그램) (0) | 2024.05.20 |
---|---|
[피그마 오토레이아웃] 개념 & 원리 / 오토레이아웃 리사이징 (컨텐츠과 컨테이너는 상대적인 관계) (0) | 2024.05.16 |
UX/UI 책 스터디 <사용자를 사로잡는 UX/UI 실전가이드> -4 픽셀 밀도와 선명도의 상관관계 (0) | 2024.05.13 |
웹/앱 클론 디자인 (0) | 2024.05.08 |
[피그마 플러그인 추천] Flow chart 유저플로우, 플로우차트 쉽게 만드는 플러그인 (0) | 2024.05.07 |