앱이 개발한 디자인 프로세스?

비즈니스 분석은 제품의 비즈니스 가치를 반영할 수 있으며, 제품 수명 주기 동안 가장 거시적인 지침 문서이며, 보고서는 이 작업의 출력 문서입니다. 간단히 말해 업계 전망, 즉 이 신제품이 상업적 가치가 있는지 여부, 제품 사용 후 수익이 무엇인지 등을 알 수 있습니다. 이 단계는 고위층, 심지어 창업자들이 이미 전체 시장을 통제했다는 결론일 것이다. 이 단계에서 신제품과 기존 제품의 새로운 모듈 기능 분석이 크게 다르고 신제품 분석이 더 어렵다는 점은 주목할 만하다. 기존 제품은 이미 어느 정도의 데이터를 축적하여 업계와 사용자에 대해 더 잘 알고 있기 때문에 새로운 모듈 기능을 할 때 저항이 훨씬 적은 경우가 많습니다.

둘째, 제품 포지셔닝

이 단어는 막 일에 참가한 동창들이 들은 후에 사실 매우 허황된 것이다. UI 를 처음 만들었을 때 제품 포지셔닝, 시장 분석 같은 단어를 들었는데 사실 졸려요. 나는 나에게 수요를 직접 알려주면 좋을 줄 알았다. 왜 굳이 그렇게 빈말을 많이 해야 합니까? 하지만 3 ~ 5 년 동안 일한 후, 이것들은 사실 매우 중요하다. 제품 포지셔닝의 핵심 정보는 사실 이 제품이 무슨 용도로 쓰이는지, 예를 들면 위챗, 사교.

셋째, 수요 단계

일단 시장 방향이 정해지면, 이 방향에서 시급히 해결해야 할 수요가 무엇인지 알아내야 한다. 수요 측면에서도 이 시장 방향의 많은 직접 및 간접 경쟁자를 발견할 수 있습니다. 이 단계는 우리의 UI 에 매우 가깝다. 시장 분석과 제품 포지셔닝이 확정되면 어떤 수요가 시급히 해결되어야 하는지를 명확히 해야 한다. 여기서 PM 은 경품의 장단점을 나열하는 경품 분석 보고서를 자주 출력하고, 일부는 SWOT 분석도 한다.

넷째, 제품 디자인

이 링크는 UI 에서 빼놓을 수 없다. 우리가 수요를 제시할 때마다 이 물건을 볼 수 있기 때문이다. 이 물건은 우리와 밀접한 관련이 있고, 또한 우리가 가장 잘 아는 작업이다. 이 링크, pm 은 실제로 프로토 타입을 그리고 문서를 쓰는 것입니다. 하지만 사실, 내 오랜 경험에 따르면, 정말 핍박하는 pm 은 여전히 매우 적다. 주로 프로토타입이 거칠게 그려지고, 문서 묘사가 생략되고, UI 디자인이 PM 보다 좋은 곳이 많다. 또 다른 이유는 대부분의 초급 pm 이 경매품을 베끼는 데 능숙하지만, 이 두 제품이 본질적으로 다르다는 것을 모르는 경우가 많기 때문이다. 이 단계는 기본적으로 PM 과 UE 가 완성한다. 상호 작용이 완료되면 내부 상호 작용 검토가 진행되며 상호 작용 시나리오를 확인한 후 UI 디자이너에게 전달됩니다.

우리는 직장에서 다양한 원형 상호 작용 다이어그램을 볼 수 있지만 잘 그려지는 경우는 거의 없다. 우리가 기본적으로 보는 것은 다음과 같은 것들이 무섭지 않다는 것이다.

PM 은 전체 제품 계획에서 어떤 목표를 달성하고 싶습니까? 제품 기획이 달성해야 할 목표는 사실 제품 가치다. 제품 계획에서는 각 단계의 목표가 무엇인지 명확히 해야 하며, 모든 의사 결정과 행동은 이 목표를 중심으로 진행되며, 결국 데이터 등 평가 가능한 방법을 통해 문제가 해결되었는지 여부를 판단해야 합니다. 이를 위해서는 사용자 활동, 거래액 등의 지표와 같은 단계적 목표가 명확해야 하며, 이는 모두 이전 단계가 유효한지 확인하는 근거가 됩니다. 제품 계획을 공중 누각으로 만들지 마라. 실행할 수 없는 가짜 문서는 0- 1 의 제품 수명 주기에 심각한 영향을 미칠 수 있다.

다섯째, 수요 검토

이는 기본적으로 제품 요구 사항이 확정되면 제품이 회의를 열고 프로젝트의 각 기능 책임자가 회의에 참석한다는 것을 의미합니다. 일반 PM, UE, UI, RD, FE, QA 등 다섯 가지 책임을 가진 사람들이 모두 검토에 참여합니다. 회의 기간 동안 PM 은 수요 문서 (대기업은 일반적으로 위키를 사용) 를 설명했다. 경험에 따르면 R&D 는 일반적으로 가장 많은 질문을 합니다. PM, UE, UI 는 모두 검토 전에 확인되기 때문입니다. R&D 및 테스트에서는 코드를 직접 호출할 수 있는지 여부와 같은 위험한 질문을 했습니다. 그렇지 않으면 위험 힌트가 발생할 수 있습니다. 기술적인 어려움 등이 있습니다. 검토가 완료되면 R&D 가 일정을 잡을 것입니다.

여섯째, UI 디자이너의 개입은 몇 가지로 나뉜다.

1. 우리가 프로젝트를 받은 후, 특히 해본 적이 없으니 급하게 그림을 그리지 마세요. 우선 제품의 의도와 목적을 분명히 해야 한다. 둘째, 전체 제품 라인 (여기서는 주로 전체 app 디자인 조율, 글꼴 크기, 간격) 을 자세히 살펴본 다음 경품을 분석해야 합니다 (여기서 분석은 제품 분석과는 달리 주로 시각층을 보면 참조 찾기). ) 을 참조하십시오

2. 우리는 설계를 결정할 때 전체적인 설계 진도를 예측한 다음 설계 진도를 내야 한다. 진도는 페이지 디자인+수정 시간에 따라 계산되어 프로젝트 연기를 방지해야 한다. 개인적으로, 10 인터페이스와 같은, 나는 3 일 동안 디자인하고 상류와 확인한 다음 1 일, 즉 4 일 동안 시간이 충분하다면 수정합니다. Keynote 또는 excel 을 사용하여 특정 페이지의 구체적인 시간을 나열한 다음 정련하는 것이 좋습니다.

3. 설계에서는 일반적으로 @2x 에 따라 UI 사양의 올바른 실행을 보장합니다 (아이콘 두께 균일 여부, 시각적 두께, 글꼴 두께, 배수별 간격 및 색상이 전체 제품 톤과 일치하는지 여부 포함). ) 을 참조하십시오

4. 차트를 자르고 표시를 합니다. @2x 디자인에서 아이콘/배경을 잘라냅니다. 드로잉 컷에는 두 가지 유형이 있습니다. 하나는 칼로 잘라낼 수 있고 (핫스폿을 지정하고 바로 가기 S 만 누르면 됨), 다른 하나는 구성 요소로 잘라낼 수 있습니다 (핫스폿을 지정하고, 구성 요소를 마우스 오른쪽 버튼으로 만들고, 두 번 클릭하고, 내보내기). 명명 규칙의 초보자는 반드시 중국어로 이름을 지어야 하지만, 올바른 방식으로 이름을 지정해야 합니다. 일반적으로 where/what/state/multiple 입니다. 물론, 너도 좀 더 명확한 규격을 가질 수 있다. 모든 것이 정상이면 파란색 석호에 올릴 수 있습니다. 하지만 지금 어떤 회사들은 figma~ ~ 를 사용해도 좋습니다.

5. 개발이 끝나면 UI 디자인 초안을 시각적으로 복원해야 합니다. 즉 쿼리 디버깅 단계에 들어가야 합니다. 강조해야 할 것은 (기술적으로 쓸 수 없는 것은 없다. 개발자가 할 수 없다고 하면 그는 게을러야 한다.) 내 경험에 따르면, 일부 개발 감소도는 매우 낮고, 기본적으로 50% 이며, 일부 대형 공장에는 개발 감소도가 60% 미만이면 개발로 돌아가서 재조정하고 다시 가는 원칙이 있다. 기본적으로 글꼴 크기, 두께, 색상, 간격, 아이콘, 여백 등의 기준을 조사해 보면 개발이 정말 좋지 않다는 것을 알 수 있습니다 ~ ~ ~, 기본 95% 를 합치면 거의 됩니다.

공동 조정 단계는 다음과 같습니다. 우리는 여러 브랜드의 테스트 폰을 사용해야 합니다. 한 휴대폰에 문제가 없다면 다른 휴대폰에는 유해평 호환, @3x 화면 등과 같은 작은 오차가 있을 수 있기 때문입니다. 우리는 테스트 휴대폰의 각 인터페이스 스크린 샷을 위키에 넣고 문제를 표기한 다음 wiki 다이어그램을 참고로 매핑하여 개발이 명확해 보이게 했다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 테스트명언) 만약 한 번의 연조에 문제가 있다면, 2 ~ 3 번의 연조가 있을 수 있다. 개발이 90% 로 회복될 때, 우리는 작은 벤치를 개발측으로 옮기고 만족할 때까지 세부 사항을 직접 조정할 수 있다.

6.QA 테스트 링크

사실, 이 링크에 있는 대부분의 디자이너들의 통속적인 느낌은 시험이 버그를 키우는 데 쓰이는 것이다 ~ 네, 통속적인 점은 이렇습니다. 버그는 실제로 전체 제품에 영향을 미치는 가장 큰 장애물입니다. 프로젝트가 온라인 상태일 때 버그가 없는지 확인해야 하며, 버그 해결의 우선 순위가 가장 높다. 정확히 말하자면, QA 는 개발 구현의 기능이 제품, UI, 대화형 설계와 일치하는지 확인하는 것입니다. 몇 가지 이상 상황을 발견하고, 프로젝트의 품질 부분을 최적화하고 통제하다. 사실, 여러분은 위험 통제와 비슷한 것으로 이해할 수 있습니다 ~

여기에 작은 점이 있다: 정식 전면 온라인 전에 tips 환경에 접속한다. 그렇다면 tips 는 무엇일까? 사실 테스트를 위한 것입니다. 테스트 환경의 데이터는 온라인 환경의 데이터와 다를 수 있습니다. 테스트 환경에서는 일부 문제가 반영되지 않을 수 있으므로 먼저 tips, tips 환경 및 온라인 데이터를 사용해야 합니다.

7. 제품 수락 링크

제품 검수는 0- 1 프로세스에서 매우 중요한 부분이며, 제품 검수의 최종 결과는 온라인이지만 그 전에 반복적으로 수정될 수 있습니다.

제품이 온라인 상태가 되기 전에 테스트, UI 검수, 제품 검수를 통과해야 하는 것은 제품의 품질을 통제하는 데 필요한 수단이다. 제품 수용이 더 중요한 것은 제품 관점에서 개발이 제품 요구 사항을 충족하는지 확인하고, 비즈니스 논리에 초점을 맞추고, 수요에 대한 책임을 지는 것입니다.