인프런 커뮤니티 질문&답변

안녕하세요 튜터님! 빠른 답변에 너무 감사드립니다.

답변을 보고 전체적으로 명쾌하게 이해가 되었고, 추가로 몇가지 연관 질문이 있어 남겨봅니다.

2. Scrim, Overlay, Dimmed의 의미

    

   용어가 비슷한경우 워크샵으로 용어를 통일한다고 말씀주셨는데요. 보통 이런 논의를 할때는 대부분 어떤 용어든 정해지면 상관없어요 라는 경우도있지만, 어떤 용어가 더 익숙하다고 의견이 다른경우도 발생할 수 있을것 같아서요.

    

    

   이럴때는 어떤 근거를 기준으로 제안을하면 보다 객관적이고 모두가 공감하는 방향일까요? 상황따라 다르겠지만 이건 디자인이나 용어의 영역보다는 설득과 협업의 영역처럼 보이기는 하네요^^;

    

   설득력있고 논리적인 디자인은 경험(시니어 vs 주니어), 지식(전공 vs 비전공 vs 논문발췌 등), 레퍼런스나 요새 트렌드 등 다양한 루트를 통해 고려될수있을것 같은데, 개인적으로 튜터님의 경험이나 인사이트가 궁금해 여쭤보게 되었습니다. 스스로 납득할수있는 근거를 가지는게 디자인 중심을 지키며 진행시킬수있는 힘이 될것 같아서요.

    

   개인적으로는 버튼 state를 press라고 할지 pressed라고 할지 고민이 되었던적도 있고, hover&pressed를 구분하지 않고 따로 쓰는 경우도 많이 보이는데 과정의 단순화를 위해 state, interaction을 간소화하는게 맞는 방향일지, 아니면 사소한것이라도 시각적위계와 시스템 체계를위해, 그리고 보다 퀄리티있고 섬세한 작업을 위해 구분해서 쓰는게 맞을지와 같은 정답과 취향, 신념사이에서 아직 정체성을 만들어가고있는 단계이다보니 파생되는 궁금한점들이 많았던것 같아요.

    

    

3. 레이어 네이밍 전략

    

   레이어 네이밍 단계를 말씀주신건 너무 유용한것 같습니다. 그런데 저희 개발자분들께서는 레이어명을 거의 안본다고 하시더라구요.

    

   그러면 레이어명을 관리하는 목적은, 디자인팀 내부의 소통과 레이어명을 쉽게 find & replace하기위함일까 싶어서요. 왜 필요한지에 대한 납득이 되지 않으면 업무가 바쁠땐 상대적으로 제가 중요도를 낮게 가져가는 작업이 될까봐 한번 더 여쭤보게 되었습니다 .

5. 에이전시의 멀티 프로젝트 관리

    

   말씀주신 Conde Nast의 방법으로 스타일을 스왑해 사용하는것은 에이전시에서 멀티프로젝트를 지속적으로 관리해나가는 경우를 말씀주신걸까요?

    

   1회성 프로젝트의 경우에도 말씀주신것처럼 각 프로젝트 5개에대한 스타일을 각각 만들고, 이후에 생성하는 6번째 신규 프로젝트부터는 5개 스타일중 적용할 수 있는 비슷한 스타일을 라이브러리로 가져와 적용하는 방식을 말씀주신걸까요?

    

    

   예를들어 베리어블을 1) 프로젝트별로 생성하는 경우, 2) 도메인별로 생성해(이커머스, 금융, 패션 등..) 스타일을 만들고, 비슷한 도메인일경우 각 해당되는 스타일을 적용하는 경우, 3) 어디서나 적용되는 기본형태 스타일을 생성하고, 해당 스타일을 lo-fi에 적용한뒤, 디자인 디벨롭 단계에서는 각 프로젝트 목적에 맞게 시스템을 적용하지않고 local style로 hi-fi를 만드는것 이런 3가지 케이스를 고려해보았었는데.. 튜터님이 말씀하신 화이트라벨 컴포넌트 라이브러리를 생성하는 방식을 제가 잘 이해한것일지 모르겠어서 한번 더 여쭈어봅니다^^;

강의내용도, 답변도 큰 도움이 되었습니다. 특히 shadow쪽 답변을 보고 간단한 내용일수있어도 기본 개념을 알고 적용하는게 온/오프라인 관계없이 너무 중요하다는 생각이 다시한번 드네요^^ 덕분에 다시한번 개념을 짚게 되었습니다. 좋은 답변주셔서 감사드립니다!!

안녕하세요, Cloe님, 좋은 질문들 주셔서 정말 감사합니다. 사소한 질문도 언제든지 남겨주세요.

1. 두 개의 Shadow를 사용하는 이유

첫째, 효과(effect)를 사용하는 이유는 우리가 구현하는 UI가 현실과 최대한 비슷하게 보이도록 하기 위함입니다. 그중에서도 Shadow는 빛과 관련되어 입체감을 나타내는 중요한 역할을 합니다.

제가 준비 중인 기초 강의 내용을 참고하자면, 미술 시간에 원형 구에 빛이 비추었을 때를 떠올려보세요. 아래에 넓게 드리워진 그림자와 그 안에 반사광이 미치지 않는 매우 어두운 그림자를 기억하실 것입니다. Shadow를 구현할 때도 이와 마찬가지로, 빛이 비추면서 반사광에 의해 희미해진 Cast Shadow와 Occlusion Shadow를 함께 표현한 것입니다. 이 두 가지 개념이 두 개의 Shadow를 사용하는 주요 이유 중 하나라고 생각합니다.

2. Scrim, Overlay, Dimmed의 의미

Scrim, Overlay, Dimmed는 모두 모달 창과 배경 콘텐츠를 구분하기 위해 사용됩니다. 명확하게 구분하면 약간의 차이가 있겠지만, 역할 측면에서는 비슷합니다. 여러 디자이너들과 작업하다 보면 각자의 경험에 따라 다른 용어를 사용하는 경우가 많습니다. 특히 베리어블(variable)을 작성하거나 컴포넌트 네이밍을 정할 때도 마찬가지입니다. 이런 경우 저는 워크샵을 통해 용어를 통일하는 편입니다.

• Status vs. State

• Disable vs. Disabled, Enable vs. Enabled

• Collapsed, Expanded vs. Open, Close

• Collapse vs. Collapsed (수동태, 능동태 등)

등등

이러한 용어들을 함께 정리하고 문서화하는 것이 매우 중요합니다.

3. 레이어 네이밍 전략

네이밍의 경우, 제가 4월에 진행한 워크샵에서 진행한 다음의 방법이 매우 유용합니다.

우리가 디자인을 할 때 보통 세 가지 단계가 있습니다: 아이디어, 디벨롭, 핸드오프.

1. 아이디어 단계: 레이어 이름에 신경 쓰지 말고 마음껏 만듭니다. 예를 들어 ‘Frame2212312’처럼 이름이 되어도 상관없습니다. 아이디어에 집중하는 것이 중요합니다.

2. 디벨롭 단계: 이 단계에서는 깔끔하게 정리하면 됩니다. Figma의 AI Rename 기능을 사용하면 간단히 정리할 수 있습니다.

3. 핸드오프 단계: 개발자들이 이해하기 쉽도록 의미 있게 정리합니다. 번거로울 수 있지만 ‘Container’, ‘Wrap’ 등 기본적인 용어를 사용하여 정리하면 됩니다. 너무 멋진 이름을 만들려고 하지 않아도 됩니다. 개발자분들은 레이어보다는 오른쪽의 프로퍼티에 더 관심이 많습니다.

4. 라이브러리 활용

라이브러리를 사용할 때는 베리어블(토큰)을 만들 때 라이브러리의 용어를 참고하여 만드는 것을 추천드립니다. 하지만 무엇보다도 개발자분들과 상의하여 어떻게 구성할지 결정하는 것이 가장 중요합니다.

라이브러리의 장점은 이미 만들어져 있다는 것이지만, 서비스에 따라 수정이 필요할 수도 있습니다. 최대한 라이브러리와 동일하게 구현하거나 비슷한 라이브러리를 찾아 커스텀하는 것도 좋은 방법입니다. 제 강의에서 제공하는 33개의 컴포넌트를 만들어보시면 모두 구현하실 수 있을 것입니다.

5. 에이전시의 멀티 프로젝트 관리

에이전시에서 여러 프로젝트를 동시에 진행하는 경우, 초기에도 언급했던 Conde Nast의 방법이 유용할 것 같습니다.

화이트라벨 컴포넌트 라이브러리를 사용하여 스타일 가이드를 스왑하는 방식인데요. 제 강의에서 언급한 방법도 좋지만, 엔터프라이즈 계정은 40개의 모드를 지원하는 반면, 오거나이제이션 계정은 최대 4개까지만 지원합니다.

그래서 추천드리는 방법은 예를 들어, 디자인 시스템 관리를 프로젝트 5개를 동시에 진행한다면:

• 화이트라벨 컴포넌트 라이브러리를 만들고,

• 각 프로젝트마다 스타일 가이드를 생성하며,

• 베리어블 이름을 동일하게 설정합니다.

• 그런 다음 Apply Variable 플러그인을 사용하면 동일한 이름의 베리어블을 한꺼번에 스왑할 수 있습니다.

• 이렇게 하면 프로젝트마다 컴포넌트 라이브러리를 만들 수 있습니다.

에이전시마다 다르지만 클라이언트가 만약 라이브러리와 스타일가이드를 요청하면 그 프로젝트 해당하는 것만 보내면 됩니다.

질문 주신 부분에 대해서 위와 같이 정리해보았는데, 혹시 추가 질문이 있으시면 언제든지 말씀해주세요.

볼드 드림.