1, 이 책에서는 설계 프로세스를 체계적으로 추진하고 특정 제품 목표와 팀 특성을 중심으로 설계 시스템을 구축하는 방법에 대해 설명합니다.
2. 설계 시스템은 다양한 패턴, 조직 구조, 팀 문화, 제품 유형 및 설계 프로세스로 구성됩니다. 여기서 설계 패턴은 우리가 논의해야 할 핵심 내용입니다.
디자인 패턴은 디자인 사양이 아닙니다. 전통적인 설계 사양은 글꼴, 색상, 아이콘 등의 정의이며 스타일에 더 중점을 둡니다. 디자인 패턴은 재사용 가능한 모든 인터페이스 구성 요소를 나타냅니다. 싼 아저씨의 이해에 따르면 패턴은 추상적인 것이 아니라 당신의 구체적인 업무와 제품입니다. 예를 들어, 로그인 등록, 모든 제품은 가지고 있지만, 어떤 이유로 등록할 때 아바타를 제출해야 할 수도 있습니다. 그러면 제품에 따라 등록 모드를 설정할 수 있습니다.
나는 많은 사람들이 인색한 아저씨처럼 회사를 위해 디자인 규범을 만들었다고 믿는다. 이전 역사를 뒤집고 1.0.0 부터 올해 4.0.0 까지 총 4 회 반복했지만, 사실 큰 변화는 두 가지 버전일 뿐이다. 초판이 설립되었을 때 길조 삼촌은 조수로 주로 회사의 한 디자이너가 만들었다. 그녀는 PS 로 회사의 초판 설계 사양을 세웠다. 당시 두세 명밖에 없었다. 한 번 보세요. 몇 가지 중요한 색상 값을 적어두면 됩니다. 사양 문제도 분명합니다.
1. 기본 사양은 읽기에만 적용되며 직접 액세스할 수 없습니다.
2. 사양의 컨트롤, 어셈블리, 부품이 뒤섞여 비즈니스 변화에 따라 사양 변경이 잦은 경우가 많습니다.
3. 전체 규범은 협력, 유지 관리, 반복에 불리하지만 당시 두세 명밖에 없었기 때문에 이 문제는 분명하지 않았다.
그래서 버전 2.0.0 에서 싼 아저씨는 사용량에 따라 몇 가지를 최적화했습니다. 1, 문서를 스케치 소스 파일에서 분리하여 문서를 볼 수 있도록 하고, 스케치 소스 파일을 직접 사용합니다. 2. 기본 통제를 업무 통제와 분리합니다. 기본 컨트롤은 팝업, 토스트와 같은 시스템 컨트롤이며, 비즈니스 컨트롤은 비즈니스 장면 침전을 기반으로 하는 컨트롤입니다. 3. 개정 레코드를 추가합니다. 자, 문제가 있습니다.
1, 수정하기가 번거롭습니다. 한 곳을 바꾸기 위해서는 두 개의 파일을 업데이트해야 합니다.
2. 공동 작업 효율이 좋지 않아 다른 사람에게 업데이트를 통지해야 합니다. 그렇지 않으면 정보가 동일하지 않습니다.
3. 비즈니스 컨트롤이 점점 많아지면서 거의 모든 장면 스타일이 있습니다. -응?
이것들은 익숙한 설계 사양입니까? 글꼴, 색상, 아이콘, 컨트롤 등의 표준화. 기본적으로 디자인 팀의 모든 표준입니다. 우리가 정의하는 기본 컨트롤은 iOS 및 재질 디자인을 필터링하는 컨트롤입니다. 나중에 개미가 디자인한 후, 우리는 일부 페이지가 웹이라는 것을 깨달았고, 그 결과 우리의 기본 컨트롤은 단지 세 플랫폼 간의 균형을 찾고, 조금 정의하여 우리의 제품 요구에 더 잘 맞도록 했다.
우리는 무엇을 설계하고 있습니까?
사실, 2.0.0 버전의 비즈니스 제어는 디자인 타임에 이미 한 페이지를 의식적으로 요약하여 같은 문제에 대해 솔루션을 반복적으로 생각할 필요가 없도록 하는 것이다. (존 F. 케네디, 공부명언) 모델 재고의 의미도 마찬가지다. 당사의 제품은 4 ~ 50 개의 기능을 가지고 있으며, 6 명의 디자이너가 동시에 다른 기능을 설계한다. 누구나 디자인 할 수있는 똑같은 정보 디스플레이 페이지를 디자인 할 수 있습니까? 그런데 정보전시페이지가 마주할 수 있는 상가는 다르지만 디자인이 다르면 안 되나요? 이 책에서는 동일한 정보 아키텍처와 동일한 기능을 동일한 디자인 패턴으로 분류할 수 있다고 말합니다. 비즈니스 시나리오마다 모양 요구 사항과 동작이 다를 수 있지만 이는 패턴의 변형일 뿐 다른 패턴은 아닙니다.
나는 대충 목록 페이지를 수집했다. 물론 목록은 해당 표현식일 뿐입니다. 그들의 목적은 커뮤니티 게시판과 비슷한 정보를 보여주는 것이다. 내가 책에서 쓴 내용에 따르면, 나는 페이지를 기능별로 분류하고, 정보 구조를 분해하고, 이 모델에' 창 목록' 이라는 이름을 붙였다.
왜 창 목록이라고 불러요? 이름은 책에 적혀 있다. 기억하기 쉽고 기능과 연결되어 있어야 합니다. 목록 1 목록 2 보다 창 목록을 기억하기 쉽습니다.
그래서 원래의 질문으로 돌아갑니다. 우리는 무엇을 디자인하고 있습니까?
인색한 아저씨는 우리가 진정한 수요를 알아야 한다고 생각한다. 디자인은 단순히 문제를 해결하기 위한 것이 아니라, 진짜 문제를 보아야 한다. 큰 공장이 걸핏하면 크고 완전한 기능 제어 라이브러리를 만드는 것을 좋아하는 것처럼, 사실 불필요한 반복 작업을 어느 정도 줄일 수 있으니, 우리는 사용자와 수요를 이해하는 데 더욱 집중해야 한다.
우리는 어떤 팀입니까?
어떤 팀과 조직 구조가 실제로 우리의 설계 체계에 영향을 끼쳤는가. 구체적으로 디자인 제도의 세 가지 측면, 즉 실용규칙 (엄함과 소나무) 에 나타난다. 건설 모드 (모듈화, 통합); 관리 메커니즘 (중앙 집중식 분산). (번역문은 번역사 C72 10 에서 발췌한 것으로 링크가 첨부되어 있다. 나중에 이 책은 Airbnb, ted, Future Learn 의 예를 인용했다.
이 인색한 아저씨는 통찰력이 있다. 당초 규범을 세웠을 때, 일부 팀원들은 규범이 너무 가늘어서 디자이너의 발휘에 영향을 미칠까 봐 걱정했다. 하지만 책의 이 장은 팀의 스타일 건설을 포함한 제품을 서비스하는 것이 궁극적인 목적이라는 것을 잘 알고 있다. (윌리엄 셰익스피어, 윈스턴, 독서명언) (윌리엄 셰익스피어, 윈스턴, 독서명언) 우리는 자신의 요구에 따라 우리 팀에 속한 설계 체계를 맞춤화할 수 있다.
사실 아직 적지 않은 작은 점들이 많이 남아 있다. 왜냐하면 문장 너무 길어서 잔소리가 너무 길어서 나머지는 모두가 직접 보는 것을 볼 수 있기 때문이다. (윌리엄 셰익스피어, 햄릿, 독서명언) 나는 내가 가장 중요하다고 생각하는 것만 썼다. 읽어 주셔서 감사합니다.
번역 버전 링크:
/s? _ _ biz = mjm5 MDC 0 MDI yma = = & Mid=26506 19728 입니다. Idx= 1 입니다. Sn = 292 caed 44 C7 f985 ca 52ab0c18f357c7f & Chksm = be49a4c3893e2dd57d13f23a8d0 cdecb28ab3e2c67b37b894628e4e7670 cdb263b0e98187cbc Mpshare =1& 장면 = 23 & ampsrc id =1219 scj6 pdpxjkdz 68x1pt9o% 23 일