Stephanie Walter의 스매싱 팟캐스트 에피소드 9: UI 프레임워크로 작업하려면 어떻게 해야 하나요?

개발자로서 내가 UI 프레임워크에 대해 좋아하는 것 중 하나는 기본 스타일이 함께 제공되는 경우가 많지만 이것이 프로젝트에서 의존해야 하는 것입니까? 단순히 기본 스타일을 사용하고 프레임워크를 만든 사람이 해당 구성 요소를 디자인하는 데 있어 정말 좋은 일을 했다고 믿으십니까? UI 프레임워크를 구축할 때 고려해야 할 사항에 대해 UX 디자이너 Stephanie Walter와 이야기하는 오늘의 팟캐스트 에피소드에 참여하세요.

메모 표시

• 스테파니의 웹사이트
• 트위터의 스테파니

주간 업데이트

• Anna Prenzel 의 "Angular 및 RxJS를 사용하여 카드 매칭 게임을 만드는 방법"
• Sarah Drasner 의 "JAMstack에서 헤드리스 WordPress 사이트를 만드는 방법"
• Dan Halliday 의 "Magic Flip Cards: 일반적인 크기 조정 문제 해결"
• Philip Kiely의 "Django 하이라이트: 사용자 모델 및 인증(1부)"
• Shajia Abidi의 "React와 전단지로 지도를 만드는 방법"

성적 증명서

Drew McLellan: 그녀는 사용자 중심의 디자이너이자 모바일 경험의 전문가로, 성능에 특별한 초점을 두고 유쾌한 제품과 인터페이스를 넘나들었습니다. 그녀는 룩셈부르크 대학교(University of Luxembourg), 유럽 투자 은행(European Investment Bank), BMW 및 Microsoft와 같은 고객을 위한 프로젝트에 참여했으며, 이러한 고객이 전략에서 최종 제품에 이르기까지 청중에게 성공적인 프로젝트를 전달할 수 있도록 돕습니다. 그녀는 제품 디자인 분야의 Google 개발자 전문가이자 열정적인 교사로서 수많은 블로그 게시물, 기사, 워크샵 및 컨퍼런스 프레젠테이션에서 자신의 지식을 공유하고 있습니다. 그래서 우리는 그녀가 전문 사용자 경험 디자이너라는 것을 압니다. 하지만 그녀가 한때 Elton John 경과 함께 카펫을 맞추는 일을 한 적이 있다는 것을 알고 계셨습니까? 내 Smashing 친구, Stephanie Walter를 환영하십시오. 안녕 스테파니, 잘 지내?

스테파니 월터: 안녕하세요. 소개가 너무 반가웠습니다.

Drew: 그래서 저는 오늘 특정 문제에 대해 이야기하고 싶었고 바로 기성품 사용자 인터페이스 프레임워크를 사용하는 주제였습니다. 이제 당신은 사용자 경험 디자이너이고 다양한 클라이언트와 함께 일하고 있으며, 당신의 임무는 이러한 클라이언트가 매우 유용한 사용자 인터페이스를 제작하여 가능한 최고의 사용자 경험을 만들 수 있도록 돕는 것입니다. 따라서 기성품 도구 세트로 그렇게 할 수 있다는 아이디어는 나에게 약간의 확장처럼 보입니다. 작업 전반에 걸쳐 UI 프레임워크를 사용하는 것이 많이 보입니까?

스테파니: 예, 특히 지난 몇 년 동안 내가 에이전시에서 일하기 시작했고 지금은 회사에서 일하기 때문에 많이 본 것입니다. 그래서 그 초대형 IT 기술 팀과 예, 현재 내가 가장 많이 본 것과 같은 프레임워크 UI가 많이 있습니다. Material-UI입니다. 기본적으로 Material 디자인은 Google 디자인의 일종의 가이드라인이자 사물이고 Material -UI는 Angular의 팀이지만 React의 팀이기도 합니다. 그들은 Google의 머티리얼 디자인의 모양과 느낌을 사용하여 자체 프레임워크를 만들었습니다. 그러나 그것은 더 이상 구글과 관련이 없습니다. 잘 모르겠지만 외모와 느낌을 좋아했던 것 같아요. 그래서 현재 제가 작업하는 두 가지 주요 UI 프레임워크입니다. 그리고 Ant Design이라는 것이 꽤 인기를 얻었습니다.

Stephanie: React 프레임워크입니다. Angular도 있는지 모르겠습니다. 중국팀에서 만든거 같은데 구성 요소, React의 모든 것을 제공할 뿐만 아니라 웹 사이트에 가면 스크래치 파일도 얻을 수 있기 때문에 흥미롭습니다. 이는 디자이너가 빌드하거나 모양을 만들거나 만드는 데 동기를 부여하거나 도움을 주기 때문에 실제로 매우 흥미롭습니다. 해당 프레임워크에서 사용하는 UI 구성 요소에 대한 인터페이스입니다. 예, 특히 대규모 IT 팀에서 대부분의 경우 디자이너가 없기 때문에 많이 본 것입니다. 현재 저는 기본적으로 유럽 투자 은행의 소규모 팀 중 하나인 UX 팀입니다. 그래서 저는 UX 디자이너입니다. 저는 개발자, 비즈니스 분석가, 좋은 사람들로 구성된 팀과 함께 일하지만 여전히 전체 프로젝트에 대해 한 명의 디자이너입니다.

스테파니: 제가 도착하기 전까지는 디자이너가 없었습니다. 따라서 많은 회사, 특히 예를 들어 내부 제품에 구현된 일종의 솔루션입니다. 그들이 일반적으로 말하는 것처럼, 우리는 그것에 대해 디자이너가 필요하지 않습니다. 내부 사용자를 위해 작동하는 것이 필요하고 개발자에게 편리하기 때문에 프레임워크를 사용하겠습니다. 대부분의 구성 요소는 이미 존재하고 팀에 디자이너가 없기 때문에 UI 디자이너의 역할을 대체하는 것과 같습니다. 네, 문제는 구성 요소가 있지만 UI 디자이너의 역할은 버튼이 빨간색, 녹색, 주황색, 파란색 등 무엇이든 결정하는 것만이 아니라는 것입니다. 일반적으로 UI 디자이너의 역할은 사용자 요구를 이해하는 정보 아키텍처입니다. 인터페이스를 넘어서는 모든 것. 따라서 전체 UI를 처리하는 이러한 종류의 프레임워크가 있더라도 화면에 보이는 것을 시각적으로 표시합니다.

스테파니: 여전히 우리가 화면에 무엇을 표시할지 이해하는 작업을 수행할 누군가가 필요합니다. 어떻게 작동할까요? 여기를 클릭하면 어떻게 됩니까? 사용자는 어떻게 목표를 달성합니까? A 지점에서 B 지점으로 어떻게 가나요? 모델을 사용할 수 있기 때문에 탭을 사용할 수 있고 모든 구성 요소를 사용할 수 있습니다. 그래서 항상 조금 복잡하고 까다롭습니다.

Drew: 가능합니까? 기성 UI 프레임워크를 사용하여 사용 가능한 사용자 인터페이스를 만들 수 있다고 생각합니까, 아니면 항상 약간의 타협이 있을 것입니까?

스테파니: 그렇게 되기를 바랍니다. 그렇지 않으면 사용할 수 없는 인터페이스를 구축하고 있기 때문에 희망합니다. 그래서 이 대답은 완전히 편향되어 있습니다. 하지만 그렇습니다. 제 생각에는 그렇습니다. 그러나 그것은 또한 당신이 기꺼이 하고자 하는 타협의 수준에 달려 있고 양측에 타협이 있습니다. 예를 들어 지금은 Material-UI에 아주 특정한 버튼이 있고 버튼의 파급 효과가 별로 마음에 들지 않기 때문에 많은 버튼을 타협하고 있습니다. 모바일에서는 사용자가 버튼을 클릭하거나 터치할 때 일종의 큰 피드백이 필요하기 때문에 모바일에서 잘 작동한다고 생각합니다. 그러나 단계는 버튼 전체에 영향을 미치는 일종의 파급 효과입니다. 특히 버튼이 많을 때 약간 과도합니다. 그러나 여전히 우리는 이 파급 효과를 유지할 것입니다. 왜냐하면 이것이 React 프레임워크에 내장되어 있기 때문에 제거하는 것이 매우 복잡하기 때문입니다. 그리고 이 버튼에 또 다른 호버 효과를 주기 위해 여기에서는 이런 종류의 우스꽝스러운 것이 아닌 더 미묘한 것입니다. 엄청나게 복잡할 것입니다.

Stephanie: 이것이 당신이 하는 일종의 타협입니다. 그러나 그 동안 나는 사용자 정의 구성 요소인 특정 항목에 대해 타협하지 않습니다. 이전에 일했던 곳에서 현재 여행 및 항공사 회사의 고객입니다. 그리고 항공사에는 정말 아주 특별한 요구 사항이 있습니다. 예를 들어 항공사의 달력은 가격을 넣고 싶고, 넣고 싶고… 특정 날짜에 이 목적지로 여행하지 않으면 언제 넣어야 할지 모르겠고, 이 출발과 도착이 있고 대부분의 UI 프레임워크의 기본 달력은 이러한 종류의 기능을 제공하지 않습니다. 그래서 어느 시점에서 당신은 말할 수 있습니다. 알았어, 우리는 그들이 가지고 있는 달력을 사용할 것입니다. 그리고 그게 다야. 당신은 그 이상으로 갈 필요가 있습니다. 따라서 대부분의 절충안은 기본적으로 구축되어 있습니다. 기본 구성 요소를 사용합니까? 사용자의 요구에 맞는 맞춤형 제품을 만들 수 있습니까? 아니면 둘을 섞어서 만들까요? 예를 들어 캘린더의 경우 캘린더 그리드를 사용하기 때문에 기본 컴포넌트를 사용하고 그 위에 커스터마이징을 추가하여 기능을 향상시켰습니다. 그래서 그것에 대한 React 개발이 많았습니다.

Stephanie: 네, 그래서 보통 타협을 많이 합니다.

Drew: 그래서 사용자 인터페이스 프레임워크를 사용하면 어느 정도는 얻을 수 있는 것처럼 들리지만 결과적으로 좋은 사용자 인터페이스를 얻으려면 맨 위에 꽤 많은 사용자 지정 작업을 수행해야 합니까?

스테파니: 보통. 응.

Drew: 그 커스터마이징이 테마를 넘어선 것입니까?

스테파니: 네, 제 개발자는 주제를 넘지 않기를 바랐습니다. 내 말을 들으면 유진. 나는 우리가 모든 것에 몇 가지 색상을 바꾸면 그가 매우 기뻐할 것이라고 생각합니다. 그러나 예, 어느 시점에서는 사용자 정의를 넘어서야 합니다. 왜냐하면 먼저 UI 프레임워크와 같은 레고 도구는 일종의 도구 상자이기 때문입니다. 따라서 상자에 다양한 구성 요소가 있지만 페이지가 구성되지는 않습니다. 여전히 머리글이 필요하고 바닥글이 필요합니다. 프레임워크에 없는 추가 콘텐츠가 여전히 필요합니다. 따라서 때로는 구성 요소를 필요한 것으로 조정할 수 있습니다. 내가 이해한 바에 따르면 우리는 카드 구성 요소를 사용하여 모달 창을 만들고 있지만 모달 창을 사용하는 것은 실제로 카드처럼 작동하지 않는다는 것입니다.

스테파니: 당신은 그것보다 조금 더 나아가고 있습니다. 모호한 배경이 필요합니다. 일반적으로 카드가 인터페이스에 이미 있는 동안 클릭 시 트리거해야 합니다. 그래서 우리는 이 카드 구성 요소를 사용하고 있습니다. 배경, 상단의 헤더 및 제목, 하단의 일부 버튼과 같이 필요한 것이 많기 때문입니다. 그래서 우리는 구조를 가지고 있고 우리는 그것을 약간 조정합니다. 그러나 때로는 의미론, HTML에 대해서도 충돌이 발생합니다. 예를 들어 버튼 모양이 없는 버튼을 원했기 때문에 링크 버튼과 개발자가 "좋아, 그래서 우리는 href 링크와 같은 링크를 사용합니다."라고 말했습니다. 나는 "아니요, 이것은 링크가 아닙니다. 버튼입니다. 클릭하면 새 페이지가 열리지 않습니다. 형식에 있는 모든 것을 지웁니다."

Stephanie: 기술적으로 의미론적 관점에서 볼 때 버튼이어야 합니다. "응. 하지만 프레임워크에는 존재하지 않습니다.” 나는 "그래 알았어, 그래서 우리는 무엇을 할까?"라고 말합니다. 그래서 일반적으로 이러한 작은 것들에 대해 논의하기 시작합니다. 그리고 제가 개발자들에게 접근성에 대해 정말 짜증나게 하기 때문에 이것은 그들이 잘 작동하는 기본 구성 요소가 있는지 확인하기 위한 또 다른 추가 레이어입니다. 그러나 의미상으로 gif 안에 gif 안에 gif가 있는 버튼을 갖고 싶지 않다는 것입니다. 그렇지 않으면 결국 문제가 발생합니다.

Drew: UI 프레임워크를 사용할 새 프로젝트를 시작하려면 일종의 사용자 조사부터 시작해야 할 것 같습니다.

스테파니: 네.

드류: 그게 공정한가요?

스테파니: 그래야 합니다. 당신은해야합니다. 예, 일반적으로 원하는 모든 구성 요소를 가질 수 있습니다. 사용자가 페이지에서 무엇을 필요로 하는지, 어떻게 탐색할 것인지 여전히 알아야 합니다. 흐름을 구축해야 합니다. 그래서 일반적으로 프레임워크를 결정하기 전에 우리가 하는 일은 사용자에게 가서 이야기하고 그들의 요구를 이해하려고 노력하는 것입니다. 따라서 현재로서는 사용자가 은행 내부에 있기 때문에 매우 운이 좋습니다. 그래서 우리는 그들과 함께 많은 워크샵을 하고 당신은 그것이 매우 복잡한 인터페이스라고 상상해야 합니다. 우리는 10년 또는 15년 전에 만들어진 것에서 Material-UI React를 사용하여 완전히 새로운 반짝이는 것으로 마이그레이션하고 있습니다. 따라서 이는 상당히 큰 변화이며 그 15년 동안 무언가를 원하는 모든 사람이 지원을 받은 다음 IT 팀에 구현을 요청할 수 있다는 것을 이해해야 합니다. 그래서 현재 내 인터페이스는 테이블, 테이블 내, 테이블 내, 다른 테이블 및 테이블에 있어서는 안되는 항목이 있는 400페이지와 같습니다.

Stephanie: 키 값, 키 값, 키 값인 많은 것들이 있는 것처럼. 그래서 그들은 두 개의 열이 있는 테이블을 만듭니다. 저는 "아니요, 어쩌면 우리가 그것으로 더 나은 것을 할 수 있을지도 모릅니다."라고 생각합니다. 그래서 현재 우리가 하고 있는 일은 사용자의 다양한 목표를 이해하기 위해 사용자 연구를 수행하는 것입니다. 그래서 우리가 식별한 것은 그들이 인터페이스로 하는 일에는 몇 가지 계획 목표가 있다는 것입니다. 그들은 일을 계획해야 합니다. 그래서 나는 이 작업이 이 회의에 갈 것이라는 것을 알고 싶습니다. 그래서 그 일정에 그런 것이 필요합니다. 그들은 사물을 모니터링하고 데이터를 보고하기를 원합니다. 따라서 모니터링은 데이터를 보고 모든 것이 정상인지 확인하는 것과 같습니다. 보고는 데이터를 활용하여 공유하고 싶은 작업을 수행하고 동료와 일종의 공동 작업을 수행할 수 있으며 사용자와 직접 토론하여 발견한 모든 것입니다.

Stephanie: 그리고 우리가 발견한 것은 실제로 우리가 마지막에 마이그레이션할 계획이었던 것들 중 일부가 사용자에게 일상적으로 가장 중요한 것들 중 일부라는 것입니다. 따라서 planification 사용자 목표는 현재 가장 큰 목표 중 하나입니다. 그래서 우리는 정말 정말 열심히 노력하고 있습니다. 그래서 예, 우리는 인터뷰를 사용하고 지금 우리는 쉘을 빌드해야 하고 탐색을 이해해야 한다고 말하는 매우 높은 수준의 단계에 있습니다. 그러나 현재 우리는 모든 데이터를 검토하지 않았으며 이것이 이제 우리가 할 일입니다. 우리는 많은 테이블을 가지고 있기 때문에 흥미롭습니다. 우리는 현명하지 않은 방식으로 가서 테이블을 새 인터페이스에 넣으면 끝납니다. 또는 다음과 같이 말할 수 있습니다. 이러한 테이블은 사용자가 이 테이블을 사용하는 용도입니다.

Stephanie: 그런 다음 일부 테이블을 데이터 시각화로 표시할 수 있습니다. 그렇게 하려면 전체 비즈니스를 이해해야 데이터가 이해될 수 있습니다. 좋은 프레임워크가 있고 이 차트를 사용해보자고 하면... 차트 JS 프레임워크라고 생각합니다. 많은 것들이 있고 히스토그램, 파이 차트, 그래프 등 모든 것을 가질 수 있지만 어느 시점에서는 여전히 결정을 도와줄 디자이너가 필요합니다. 좋습니다. 이 데이터를 그래프로 표시하는 것이 말이 됩니까 아니면 전체의 일부를 표시하기를 원하기 때문에 파이로 표시하는 것이 더 합리적입니까, 아니면 지난 10개 국가의 진화를 비교하고 싶습니까? 몇 년이 지나면 히스토그램이 더 흥미로워집니다. 따라서 사용자가 데이터로 수행하려는 작업에 따라 완전히 다른 방식으로 데이터를 표시합니다.

Stephanie: 그리고 일반적으로 그렇게 하는 것은 개발자 일이 아닙니다. 우리 개발자, 그들은 매우 똑똑한 사람입니다. 죄송합니다. 저는 솔직히 남자 개발자들과 일하고 있습니다. 여자가 몇 명 있었으면 좋겠지만 없습니다. 그들 중 누구도 여성이 아닙니다. 그래서 아주 똑똑한 사람들이지만 그들은 말할 자격이 없습니다. 좋아요, 이 데이터는 이렇게 표시되어야 합니다. 따라서 결국에는 일부 디자이너가 사용자와 이야기하고 데이터로 무엇을 할 수 있는지 이해해야 하며 이는 단순히 탭 표시줄이거나 왼쪽에 탐색이 되어야 한다고 말하는 것 이상입니다.

Drew: 그리고 사용자들과의 대화를 바탕으로 그런 종류의 결정을 내린 후에요. 예를 들어 사용자가 선택한 차트 유형을 이해하는지 확인하기 위해 일반적으로 결과 프로토타입이나 디자인을 사용자에게 다시 가져와 테스트하시겠습니까?

스테파니: 예, 실제로 많이 했습니다. 유용하고 사용할 수 있다는 것을 알게 될 때까지 개발하지 않기 때문에 정말 좋습니다. 그래서 그것은 달려 있습니다. 이미 대부분의 구성 요소가 있기 때문에 실제로 개발하는 것이 더 빠르다면 제가 보통 하는 일은 정말 빠른 종이 프로토타이핑을 한 다음 데이터가 없어도 빠르기 때문에 개발하는 것입니다. 개발하는 데 많은 시간이 소요되는 복잡하고 정말 새로운 것이라면 우리는 "좋아, 우리는 몇 개의 화면을 디자인하고 화면에서 직접 몇 가지 테스트를 한다"고 말합니다. 그래서 우리는 InVision이라는 도구를 가지고 있습니다. 기본적으로 모든 디자인을 넣고 다른 부분 사이에 링크를 만들 수 있습니다. 문제는 또한 테스트하려는 항목에 달려 있다는 것입니다. 예를 들어 전화기를 테스트하려는 경우 사람들이 전화기를 실제로 느낄 수 없고 특히 휴대폰에서 InVision을 테스트하는 것은 악몽입니다.

Stephanie: 그래서 항상 똑똑한 편입니다. 가장 빠르고 저렴한 방법은 무엇입니까? 디자인만 테스트하는 것이 더 빠르고 저렴합니까? 이것이 충분하나요? 일반적으로 양식의 경우 실제로 사용자가 양식을 채우도록 하는 프론트 엔드에 가한 모든 무거운 작업을 자동으로 완료하기 때문이 아니라 실제로 양식을 작성하고 테스트하는 것이 더 효율적일 수 있습니다. 하지만 새로운 것을 위해 우리는 많은 디자인을 합니다. 우리는 사용자에게 간다. 그래서 지금은 1:1 둘 중 하나를 하고 있지만, 제 유저들은 정말 바쁜 사람들입니다. 유럽 ​​투자은행이라 시간이 많지 않습니다. 그래서 우리가 보통 하는 일은 사용자들과 일대일로 오면 포커스 그룹과 같은 소규모 회의를 하는 것입니다. 그리고 때때로 대결을 하기 때문에 흥미롭기도 합니다. 어떤 사람들은 "네, 제가 이런 저런 일을 하기 때문에 효과가 있는 것 같아요."라고 말하고 다른 사람들은 "아, 너도 그렇게 일하니? 사실 아니요, 그런 식으로 해요.”

Stephanie: 그래서 방에 몇 사람이 모여서 대화를 듣고 메모를 하고 "오, 그러면 우리도 할 수 있겠네요", "이 구성 요소는 내가 방금 말한 것을 기반으로 하면 더 좋을 것입니다. 들었다." 그리고 그런 것들.

Drew: 귀하의 제품에 대해 보다 일반적인 청중과 함께 작업하는 경우. 그래서 아마도 당신과 같은 내부 사용자가 아니라 일반 대중에게 디자이너가 연구를 활용할 수 있는 저렴한 방법이 있습니까? 사용자가 누구인지 직접 알 수 없는 경우 더 쉬운 방법이 있습니까?

Stephanie: 제품을 만들기 전에 마케팅 담당자가 하는 일을 하지 않으면 그들이 누구인지 알아야 합니다. 그러나 예, 예를 들어 몇 가지 게릴라 사용자 테스트를 수행했습니다. 예를 들어 InVision을 계속 사용할 수 있습니다. 예를 들어 InVision에서 프로토타입을 만든 다음 소셜 미디어를 통해 사용자를 모집할 수 있습니다. 나는 도움이 되는 제품을 위해 일하고 있었습니다. 이름이 무엇인지, 자동차 대리점 정비공은 물건을 수리한 다음 추가 수리에 대해 고객에게 알리기 위해 그와 같은 일을 했습니다. 그래서 우리는 이미 링크드인과 페이스북에서 일종의 성장하는 커뮤니티를 갖고 있었습니다. 그래서 당신이 할 수 있는 것은 그 사람들을 모집할 수 있다는 것입니다. 온라인 도구와 같은 도구에서 대화를 나누는 것처럼 원격 테스트를 수행할 수 있습니다. 화면 공유를 할 수 있습니다. 그래서 우리는 일부 프로젝트에서도 그렇게 했습니다.

Stephanie: 이전에 도구를 테스트하라는 한 가지 조언을 드리고 싶습니다. 저는 이 도구를 사용하고 있었기 때문에 이 도구를 출현했습니다. 하지만 이름을 Whereby 또는 기타로 변경했다고 생각합니다. 하지만 내가 말한 것은 정말 브라우저에 있습니다. 좋아요. 그러면 사용자가 아무 것도 설치할 필요가 없지만 사용자가 실제 컴퓨터에 있지 않기 때문에 좋습니다. 그들은 VM, Citrix에 있었고 마이크가 없었기 때문에 우리가 한 일은 마치 그들이 내 도구를 사용하여 화면을 공유하는 것과 같았습니다. 그들은 프로토타입을 클릭하고 있었고 동시에 유선 전화처럼 전화로 직접 이야기하도록 했습니다. 그래서 항상 있습니다. 모집하기 좋은 날이었기 때문에 이것은 매우 저렴했습니다. 제 생각에 우리는 사용자가 10명 정도였던 것 같습니다. 네, 직접 대면할 수 없어도 많은 일을 할 수 있습니다. 저는 Skype에서 직접 사용성 테스트를 많이 했습니다. 그래서 항상 그것을 할 수있는 몇 가지 저렴한 방법이 있습니다.

Drew: 작업할 UI 프레임워크를 선택할 때 그것이 당신이 가고자 하는 경로라면 개발자에게만 맡기는 것입니까 아니면 디자이너도 참여해야 하는 것입니까?

스테파니: 저를 위해서는 전체 팀을 참여시켜야 합니다. 설계자, 개발자, 아키텍트가 있는 경우 설계자와 마찬가지로 프레임워크가 구축되는 방식도 이러한 종류에 영향을 미칠 수 있기 때문입니다. 불행히도 대부분의 경우 그들이 프로젝트에 도착했을 때 프레임워크는 이미 결정되었습니다. 아니요, 사실 재미있습니다. 이미 결정되었거나 프레임워크 선택을 확인하도록 요청했지만 검토나 조사는 하지 않았습니다. 그들이 나에게 그들의 화면을 보여주지 않았기 때문에 나는 프로젝트에 무엇이 있는지 전혀 모릅니다. 그들은 "예, 당신의 일을하십시오. 우리는 이 프레임워크를 사용할 수 있습니다.” 모르겠어요. 글쎄, 우리에게 화면이 있습니까? 그래서 그들은 클라우드에서 마이그레이션하려는 Windows 기본 앱인 몇 개의 화면을 보여주었습니다. 그들은 "예, 우리는 버튼만 필요하고 대부분 양식과 같은 것을 좋아합니다."라고 말했습니다.

Stephanie: 하지만 "예, 이 프레임워크로 이동하세요. 필요한 구성 요소가 모두 있습니다."라고 말하기는 어렵습니다. 또는 "콘텐츠가 무엇인지, 탐색이 무엇인지에 대한 대략적인 아이디어가 없으면 가지 마세요." 따라서 모든 구성 요소가 있는지 100% 확신하지 않는 한 프레임워크를 선택하기 전에 전체적인 개요가 있어야 한다고 생각합니다. 그러나 대부분의 경우 프레임워크 선택은 기본적으로 현재 개발자가 어떤 기술을 좋아하는지에 따라 결정됩니다. 그 이전에 프레임워크에 대한 경험이 있습니까? 우리는 일부 프로젝트에서 Ant를 사용한 경험이 있는 소수의 개발자가 Ant를 정말 좋아했고 Ant를 효율적으로 사용했기 때문입니다. Material React UI의 경우에도 동일합니다. 개발자가 이미 이전 프로젝트에서 사용했기 때문에 효율적입니다.

Drew: 따라서 실제로 개발자가 편안하게 느끼는 것, 그들이 알고 있는 것, 기술 스택과 함께 작동할 것, 그리고 좋은 사용자 인터페이스를 만드는 측면에서 제품의 요구 사항이 무엇인지 사이에서 균형을 잡아야 합니다. 그리고 이상적인 프레임워크를 찾기 위해 이 둘의 균형을 어떻게든 해야 합니다.

스테파니: 네. 나는 어떤 프로젝트에 대한 일종의 특정 요구 사항이 있습니다. 저는 ... 저는 룩셈부르크에 있습니다. 우리는 많은 유럽 기관과 그와 같은 것을 가지고 있습니다. 그래서 우리는 그 중 일부에 대한 추가 접근성 요구 사항이 있습니다. 그리고 일반적으로 프레임워크가 결정될 때 프레임워크의 접근성에 대해 실제로 확인하지 않고 프로젝트가 시작된 후 몇 달 후에 다시 돌아와서 "아, 방금 이 새로운 법률이 있다고 말했고 우리는 액세스할 수 있지만 어떻게 해야 할지 모르겠습니다.” 예, 조금 늦었습니다. 따라서 저에게 프레임워크를 선택하려면 프로젝트 시작 시 모든 제약 조건을 알아야 하고 접근성이 그 중 하나인 경우 구성 요소를 테스트하고 액세스할 수 있는지 확인해야 합니다. 하지만 저는 React나 Angular 개발자는 아니지만 액세스할 수 없는 UI 프레임워크를 액세스 가능한 것으로 바꾸는 것은 매우 복잡하다고 확신합니다. 모든 구성 요소를 다시 빌드하는 것은 약간 복잡할 수 있습니다. 그런 식으로 말이죠.

Drew: 해당 프로세스가 수행되지 않고 UI 프레임워크가 이미 선택된 프로젝트에서 작업하고 있는 자신을 발견하면 사용자 인터페이스가 해당 프레임워크에 이미 존재하는 구성 요소가 아니라 해당 프레임워크에 영향을 받을 위험이 있습니까? 사용자의 요구에 의해 주도되고 있습니까?

Stephanie: 정말, 솔직히 말해서, 제가 작업한 대부분의 프로젝트는 결국 밀어붙이려고 해도 결국에는 많은 상충 관계를 갖게 됩니다. 그래서 그것은 대부분 균형에 관한 것이고 개발자들과 논의하는 것입니다. 그래서 보통 제가 하는 일은 와이어 프레임, 심지어 빠른 종이 와이어 프레임까지 하는 것입니다. 이 페이지에서 저와 저 구성 요소가 필요할 것입니다. 가장 먼저 하는 일은 개발자에게 우리가 그것을 가지고 있는지 묻는 것입니다. 현재 프레임워크? 어떻게 생겼나요? 그런 다음 우리는 함께 결정합니다. 알겠습니다. 이것은 작업을 수행할 구성 요소인지 아니면 작업을 수행하지 않을 구성 요소인지입니다. 우리가 그것을 조정합니까? 우리는 여전히 구성 요소를 유지하지만 작업을 수행하도록 약간 변경합니까, 아니면 처음부터 무언가를 구축합니까?

Stephanie: 그리고 결국에는 예산에 따라 달라질 것입니다. 그래서 결국 트레이드 오프를 했습니다. 내가 완벽하지 않고 몇 가지 문제가 있는 경우 거의 사용되지 않는 작은 구성 요소에 대해 괜찮을 것입니다. 그러나 기본 탐색, 기본 구조, 예를 들어 화면에서 항상 보는 것들의 경우 이것이 실제로 작동해야 합니다. 사용자가 효율적으로 작동하는 방식을 이해해야 하며, 예, 말씀하신 대로 프레임워크가 없는 경우 원하는 이상적인 경험과 현재 보유하고 있는 것, 예산 및 타이밍. 만약 우리가 이 스프린트의 경우 기능은 이 스프린트가 끝날 때 완료되어야 한다고 말하고 그들은 말합니다. 하지만 구성 요소를 원하면 이 스프린트가 끝날 때 기능을 끝내지 않을 것입니다. 토론을 시작합니다. 알겠습니다. 다음 화면에서 이 기능을 끝낼까요? 제대로 하려면 시간이 더 걸릴까요? 그리고 일반적으로 그것은 정말로 달려 있습니다.

Stephanie: 저를 가장 좌절하게 하는 것은 우리가 자르기 수정 구성 요소를 사용한다는 것을 알고 그들이 저에게 "아, 걱정 마세요."라고 말할 때입니다. 나중에 수정하겠습니다. 그리고 나중에 불행하게도 그런 일은 결코 일어나지 않을 수도 있다는 것을 알고 있었습니다. 따라서 팀에 따라 다릅니다. 그러나 잠시 후에 경험을 하고 이것이 나중에 도착할 것인지, 그렇지 않을 것인지 알 것입니다. 예, 타협에 관한 것입니다. 이러한 종류의 도구로 작업할 때.

Drew: 개발자로서 UI 프레임워크에 대해 좋아하는 것 중 하나는 기본 스타일이 함께 제공되는 경우가 많다는 것입니다. 따라서 모든 구성 요소의 모양과 느낌을 도와줄 디자이너가 반드시 필요하지는 않습니다. 그것이 우리가 프로젝트에 의존해야 하는 것입니까? 프레임워크를 만든 사람이 구성 요소를 디자인하는 데 정말 좋은 일을 해냈다는 기본 스타일과 신뢰입니까? 아니면 해당 구성 요소의 스타일을 직접 지정하시겠습니까?

스테파니: 나는 그것이 정말로 달려 있다고 생각합니다. 예를 들어 Material-UI의 문제는 웹 앱의 모양과 느낌이 기본적으로 구성된 Google 제품이라는 것입니다. 따라서 실제로 글꼴을 변경하지 않고 몇 가지 색상을 변경하고 자신의 브랜드 아이덴티티를 가져와 그렇게 하면 모든 Google 제품처럼 보이는 제품을 갖게 됩니다. 사용자가 Google 제품에 익숙하므로 이해하는 데 도움이 될 수 있습니다. 그래서 보통 팀에 디자이너가 없다면 선택의 여지가 있습니까? 내가 본 많은 다른 작업과 마찬가지로 사용자 정의 테마와 함께 제공되므로 최소한 색상을 변경할 수 있습니다. 글꼴도 꽤 쉽게 변경할 수 있다고 생각합니다. 그러나 다시 말하지만, 색상을 변경하고 디자인이나 접근성에 능숙하지 않은 경우 사용할 색상이 충돌하고 대비 문제가 있을 수 있습니다.

Stephanie: 예를 들어, 저는 주황색을 좋아하지만 작업하기 가장 성가신 색상 중 하나입니다. 예를 들어 흰색 텍스트가 있는 버튼과 같이 주황색이 거의 갈색으로 보이기 때문에 실제로 액세스할 수 있는 주황색을 사용하기 때문입니다. 그리고 이 정말 빛나는 오렌지를 갖고 싶다면 읽을 수 있도록 그 위에 어두운 텍스트가 필요하지만 하루가 끝나면 인터페이스가 할로윈처럼 보이게 만듭니다. 네, 웃는 모습이 보이네요. 하지만 사실입니다. 그래서 항상 이런 종류의 타협에 관한 것입니다. 만약 당신이 개발자이고 프레임워크를 있는 그대로 사용하고 싶고 디자이너가 없다면 아무것도 없는 상태에서 처음부터 빌드하는 것보다 여전히 낫다고 생각합니다. 사용하기 매우 복잡합니다. 그러나 문제는 구성 요소가 있다고 해서 훌륭한 인터페이스를 구축할 수 있다는 의미는 아니라는 것입니다. 마치 레고 블록처럼 말이죠. 레고 브릭이 있다면 괜찮습니다. 하지만 정말 멋진 우주선을 만들 수도 있고, 계획이 없었기 때문에 서로 붙지 않고 무너질 수도 있는 일을 할 수도 있습니다.

Stephanie: 디자인은 그 이상입니다. 디자인은 화면에 표시될 내용과 작동 방식을 실제로 이해하는 것입니다. 그리고 실제로 그렇게 할 수 있는 능력이 있는 개발자를 알고 있습니다. 그래서 그들은 사용성 지침에 대해 정말 능숙하고 예를 들어 많은 디자인 규칙을 이해합니다. 따라서 구성 요소를 선택할 때 구성 요소는 정말 좋습니다. 그리고 어떤 구성 요소를 선택해야 하는지 모르고 작업을 수행하는 첫 번째 구성 요소를 선택하는 개발자를 알고 있습니다. 그러나 잠시 후 더 이상 작동하지 않습니다. 예를 들어 탭과 마찬가지로 일부 개발자가 탭을 선택하는 인터페이스가 있었습니다. 처음에는 아이템이 3개 밖에 없을 때 하는 것이 합리적이라고 생각합니다. 하지만 화면에는 12개의 항목이 있었고 3줄의 탭인 탭이 있습니다. 모두 같은 수준의 1단계 탭이고 탭 안에 탭이 있습니다. 그래서 그들은 구성 요소를 가지고 있었고 프레임 워크를 사용하기 때문에 멋지게 보이지만 실제로 사용할 수는 없었습니다.

Stephanie: 그리고 예를 들어 모달 창과 같은 것을 사용했습니다. 디자이너 없이 프로젝트를 빌드하는 곳에서 잠시 후 클라이언트가 이 모달에 점점 더 많은 것을 요구했다고 생각합니다. 그래서 그들은 테이블이 있는 화면으로 끝났고 행 추가를 클릭하면 모달을 열 수 있습니다. 이 모달에는 두 개의 탭이 있고 그 중 하나에는 다른 테이블이 있습니다. 여기에 추가 항목을 추가하면 모달 위에 모달을 추가할 수 있을 것 같습니다. 그리고 어느 시점에서 디자이너는 모달에 그렇게 많은 콘텐츠가 있다면 모달 창이 아니어야 한다고 대답할 것입니다. 페이지여야 합니다. 따라서 구성 요소가 있더라도 계획을 수행하고 모든 구성 요소가 함께 잘 작동하는지 확인하려면 일종의 설계자가 필요합니다.

Drew: 디자이너로서 일부 구성 요소의 스타일을 변경하라는 요청을 받는 경우 모든 스타일을 변경하려고 합니까? 모든 것을 사용자 정의하시겠습니까? 아니면 집중할 특정 영역이 있습니까?

스테파니: 색상 제 생각에 색상은 가장 먼저 보는 것이기 때문에 실제로 정체성을 부여할 수 있습니다. 강력한 브랜드 아이덴티티를 갖고 있다면 최소한 제품의 색상을 버튼이나 아이콘 등에 두는 것이 프레임워크를 사용자 정의하는 데 이미 도움이 됩니다. 글꼴은 쉽다고 생각하기 때문에 프레임워크가 잘 구축되어 있으면 일반적으로 전체 글꼴 모음을 어딘가에서 변경한 다음 사이트의 나머지 부분에서 일종의 계단식 배열이 되어야 합니다. 그래서 색상과 글꼴은 프레임워크를 빠르게 사용자 정의하는 두 가지 쉬운 방법이라고 생각합니다. 아이콘은 개성을 가져오는 또 다른 좋은 방법이지만 내가 본 바에 따르면 대부분의 프레임워크에는 사용자 정의 아이콘이나 Font Awesome 또는 이미 내장된 라이브러리와 같이 제공되기 때문에 어려울 수 있습니다. 따라서 이를 교체하려면 먼저 다음이 필요합니다. 아이콘을 모두 교체하려는 경우 아이콘이 많이 있습니다. 그래서 조금 복잡할 수도 있습니다. 사용하려는 아이콘 팩을 선택할 수 있는 프레임워크도 보았습니다. Font Awesome, Glyphicons 및 기타 일부와 같은 것입니다. 따라서 이것은 매우 쉽게 사용자 정의할 수 있는 종류입니다.

Stephanie: 그 다음은 모양과 느낌에 관한 것입니다. 예를 들어 머리글에는 일반적으로 다양한 종류의 머리글과 바닥글이 있습니다. 그런 것들을 어떻게 탐색합니까? 따라서 Material-UI-ish처럼 보이지 않도록 가져올 수 있는 작은 사용자 정의가 이미 많이 있으며, 귀하의 브랜드처럼 보이고 예를 들어 테두리 반경을 가지고 놀 수 있습니다. 완전히 둥근 버튼을 원하든, 사각형 버튼을 원하든, 그림자와 같은 중간 부분을 원하든. 따라서 대부분의 프레임워크가 CSS 변수에 포함되어 있기 때문에 일반적으로 쉽게 사용자 지정할 수 있는 몇 가지 작은 항목입니다. 이것은 이러한 파급 효과를 제외하고는 많은 노력 없이 사용자 정의할 수 있는 종류의 작은 것입니다. 싫어. 나는 그것을 싸울거야. 나는 그들이 결국 그것을 바꾸기를 바랍니다.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. 아세요?

Drew: Yup.

Stephanie: It does. 괜찮아. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.