피그마의 핵심 ‘오토레이아웃’

• 개체를 패딩으로 감싸 컨테이너(여백)로 만들 때 쓰는 ‘오토레이아웃'
• 오토레이아웃에서는 일반적인 레이어의 앞 뒤 순서가 반대다.
• 하나의 컨테이너 (모든 코드 블록) = 개체의 크기 + 패딩(내부여백 값).
• 이 컨테이너를 쌓기 위해 필요한 오토레이아웃!

잊지말아요 :
(콘텐츠를 패딩으로 감싸 컨테이너를 만들어 주는 오토레이아웃)

‘컨스트레인트 Contraint’

하지만 반응형 웹사이트 처럼 실시간으로 같이 움직이는 레이아웃을 만들기 위해서는 오토레이아웃의 ‘규칙’을 만들어 줘야한다.

★ 부모 컨테이너의 크기가 변할 때, 자식 컨테이너는 어디를 기준으로 변할지 정할 수 있다.

★ 리사이징의 개념 ★ 

• 프레임은 기본적으로 크기가 고정. Fixed.
• 오토레이아웃으로 프레임을 감싸는 그 순간! Fixed외 다른 사이즈값이 생긴다 → 리사이징  ✅
• 부모의 사이즈 값에 따라 자식의 사이즈 값이 영향을 받는다.
• 자식의 사이즈 값에 따라 부모의 사이즈 값도 영향을 받는다.

• 자식이 Fixed면 부모가 Hug 감쌀 수 있다.
• 자식이 부모에 맞게 늘어나야한다면, 부모가 고정값Fixed으로 설정되어 있어야 한다.
• 부모가 고정되어 fixed 되어 있지 않으면 자식이 Fill로 되어 있을 때 계속 쫒아다닌다.
• 반대로 부모가 자식을 Hug 감싸기로 했다면 자식은 Fixed 고정됭 있어야 한다.
• 부모와 자식이 둘 다 fixed 일수도 있다. 

실제 만드는 웹사이트나 앱에는 수많은 컨테이너들이 있다. 그렇기 때문에 리사이징에 꼼꼼하게 신경을 쓰지 않으면 복잡한 움직임이 있을 때 내가 의도하지 않았던 레이아웃이 생길 수 있다.
→ 여러개의 컨테이너가 쌓였을 때는 리사이징을 반드시 잘 조정해야한다.

경쟁사 분석이 필요한 이유는 시장의 '진짜' 경쟁사를 분류하기 위함이다.
이 과정을 통해 우리 서비스의 강점과 약점을 파악하고 나아갈 방향을 모색할 수 있다.

경쟁사 분석이 필요한 이유

BY 스티븐 더글라스 Steven Douglas (Shopify 콘텐츠 디자이너)

• 시장에서 통용되는 사용성(멘탈 모델)을 발견하기 위해 ▶️ 이런 기능 개발의 우선순위를 높여야 한다.
• 우리 서비스의 사용성을 개선하기 위해
• 목표를 발견하고 집중하기 위해
• 서비스가 시장 어디쯤에 있는지 파악하기 위해
• 경쟁사의 강점과 약점을 알기 위해
• 우리 제품의 장단점을 파악하기 위해
• 제품의 기능 변경 시 신뢰할 수 있는 근거를 확보하기 위해

즉, 경쟁사 분석의 핵심은 우리 서비스를 객관적으로 바라보기 위함이다.

경쟁사에는 직접 경쟁사(우리 서비스와 동일한 제품 또는 서비스를 제공하고 가격대도 유사)와 간접 경쟁사(수익 창출 방법은 다르나 잠재적 경쟁사가 될 수 있는 서비스들)가 있다. 이 중 '진짜' 경쟁사를 발견하려면 분석하기 전 '경쟁사 분석 표'를 작성한다.

경쟁사 리스트 목록

• (직접/간접) 경쟁사 이름
• 앱스토어 주소 (접속 링크) or 접속 ID
• 앱의 목적
• 생성일

기능 비교 표 만들기 

경쟁사들이 보유한 기능들을 한눈에 파악할 수 있게 만들면 우리 서비스에 구현해야 할 기능을 한눈에 볼 수 있고 사용자가 원하는 기능도 파악할 수 있다. 그렇다고 경쟁사의 모든 기능을 구현할 필요는 없다. 꼭 필요한 것만. 가진 자원을 고려해 어떤 기능을 먼저 구현하는게 가장 효율적일지 고민해야 함.

+ 우리 제품 서비스가 시장 어디쯤 있는지, 무엇을 더하거나 덜어야 할지 등을 파악하기 위한 여러 프레임워크

1. SWOT 분석

가장 대중적인 경쟁사 분석 프레임워크. Strength, Weakness, Opportunity, Threat (강점, 약점, 기회, 위협). 경쟁사 분석뿐 아니라 경경 전략을 수립하는 데도 자주 사용한다.  4분면으로 나눠 각 면에 내용을 기록하는 것이 일반적.

장단점 : 제품 설계시 영향을 미치는 내부(강약점)와 외부(기회와 위협)를 평가하는 적합하지만 4가지 범주로만 제한하는 것은 가설을 지나치게 단순화할 수 있으니 너무 맹신하지 않기.

2. BCG 매트릭스 (Growth-Share Matrix)

컨설팅 그룹에서 만든 사업 포트폴리오를 분석하는 기법. 세로축은 시장 성장률, 가로축은 시장 점유율.

각 분면을 별, 캐시카우, 개, 물음표 기호로 분류.

별 : 시장 성장률, 시장 점유율이 모두 높은 사업. 기업을 대표하는 핵심 사업일 가능성이 높다.
캐시카우 : 수익성 ⬆️ 높지만 성장률은 ⬇️. 별이었던 사업의 시장 성장률이 떨어지면 캐시카우가 되기도 함.
개 : 시장 성장률, 점유율 모두 ⬇️ 낮은 사업. 장래성이 없어 시장에서 철수될 가능성이 높다.
물음표 : 시장 성장률 ⬆️ 높지만 시장 점유율이 ⬇️ 낮은 사업. 경영 방향에 따라 별 또는 개가 됨. 점유율을 높이지 못하면 현금 유출로 조직 내 큰 손실이 발생할 수 있다.

다양한 계열사가 있는 대기업에 맞는 프레임워크 같지만 다양한 기능이 있는 앱에 적용해 볼 수 있다. 예를 들어 금융 앱이라면 송금, 주식, 가계부 같은 기능 하나하나가 사업 포트폴리오가 될 수 있다.

3. 지각 매핑 Perceptual Mapping

경쟁사 사이에서 우리 제품 또는 서비스의 위치를 시각화해 사용자들이 특정 축에서 떠올리는 다양한 브랜드의 맵을 그리는 것. 주요 쟁점을 바탕으로 2가지 축을 설정해 지각 매핑을 그려 본다면 시장에서 우리 제품 또는 서비스의 위치를 가늠할 수 있다.

이 기법들은 오랜 시간 시장에서 검증되었고 객관적으로 사고하는 데 도움을 주지만 '시장은 역동적이고 예측하기가 어렵다.' 그렇기 때문에 이 분석 기번들이 이런 시장 역동성을 단순화할 수도 있으니 활용은 하되 맹신하지 않고 객관적으로 보는 것이 중요.

MVP (Minimum Viable Product) ↔️ Double Diamond 더블 다이아몬드
최소 기능 제품. 스타트업 뿐만 아니라 대기업에서도 서비스를 만들다 보면 인력, 자금, 시간에 자유롭지 않은데, 이런 환경에서 아이디어를 구체화 할 때 처음 부터 모든 자원을 투자해 제품  또는 서비스를 완벽하게 구현하는 것은 불가능에 가까움. 때문에 최소한의 가용 자원으로 최소 기능 제품을 시장에 보임으로써 이 제품에 앞으로 더 많은 자원을 투자할 가치가 있는지를 파악하는 것이 핵심이다.

MVP 포인트 : 시장에서 받는 '피드백'을 통해 점진적으로 제품을 개선

MVP 아이디어가 대중의 문제에서 시작되었다면, 실제로 그 문제를 해결하는 데 도움이 되는지 확인하는 과정이 필요하다. 이 과정은 제작, 측정, 학습의 3단계로 이루어진다. 이 단계를 계속해서 반복하는 것을 '피드백 루프'라고 한다.

"사람들이 원하는 무언가를 만드는  것, 그것이 가장 기본입니다.
시장에서 버려진다면, 아마도 그건 사람들의 욕구를 충족하지 못했기 때문입니다." - 폴 그레이엄 (투자자)

먼저 제작 단계에서 가설을 세우고, 검증하고자 하는 기능을 만든다. 다음으로 측정 단계에서 그 가설이 얼마나 잘 맞는지 확인한다. 그런 다음, 다양한 경로로 받은 피드백을 통해 학습하고, 이를 바탕으로 더 나은 가설을 세워 다시 제작 단계로 돌아간다. 피드백 루프는 시장에서 의미 있는 피드백을 얻고 반영하는 과정이며, 이를 반복하면 제품이나 서비스는 성장하게 된다. 


1. 제작
MVP 피드백 루프의 첫 단계입니다. 서비스를 제작하기 전에는 시장에서의 피드백이 없기 때문에 외부 사례나 검증된 프레임워크를 통해 가설을 세우고 서비스를 제작합니다. 첫 제작이라도 검증하고자 하는 핵심 기능의 완성도는 중요하게 신경 써야 합니다. 최소 기능 제품은 가능성을 파악하는 단계이므로, 초기 가설이 모두 맞을 것이라고 기대하는 것은 좋지 않습니다. 제작 단계가 진정으로 힘을 발휘하는 시기는 피드백 루프가 반복된 이후입니다.

2. 측정
피드백 루프의 두 번째 단계인 측정 단계에서는, 제작한 서비스나 제품의 성과를 평가하고 초기 가설이 얼마나 잘 맞았는지 확인합니다. 이를 위해 다양한 데이터를 수집하고 분석합니다. 사용자 행동, 사용 빈도, 만족도 등을 측정하여 어떤 기능이 효과적이었는지, 어떤 부분이 개선이 필요한지를 파악합니다. 이 단계는 다음 단계인 학습과 개선을 위한 중요한 정보를 제공하며, 반복적인 피드백 루프 과정에서 제품이나 서비스를 점점 더 나아지게 만드는 핵심 요소입니다.

정량적 데이터:
수치로 표현되는 데이터로, 사용자 수, 클릭 수, 사용 시간 등과 같이 측정 가능하고 통계적으로 분석할 수 있는 정보입니다

정성적 데이터:
사용자 인터뷰, 설문 조사, 피드백 등의 형태로 수집되는 데이터로, 사용자 경험, 감정, 의견 등과 같이 수치로 나타내기 어려운 주관적인 정보를 포함합니다.

구글 애널리틱스 (Google Analytics):
웹사이트 및 애플리케이션의 트래픽과 사용자 행동을 분석하는 도구입니다. 방문자 수, 페이지뷰, 세션 시간, 이탈률 등 다양한 정량적 데이터를 제공하며, 사용자 유입 경로와 행동 패턴을 파악할 수 있습니다. 이를 통해 웹사이트의 성과를 평가하고 최적화할 수 있습니다.

앰플리튜드 (Amplitude): 사용자 행동을 심층적으로 분석하는 도구로, 사용자 여정, 행동 흐름, 유지율 등을 추적할 수 있습니다. 이벤트 기반으로 데이터를 수집하고 분석하며, 특정 행동에 따른 사용자 그룹을 세분화하여 분석할 수 있습니다. 이를 통해 제품 사용 패턴을 이해하고, 사용자 경험을 개선하는 데 도움을 줍니다.

3. 학습
피드백 루프의 세 번째 단계인 학습 단계에서는, 측정 단계에서 수집한 데이터를 바탕으로 제품이나 서비스에 대한 인사이트를 도출합니다. 정량적 데이터와 정성적 데이터를 분석하여 어떤 가설이 맞았고 어떤 부분이 틀렸는지 확인합니다. 이를 통해 사용자의 필요와 문제점을 더욱 깊이 이해하고, 개선할 점을 도출합니다. 학습 단계에서 얻은 지식은 다음 제작 단계에서 더 나은 가설을 세우고, 제품을 개선하는 데 활용됩니다. 이 반복 과정을 통해 제품이나 서비스는 지속적으로 발전하게 됩니다. (이 단계에서 경쟁 서비스에 대한 깊은 이해도 하게 됨).

어떤 서비스도 완벽한 상태로 유지되기는 어렵다. 시장은 항상 변화하고 소비자의 욕구도 계속 변하기 때문. 그러나 피드백 루프를 계속해서 반복하다 보면 서비스가 시장에서 자리를 잡는 순간이 온다. 이를 '프로덕트-마켓 핏을 찾았다'고 표현합니다. 피드백 루프는 서비스를 시장에 맞게 발전시키는 과정이므로 한 번에 완벽한 프로덕트-마켓 핏을 찾는 것은 거의 불가능. 시장에서 자리를 잡을 수 있는 모습은 처음부터 명확하게 보이지 않으며, 피드백 루프를 계속 거치면서 조금씩 모습이 드러날 것.

피드백 루프를 효과적으로 활용하기 위해 가치 대 노력과 긴급도 대 중요도 우선순위 프레임워크를 활용할 수 있습니다.

1. 가치 대 노력 (Value vs Effort): 이 프레임워크는 특정 기능이나 개선 사항의 가치를 측정하고, 해당 가치를 달성하기 위해 필요한 노력을 고려합니다. 즉, 가치가 높으면서도 상대적으로 적은 노력이 필요한 항목이 우선적으로 처리되어야 합니다. 이를 통해 중요하면서도 비용 효율적인 작업을 우선적으로 진행할 수 있습니다.
2. 긴급도 대 중요도 (Urgency vs Importance): 이 프레임워크는 작업의 긴급성과 중요성을 고려하여 우선순위를 정합니다. 긴급하지만 중요하지 않은 작업에 시간을 낭비하지 않고, 중요하면서도 비교적 긴급하지 않은 작업에 먼저 집중하는 것이 중요합니다. 이를 통해 장기적인 목표를 달성하면서도 예상치 못한 긴급한 문제에 대처할 수 있습니다.

이러한 우선순위 프레임워크를 사용하면 피드백 루프에서 나오는 다양한 의견과 요구 사항을 효율적으로 관리하고, 제품이나 서비스의 발전을 지속적으로 이끌어 나갈 수 있습니다.

콜로소에서 무료특강 <아마존에서 프로덕트 디자이너로 일하는 법>을 들었다.
아마존에서 일하시는 UX/Product 디자이너 박세원 님께서 회사 문화를 알려주셔서 아주 재밌게 들었다.

Designing at Amazon 아마존 회사 문화

아마존은 모든 직원을 리더라고 호칭하고, 10계명 같은 원칙이 있다.
온보딩 하면 “여러분은 고객을 위한 리더들입니다.”라고 함.
좋은 리더가 되기 위한 이 원칙들은
보통 서로 반대되는 개념들이 짝지어져 있는데,
알잘딱깔센으로 융통성 있게 적용해야 하는 것 같다.

리더십의 원칙 Leadership Principle

1. Customer Obsession - 고객 중심적
   (프로덕트 디자인 할 때 유저중심 사고와 같다.) 
   
   
2. Ownership - 내가 이 회사의 주인이라 생각하라.
   (미국은 월급 + 회사주식도 줌), 회사 뿐만 아니라 담당 프로덕트의 ownership too.
   
3. Invent & Simplify - 새로운 이노베이션을 하더라도 심플하게 만들어 쉽게 쓸 수 있게 하라. Alignment를 받은 다음에 아이디어를 가지고 Invent & 단순화해서 approachable 하게 아웃라인 해주면 리더십이 훨씬 더 잘 이해할 수 있고, implementation이 가능한 디자인이 될 수 있다.
   
   
4. Are Right, A Lot - 리더들은 촉(판단력)이 좋다.
   많은 상황에서 시간이 부족한 상태에서 일을 하다보니 intuition으로 일을 해야 한다. 시간이 없으니 좋은 촉으로 결정해라. 아이디어 혹은 Perspective가 있는데 상반되는 의견들로 옳았다는 것을 증명해야 하고 옳아야 할 거야.. ↔ Dive Deep 촉 보다는 데이터! (아마존에서는 촉과 데이터를 다 쓰게 됨. 아마존은 특히 리서치할 시간이 없을 때 이미 존재하는 데이터와 리서치를 많이 해두어서 최대한 나의 판단과 촉을 키운 다음 빨리빨리 prove wrong, right를 잘하는 디자이너를 아주 좋게 봄)
   
5. Learn and Be Curious - 디자이너는 항상 성장해야 한다. 자기계발을 계속해야 함. 고객이 프로덕트를 어떻게 쓰는지 달라지기 때문에 고객에 대한 이해도 항상 새로워야 한다. Tactical 스킬에 따라서 새로운 툴도 항상 나오고 Industry도 계속 바뀐다. Generative AI를 통해 디자인필드도 크게 변화하고 있다. 계속 변하는 세상. 디자이너도 Industry standard 이상으로 잘하려면 배움에는 끝이 없다. 
   
   
6. Hire and Develop the Best - 디자이너에게 해당되기 어려움
   
   
7. Insist on the Highest Standards <-> Bias for action
   
   
8. Think Big - (무슨 디자인을 하더라도) 큰 그림을 봐라.
   보통 Think Big을 하고, Invent & Simplify 하는 순서가 바람직. 프로덕트 로드맵이 없는 상황에서 디자이너가 생각하는 입장에서 데이터와 유저리서치를 통해서 얻어낸 문제점을 가지고 만든 디자인.. 리더십이나 파트너팀 다른 디자이너에게 좋은 동기부여가 되고, 아이디어를 보여주기에 좋은 방식. 그러나 회사이다 보니 처음부터 Think Big으로 한 디자인을 출시하기는 어렵다. 그래서 이 큰 아이디어를 현실적으로 더 작게 쪼개서 디자인할 줄 아는 능력으로 디자이너가 잘하고 못하고를 알 수 있음.

아마존에서는 보통 펀딩을 받지 못하는 프로젝트 거나 리더십이 disagreement가 있을 때 (큰 그림을 보지 않고 그런 argument가 있을 수 있으니) 큰 그림을 보여주며 왜 이 디자인이 필요한지 설득하기 좋음.

9. Bias for Action - 빨리빨리 일하고 행동으로 보여라.
Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

10. Frugality - 디자이너에게 해당되기 어려움

11. **Earn Trust - 좋은 팀메이트가 돼라.
13번과 반대 (모두 찬성이고 나만 반대인 상황에서는 한 팀이니 찬성해 봐요~) 디자이너들과 엔지니어 사이에서 Earn Trust는 매우 중요. 이 유무 차이가 디자이너팀에서 엔지니어팀에게 프로포절 할 때 얼마나 나를 믿고 존중하냐에 따라서 똑같은 요청을 해도 결과가 다른 경우가 많다.

결국, Tactical에 있는 요소들을 잘해나가고 있으면 Earn Trust는 자연스럽게 생긴다. 전문성을 보여주면 틀렸을 때는 틀렸다고 얘기해 주고 with respect.

아마존 디자이너에게 주는 팁 :
최대한 상대방이 얘기하는 것을 존중하고, 의견을 acknowledge 하되, 자신의 의견과 줏대는 항상 있어야 한다. (제일 중요한 고객중심 마인드와 함께)**

12. Dive Deep - 결국 Data Driven 해야 한다.
리더들은 리서치도 꾸준히 하고, 내 프로덕트에 무슨 문제가 있는지 Audit도 주기적으로 하고, 나의 촉을 믿지 말고 나의 고객이 무슨 얘기를 하는지 data & metrics 혹은 리서치를 통해 디테일을 점검해야 한다.(리더들은 좋은 디자이너들은 자기의 촉만 믿지 않고, 리서치를 통해서 고객의 진짜 문제가 무엇인지 항상 궁금해하고, 리서치를 수행한다.) 

13. Have Backbone; Disagree and Commit - 줏대가 있어야 함.
언제든 disagree를 준비를 해라. 내가 좋은 팀메이트가 되기 위해서 불화를 일으키지 않기 위해 ‘동의’하면 아니 되오. 물론 with respect. 그리고 만약 disagree를 하더라도 제대로 commit 하기.

14. Deliver Results - 아웃풋이 있어야 한다. 열심히 하고 잘하더라도 결과는 있어야 함. 이 부분은 운도 따라야 함. 성과주의 미국회사의 원칙. 

15. Strive to be Earth’s Best Employer - 디자이너에게 해당되기 어려움

16. Success and Scale Bring Broad Responsibility - 디자이너에게 해당되기 어려움

제일 마음에 들고 이미 실천 중인 원칙은 
"Learn and Be Curious"
자기 계발을 즐겨하는 나지만 솔직히 요즘에는 AI와 함께 요동치며 변화하는 세상 속에 배울 것들이 너무나도 많아지니 기가 질리기도 한다. 그럼에도 꿋꿋하게 꾸준히 이 원칙을 지켜야겠다. 씨이익.

Discover - Empathy Building
문제를 풀 때 고객 중심으로 푼다.

이 단계에서 Assumption 가정 하기가 쉽다. 이 단계에서 Diverge라고 하는 이유는, 모든 것을 버리고, 내려놓고, 고객 데이터와 리서치에 흡수되어 고객의 진짜 문제를 찾아내자는 의미에서..

리서치 방법 : 상황에 따라, 어떤 솔루션을 찾느냐에 따라서 적합한 방법이 다름.
Quantitative vs Qualitative 양적 질적

• Ethnographic Study - 조사하는 사람이 유저의 환경에 들어가서 유저가 어떻게 행동하고, 우리의 제품을 이용하는지 직관하는 것. (Bias 되지 않고, Assume가정이 아닌 고객의 말에 의존할 필요도 없고, 제품을 실제로 이용하는 것을 보기 때문에 Discovery에 유용 & 많은 디자이너와 리서쳐들이 선호) 하지만 질적 리서치다 보니, 데이터적으로 봤을 때 많이 할 수 없음. (참여자 모집하는 등) 시간도 많이 들어서 (투자 많이해야함) 많아봐야 서너명의 유저들과 진행함. 회사입장에서도 제품을 빨리 출시해야하는 입장이니 오랜시간 여유있게 조사할 수 없음.
• 유저 인터뷰 User interview - 말 그대로 인터뷰, 제품을 쓰면서 느낀점들을 물어보면 자연스럽게 불편한 점들을 알아냄. (노골적으로 물어보기 보다는 Task based로 ‘이런 거는 어떻게 이용하나요?’ 이런식으로 질문하면서 조금씩 파고들어가는 방식으로. 
• Diary studies - Ethnographic study와 비슷, 일기장을 적어달라고 하는 것. 단점으로 시간이 많이 걸림.
• Focus Groups - 회사에서는 시간에 많이 쫒기다 보니 많아봐야 인터뷰를 7명 함. 그래서 한 세션에 한 명이 아닌 여러명에게 토론주제를 가지고 와서 대화나눠 보게 함. 주로 아이디에이션(새로운 생각)을 하려고 하거나 제품을 쓰면서 문제가 있을 때 서로 공감을 할 수 있는 환경을 만들어줌. 단점으로, 세션 당 말이 많다. Attention을 받는 유저들이 꼭 한 두명 있음. 그 사람들의 의견이 크게 반영되는 경우가 많기 때문에 진짜 동의하지 않는 상황에서도 이 사람들의 의견에 따라가는 경우가 많다. Discovery Phase에는 좋은데, 그 이후에는 쓰면 좀..별로..
• Surveys -  기본적인 데이터를 모으기 좋다. A/B테스트도 하고..
• Card Sorting -  기본적인 제품의 구성 A피쳐 B피쳐를 다 카드로 적은 다음에 사람들에게 ‘여러분의 생각대로 그룹핑 해주세요’라고 주문하여 멘탈모델. 도출 그들의 Mental Organisation을 통해 카드가 어떻게 정리되었냐에 따라서.. 이 방법은 양적 질적 리서치 모두 가능. 이걸 온라인으로 돌릴 수 있다. 실제로 7-8명에게 organising 해달라고 할 수도 있고, 유용함.

서베이와 카드소팅은 디스커버리 단계에서만 쓰지는 않음.
Quantitive research, 데이터를 많이 가지고 와서 분석하고 싶을 때 좋은 방법.

Define - Problem Definition

전 단계에서 모은 데이터로 <실제로,정확하게> 문제점이 무엇인지

Clearly defining the problem space by synthesising research findings, identifying user pain points, and framing the design challenge in a way that inspires creativity and innovation.

취합한 수많은 데이터에서 하나로 추려낸다는 의미에서 ‘Converge’ phase.

분석단계 : 다양하게 어떻게 분석을 할 지

Methodologies

• Affinity Mapping - 포스트잇으로 비슷한 데이터나 Finding을 테마별로 인사이트별로 그룹핑 > 그룹핑 한 것들 중 하이레벨 테마로 또 다시 그룹핑 (예 : 유저1이 유저인터뷰에서는 이렇게 얘기했고, 포커스그룹에서도 비슷한 것 두 가지가 나옴. 그럼 그 두 가지를 묶어서 테마를 정해준다. 그래서 유저는 이런 문제가 있다라고 정의함.) 하이레벨 테마에서도 서로 겹치는 테마가 있을 것임. 계속해서 하이레벨로 그룹핑. 어피니티 맵핑으로
• Personas -  데이터 기반 Assumption하여 실제로 존재하는 사람은 아니지만, 우리가 생각할 때 이런 고객이 우리의 제품을 쓰고 있고, 이런 문제를 가지고 있다는 거를 보여주는 페르소나. 디자이너들이나 혹은 스테이크 홀더들 피엠, 엔지니어 등에게 공감을 형성할 수 있게 해줌.
• User Journey Map -  유저가 프로덕트를 이용하는 과정을 보여주는 지도
• Design Principles Establishment - 리서치로 찾은 유저데이터로 Key customer problem을 정의. 엔지니어나 피엠들이 어떤 제품에 이런 아이디어가 있다. 혹은 (엔지니어들이 만들기 복잡하니) 이런 제품의 기능을 간소화 해달라고 하면 .. 많이 데이터들을 모아보면 패턴이 보이잖아요? 유저는 ~할 때 ~하다 등등.. 그거를 글로 적어서 규칙으로 만들어 놓으면 좋다. 나중에 implement phase에서 피엠이나 엔지니어가 ‘우리는 이 Feature를 없애야해 왜냐하면 데드라인이 얼마 안남았어’ 할 때 데이터에 기반한 principle을 제시하며 ‘유저가 이렇기 때문에 이 기능은 필요하다’고 대응할 수 있다.
• Problem Statements - Come up with “How might we” statements to → Stake holder들이 문제점을 파악하고, 집중할 수 있게 해줌.

Design - Ideation

Define단계에서 가져온 포인트들을 가지고, 디자인 시작 + 아이디에이션, 문제해결 과정, 창의적인 아이디어를 낼 수 있음.

Methodologies (정해진 것은 없음)

1. Brainstorming and Ideation - Engage in brainstorming sessions to generate a multitude of ideas and concepts. 

a. Mind Mapping
b. Competitive Analysis
c. Storyboarding

1. Wireframe/Lo-Fidelity Design - Create a skeletal outline or blueprint of the idea. It focuses on structure, layout, and functionality rather than visual design details.
2. Speed Dating - rapid-fire brainstorming or idea generation session where participants rotate between different groups or stations to share and gather ideas quickly.
   
   

Deliver - Test & Repeat

 딜리버 하고 사용하는 유저들 리서치. (리서치로 시작해서 리서치로 끝나는 다이아몬드)

• Prototyping - 디자이너 뿐만아니라 회사, 엔지니어들 모두 선호한다. 이유는 제작비용이 싸고 빠르다. 프로토타입 만들어 유저테스트 (사람들이 실제로 프로덕트를 사용한 것과 같기 때문에 유저빌리티 테스트하기 좋음) > 피드백 받고 디자인 보완 강화 > 다시 테스트 > 디자인 업그레이드 > 엔지니어에게 디자인을 건네기 전에 PRODUCTION READY DESIGN이 됨.
• User Testing - Ensure that the product meets user expectations and performs as intended. Test the product with real users in real-world scenarios to identify and remaining usability issues or areas for improvement.
• Card Sorting - Great methodology to assess user mental model for information hierarchy and architecture.
• Refinement and Prioritisation - Refine and prioritise the proposed solutions. This involves evaluating the feasibility, viability, and desirability of each concept. → 프로덕트 매니저랑 엔지니어 팀, 디자이너과 합쳐지는 상황. 디자인 리서치를 통해서 다양한 Features set을 만들어야 할 때, 주어진 타임라인 안에서 만들 수 있는 제품이 뭘까? 하고, Refinement and Prioritisation 미팅을 많이 함. 디자이너 입장에서 유저를 대변하여 ‘유저가 blahblah 이기 때문에 이 Feature는 꼭 론칭 되어야 한다’등의 의견을 피력할 수 있다. 프로덕트 디자이너는 타임라인에 맞게 주어진 시간 안에 제품을 론칭할 수 있고, 한 번에 다 런칭하지 않아도 되니 어떤 Feature set은 런칭 후에 제작할 수 있다. 등의 결정을 할 수 있다. 엔지니어는 스콥을 어떻게 잡고 어떻게 현실적으로 만들 수 있는지 고민하고, 아 Feature는 없어야 될 거 같다. 너무 크다 혹은 작다. 등의 의견을 냄. 여기서 바로 Converge가 됨. (여기서 무엇이 진짜 Deliver 되는지가 결정된다.)

오토레이아웃 개념 원리

오토레이아웃은 진짜...
잘 모르는 상태에서 오토레이아웃 된 작업물을 접할 때 정말 혼란스럽다..

아무리 유튜브 또는 블로그를 찾아 공부한다고 해도 모르는 부분이 항상 있기 마련.
다시 정리해보는 시간을 가져본다.
원리를 이해하면 피그마 작업효율이 두 배 올라간다!

오토레이아웃 : 컨텐츠에 따라 자유롭게 변형되는 프레임
(피그마는 크기에 따라 사이즈가 유연하게 늘어나는 리사이징 기능을 제공한다.)

• 오토레이아웃의 목적 : 반응형 대응 디자인
• 버튼을 오토레이아웃으로 만들 때, 백그라운드 없이 '텍스트' 만을 가지고 오토레이아웃을 한다. 그러면 텍스트에 '프레임이 씌어져서' 백그라운드가 되어주기 때문에 필요 없음.
  
  
  

오토레이아웃 꿀팁 : 블록을 조합하듯 만들기, 요소를 덩어리 단위로 쪼개서 보고 가장 작은 단위부터 만들기

오토레이아웃 리사이징 (컨텐츠과 컨테이너는 상대적인 관계)

오토레이아웃 프레임에서 기준보다 바깥에 있으면 컨테이너, 안에 있으면 콘텐츠라고 본다면..
오토레이아웃 프레임 생성 시, 상위 프레임 사이즈가 조정될 때, 콘텐츠와 컨테이너가 어떻게 반응해야할지 설정하는 속성

• |ㅡ| Fixed width (모든 경우에 뜸)
• > < Hug (안에 컨텐츠가 있어야 만 뜸- 아래 예시 : 파란색, 베이지 박스에만 뜸)
• < > Fill container (밖에 컨테이너가 있어야 만 뜸)

오토레이아웃 리사이징 속성
1. Hug content : hug(감싸안다) + content(콘텐츠) :컨테이너가 콘텐츠를 감싸안는 속성임으로 안에 콘텐츠가 있어야 뜬다.
컨테이너에 hug contents를 적용하고 콘텐츠 상자를 늘리면 늘어나는 콘텐츠 상자 크기에 맞게 컨테이너가 감싸줌.
2. Fill container : Fill(채우다) + container(컨테이너) : 콘텐츠가 컨테이너를 채우는 속성, 즉 바깥에 컨테이너가 있어야만 뜬다.
콘텐츠에 fill container를 적용하고 컨테이너 상자를 늘리면... 그에 맞게 안의 콘텐츠가 컨테이너 상자를 채워줌.
3. Fixed Size : Fixed(고정하다) + Size(크기) : 컨테이너와 콘텐츠 모두 고정된 상태, 즉 고정임으로 상대적 개념이 아닌 모든 경우에 뜬다. (고정되어 늘려도 안변함)

모바일 서비스를 위한 앱 개발 과정

네이티브 앱

• 하나의 운영체제에서만 동작.
• 모든 운영체제에서 동작하게 하려면 각 운영체제에 맞는 언어로 각각 개발해야만 함.
• 그래서 모든 사용자를 고려하면 개발 리소스 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개 이상 선택할 수 있다.]

웹/앱 디자인 시 반드시 알아야 할 것들 - 픽셀 밀도와 선명도의 상관관계

픽셀 - 화면을 구성하는 기본 단위, 화면의 선명도에 영향을 줌. 픽셀의 많고 적음을 '픽셀 밀도'라고 하는데, 같은 면적 안에 픽셀이 얼마나 있느냐에 따라 달라짐. 밀도가 높을 수록 선명..

ppi - pixel per inch. (2.54cm), 1인치 당 픽셀 수를 이 단위로 표현하는 것.

실무하면서 알게 된 것 : 파견 나간 회사에서 무려 '포토샵'으로 웹디자인을 했는데, (그 때 까지 피그마로만 작업해서 몰랐지만) 웹 작업물은 72ppi로 설정해야한다고 한다.

→(책에 따르면)..72ppi는 육안으로 모니터를 봤을 때 선명함을 식별할 수 있는 경계선. 따라서 기준 ppi에서 픽셀을 더해도 '더 선명해졌다'는 걸 인식하지 못하기 때문에 웹에서는 굳이 픽셀 밀도를 높일 필요가 없다.

+ 프린트 해상도의 절반인 72ppi 모니터에서 디자인하고 인쇄하면 모니터에서 본 이미지와 인쇄물에서의 이미지 크기가 거의 일치. 

픽셀의 다양한 표현 방식

기술이 발전함에 따라 픽셀 밀도는 점차 늘어난다. iOS는 1곱하기, 2곱하기, 3곱하기 까지, 안드로이는 0.5, 1, 1.5, 2, 3, 4곱하기 까지 픽셀밀도를 지원한다.

실제 우리가 디바이스에서 보는 픽셀 밀도는 논리적 해상도(logical pixel), 물리적 해상도(rendered pixel), 그리고 다운 샘플링(down sampling)이라는 단계를 거쳐 기기에 적용되는데 이를 픽셀 밀도 변화 과정이라고 함.

복잡해 보이지만 걱정마시길. 디자인 기준은 1pt =1px, 1dp = 1px

1단계 - 논리적 해상도 logical pixel (순수 픽셀 밀도)

보통 피그마 같은 툴에서 모바일 화면 디자인할 때 기준 단위. 기준 단위는 iOS는 PT(point), 안드로이드는 DP(device point)라고 한다. 즉, 논리적 해상도로 디자인을 하면 해상도가 다른 기기라도 디자이너가 생각한 비율과 동일하게 출력할 수 있음.

+ 안드로이드에 DP 말고 SP도 있다. Scale independent pixel의 약자로, 글자 크기와 폰트만 독립적으로 변환이 가능하다는 뜻. (사용자의 시각적 편의를 위해 적용된 단위, 반대로 사용자가 임의로 글자 크기와 폰트를 사용자가 임의로 바꾸지 못하게 해서 레이아웃의 일관성을 유지하고 싶으면, 단위를 SP가 아닌 DP로 설정함.

2단계 - 물리적 해상도 Rendered Pixel

물리적 해상도는 레티나 디스플레이 (x2, x3)기술이 적용되는 단계. PT, DP 같은 논리적 해상도가 아닌, 기기에 정해진 배율을 곱해 픽셀을 얻는 것. (Resterization '래스터화'라고도 함).

쉽게 말해, 논리적 해상도의 벡터 속성이 '픽셀화'되는 것

물리적 해상도의 배율을 기기마다 정해져 있기 때문에 디자이너가 임의로 지정하지 않아도 됨. 즉, 디자이너는 논리적 해상도 (x1)로만 디자인해 두면 기기마다 다른 배율을 일일이 신경 쓸 필요가 없다.

3단계 - 다운 샘플링 

물리적 해상도를 만드는 단계에서 두 세배 높은 픽셀을 얻었지만 어떤 기기는 이 픽셀을 다 담지 못함. 이 때 늘어난 픽셀을 기기에 맞게 해상도를 조절해야하는데 이를 다운 샘플링이라고 한다.

4단계 - 기기 표현

실제로 기기에 표현되는 시점. 기기별 ppi가 다르다. 픽셀은 밀도에 따라 크기가 달라지는 특성이 있다. 같은 화면이라도 ppi에 따라 밀도가 달라지며 이는 선명도에 영향을 준다. 디스플레이의 발전에 따라 같은 크기에 더 많은 픽셀을 담아 선명해진 것이다. 미세한 선이나 얇은 폰트도 연출할 수 있게 되었다.