Cloe

안녕하세요 튜터님! 빠른 답변에 너무 감사드립니다.답변을 보고 전체적으로 명쾌하게 이해가 되었고, 추가로 몇가지 연관 질문이 있어 남겨봅니다.&nbsp;<ol start="2"><li>Scrim, Overlay, Dimmed의 의미&nbsp;용어가 비슷한경우 워크샵으로 용어를 통일한다고 말씀주셨는데요. 보통 이런 논의를 할때는 대부분 어떤 용어든 정해지면 상관없어요 라는 경우도있지만, 어떤 용어가 더 익숙하다고 의견이 다른경우도 발생할 수 있을것 같아서요.&nbsp;&nbsp;이럴때는 어떤 근거를 기준으로 제안을하면 보다 객관적이고 모두가 공감하는 방향일까요? 상황따라 다르겠지만 이건 디자인이나 용어의 영역보다는 설득과 협업의 영역처럼 보이기는 하네요^^;&nbsp;설득력있고 논리적인 디자인은 경험(시니어 vs 주니어), 지식(전공 vs 비전공 vs 논문발췌 등), 레퍼런스나 요새 트렌드 등 다양한 루트를 통해 고려될수있을것 같은데, 개인적으로 튜터님의 경험이나 인사이트가 궁금해 여쭤보게 되었습니다. 스스로 납득할수있는 근거를 가지는게 디자인 중심을 지키며 진행시킬수있는 힘이 될것 같아서요.&nbsp;개인적으로는 버튼 state를 press라고 할지 pressed라고 할지 고민이 되었던적도 있고, hover&pressed를 구분하지 않고 따로 쓰는 경우도 많이 보이는데 과정의 단순화를 위해 state, interaction을 간소화하는게 맞는 방향일지, 아니면 사소한것이라도 시각적위계와 시스템 체계를위해, 그리고 보다 퀄리티있고 섬세한 작업을 위해 구분해서 쓰는게 맞을지와 같은 정답과 취향, 신념사이에서 아직 정체성을 만들어가고있는 단계이다보니 파생되는 궁금한점들이 많았던것 같아요.&nbsp;&nbsp;</li><li>레이어 네이밍 전략&nbsp;레이어 네이밍 단계를 말씀주신건 너무 유용한것 같습니다. 그런데 저희 개발자분들께서는 레이어명을 거의 안본다고 하시더라구요. &nbsp;그러면 레이어명을 관리하는 목적은, 디자인팀 내부의 소통과 레이어명을 쉽게 find & replace하기위함일까 싶어서요. 왜 필요한지에 대한 납득이 되지 않으면 업무가 바쁠땐 상대적으로 제가 중요도를 낮게 가져가는 작업이 될까봐 한번 더 여쭤보게 되었습니다 . </li></ol><ol start="5"><li>에이전시의 멀티 프로젝트 관리&nbsp;말씀주신 Conde Nast의 방법으로 스타일을 스왑해 사용하는것은 에이전시에서 멀티프로젝트를 지속적으로 관리해나가는 경우를 말씀주신걸까요?&nbsp;1회성 프로젝트의 경우에도 말씀주신것처럼 각 프로젝트 5개에대한 스타일을 각각 만들고, 이후에 생성하는 6번째 신규 프로젝트부터는 5개 스타일중 적용할 수 있는 비슷한 스타일을 라이브러리로 가져와 적용하는 방식을 말씀주신걸까요?&nbsp;&nbsp;예를들어 베리어블을 1) 프로젝트별로 생성하는 경우, 2) 도메인별로 생성해(이커머스, 금융, 패션 등..) 스타일을 만들고, 비슷한 도메인일경우 각 해당되는 스타일을 적용하는 경우, 3) 어디서나 적용되는 기본형태 스타일을 생성하고, 해당 스타일을 lo-fi에 적용한뒤, 디자인 디벨롭 단계에서는 각 프로젝트 목적에 맞게 시스템을 적용하지않고 local style로 hi-fi를 만드는것 이런 3가지 케이스를 고려해보았었는데.. 튜터님이 말씀하신 화이트라벨 컴포넌트 라이브러리를 생성하는 방식을 제가 잘 이해한것일지 모르겠어서 한번 더 여쭈어봅니다^^;</li></ol>강의내용도, 답변도 큰 도움이 되었습니다. 특히 shadow쪽 답변을 보고 간단한 내용일수있어도 기본 개념을 알고 적용하는게 온/오프라인 관계없이 너무 중요하다는 생각이 다시한번 드네요^^ 덕분에 다시한번 개념을 짚게 되었습니다. 좋은 답변주셔서 감사드립니다!!&nbsp;

Cloe

Posts