Design Table 메모장(E1~E6)
개인적으로 다시 꺼내 듣고 싶은 부분들 모음
디자이너 팟캐스트 Design Table E1~E6을 들으며 간략하게 메모했던 부분들입니다.
좋은 말들이 많았지만, 특히 개인적으로 다시 회고하고 싶은 말이나 키워드들을 따로 모아봤습니다.
Design Table을 자세히 알고 싶은 분들은 아래 페이지에 가시면 상세한 내용들을 알 수 있습니다.
https://www.facebook.com/sharedesigntable/
*몇 회차에서 나온 말들인지는 따로 분류하지 않았습니다. E1~E6까지 들으며 메모했던 부분들입니다 :)
*순서는 일부러 섞었기에 에피소드 회차 순으로 나열되어있지 않습니다.
*들으면서 맥락만 맞춰 편하게 썼습니다.....ㅎ
디자인을 할 때 아웃풋만 보여주는 것이 아니라 내가 해결해야 하는 문제부터 파악하고 이걸 왜 해야 하는지에 대해 풀어가는 과정이 중요하다. 내가 이걸 왜 하는지 파악하는 과정 또한 중요하다.
이론적인 것보다 직접 경험하는 걸 선호한다.
어느 팀에 가든 그 팀이 푸는 문제 범위가 재밌어서 가는 게 이상적이다. 일도 일 같지 않고 작업하는 게 재밌게 느껴지는 것. 자발적으로 하면 더 신이 나고 기회가 생긴다.
디자인 하나에 완성도를 올리는 작업은 끝이 없는 일인데 초반에 이것에 포커스를 두고 몰입하면 큰 그림을 놓칠 수도 있다. 유저는 이제 비주얼에 감동하지 않고 경험이 쌓이고 쌓여 총체적인 경험에 감동한다.
코딩은 할 줄 몰라도 매체를 이해하는 건 중요하다. 요리는 못하지만 재료를 아는 것처럼.
Q. 코드 베이스 프로토타이핑을 많이 하고 있는데, 어떤 레벨까지만 만들 수 있고 그 이후로는 개발자에게 전달해도 무의미한 코드가 되는 게 이런 게 도움이 되는지?
A. 프로토타이핑을 코드 베이스로 한다는 것은 나중에 추가적으로 실제 구현을 할 때 개발자들이 조금 더 도움을 받을 수 있는 부분이 있다. 그 코드 자체를 쓸 수는 없지만 예를 들어 인터랙션에 들어가는 애니메이션의 로직들이 있는데 그것을 코드로 보는 것이 개발자 입장에선 명확하고 큰 도움이 된다.
또 구글 파이어베이스 같은 데이터를 활용한 프로토타입의 경우, 프로토타입으로 테스트를 하고 그 결과들을 가지고 프로덕션의 레벨에 들어갈 때 프로토타입에 대한 테스트 결과를 정량화할 필요가 있는데, 데이터 수집 단계에 큰 도움이 된다.(명확한 의사전달)
현업에서 윗선의 피드백 중요하지만, 자체적으로 걸러낼 줄도 알아야 한다. 윗사람이 하지 말라 했다고 그만둘 것이 아니라 자신의 소신을 가지고 판단해야 한다.
사용자에게 뭐가 좋냐고 물어보지 말고, 사람들이 행동하고 질문을 할 땐 누군가에게 비용을 지불하게 해야 한다. 사람이 선택하고 비용을 치르게 했을 때 그 사람의 진심을 유도할 수 있다.
Q. 개발자 입장에서 디자이너와의 커뮤니케이션
A. 예전에 이런 아티클을 읽은 적이 있는데 디자이너들은 발산적인 사고를 하고, 개발자 경우는 수렴적 사고를 하는데 많은 공감을 했다. 디자이너들은 문제 해결에 있어 다양한 대안을 내놓는 경우가 많고, 개발자들은 결국 이 문제들을 풀기 위해 그 대안들 중 하나를 선택해서 빨리 실행해서 검증을 하고자 한다. 이런 부분에 있어 빨리 결정해줬으면 좋겠지만, 다양한 대안을 제시만 하는 부분을 많이 느꼈다.
A2. 디자이너가 디자인 테스트를 습관적으로 많이 하는 편이다. 누가 봐도 명백한 답인 A가 있지만 계속 테스트를 하는 성향이 있다.(ex. 레이아웃 수정, 스케일 조정 같은)
일단 시도를 시작하면 기회가 생긴다.
구성원들이 이해도가 높았기에, '중요하다'라는 것을 설명하는 시간이 많이 들지 않았고, 어떻게 하면 잘할 수 있을까에 집중할 수 있었다.
제품을 만들 때 디자인은 일부일 뿐이다. 개발도 마찬가지다.
자기 제품에 대한 문제점을 스스로 찾고 건드려 보는 자세
Q. 새로운 툴을 사용하는 것에 대해서
A. 디자이너는 작업물을 개발자에게 넘기고 끝이 아니라 구현이라는 중간통로가 있는데 그런 통로 과정에서 효율을 높여주는 툴들이 많다.
맥락을 고려해서 빼야 할 건 빼는 것이 중요하다.
개인적으론 가용한 시간 안에 가능한 테스트를 다해보는 걸 선호하지는 않는다.
로우 피델리티로 빨리 의사결정을 하고, 나의 디자인 리소스를 활용하고 싶은데 팀 단위로 하나의 프로젝트를 하고 퀄리티를 올릴 때 이런 식으로 일이 진행되는 건 흔치 않았던 것 같다.
테스트를 위한 디벨롭을 많이 하는 편인 것 같다. A, B, C 안이 있다면 3개 모두 다 피넬리티를 높여서 작업하는 경향이 있다. (디자이너들 전반적으로)
완성이 덜된 안을 누군가에게 보여줄 때 생기는 자격지심 같은 것 때문이라 생각한다.
나는 일부로 여기까지 만든 건데, 타인이 보기엔 그것으로 나의 전체를 평가할까 봐에 대한 두려움.
마일스톤과 일정에 대한 개념보단 완성에 대한 집착.
작업을 하다 보면 동시다발적으로 더 나은 아이디어가 생기면 파생되는 시안들.
글 쓰는 건 생각 정리하기 위한 좋은 수단. 글 쓰기가 하나의 커뮤니케이션의 방법으로 커뮤니케이션 스킬을 키우는데 도움이 된다.
빠른 변화를 인정하고 받아들이는 자세
업계에 일을 하면서 전반적으로 비슷한 사람만 만나서 시각이 좁아질 수도 있다.
앞에서 편하면 뒤가 힘든 법이다. 사용자 경험을 해치고 싶어 하지는 않는 마인드가 중요하다.
사용자들의 1개의 편함을 위해, 100개의 수고를 해야 한다면 기꺼이 하겠다.
