엔지니어를 위한 커뮤니케이션 가이드
어느 훌륭한 소프트웨어 엔지니어 분께서 "모든 디자이너는 저를 싫어해요."라고 하셔서 깜짝 놀랐어요. 사례와 함께 정리한 팁을 정리했던 내용 공유합니다. 추상 클래스니까 잘 상속받아 구현해보시길!
- 좋은 디자이너는 보기 좋고 쓰기 편한 결과물을 선호함
- 좋은 디자이너는 다른 이를 만족시키면 행복해함
- 좋은 디자이너는 사람들의 곤란함을 해결하려 노력
- 우선 당신의 동료가 좋은 디자이너라고 가정
인어님, X 화면 iOS 기준 해상도에서 우측 잘립니다.
오전 중으로 좌측 패딩 줄여주세요.
- 엔지니어끼리는 가장 훌륭한 대화방식 (암요 암요)
- 문제+해결책만 전달 -> 로봇 같음
- 심지어 부적절한 해결책 -> 디자인을 알지 못하는 로봇
- 오전 중으로 -> 나를 쪼으는 디알못 로봇
인어님, '혹시' 오전 중으로
안드로이드에서 X 화면 '좀' 확인해주실 수 있나요?
- 이유를 되물을 만한 질문을 던져 문제 공유 시작
- "수정" 요청보다 "확인" 부탁이 좀 더 부드러움
- 부사 '혹시'와 '좀'은 다른 직군의 동료가 해결방안을 제시하는 입장에서 상대를 존중하는 뉘앙스를 줄 수 있음
oo님, 제가 X 화면을 확인해 봤는데요,
- 부정적인 상황은 얼굴을 보고 해결하는 것도 좋음
- 주어가 인간이면 좋음 (디자이너는 인간을 사랑함)
- 마음의 준비 1단계 - X 화면 관련 문제구나!
iOS에서는 다 잘 보이는 것 같은데
- 긍정적인 얘기로 시작. 사실이라고 생각해도 추측의 어미(~것 같은데)를 사용하면 덜 로봇 같음.
- 마음의 준비 2단계 - iOS 말고 다른 문제구나!
안드로이드에서 Y가 좀 잘릴 때가 있어요
- 설령 항상 그렇더라도 "~때가 있다"라고 말하면 부드러워 보임
- 엔지니어가 문제를 말하는 것부터 이미 스트레스 상황
- "좀": 문제가 있지만 나는 화나지 않았고 잘 대응하면 쉽게 넘어갈 수 있음을 암시 (디자이너는 당신의 감정이 궁금함)
- 상황을 잘 전달하면 디자이너가 스스로 해결책을 찾을 수 있음
- 적극적인 디자이너는 이 타이밍에 해결책을 먼저 제시할 수도 있음
~님이 오후에 ~ 작업을 하기로 해서
- 주어가 인간이면 좋습니다 (디자이너♡인간)
- 다른 이의 상황과 파급효과를 전달하는 것은 우선순위 결정과 동기부여에 영향
가급적 오전 중으로 수정해주시면 감사하겠습니다
- 담당 업무니까 당연히 해야 하는 것이 새삼스러울 수 있음
- 기왕이면 서로 감사한 마음을 갖고 표현하면 좋음
- 좋은 디자이너는 소중한 동료 인간을 곤경에 빠뜨리려 하지 않음
네, 이제 잘 보이네요. 감사합니다!
- 사실에 근거한 긍정의 피드백
- 빨리 완료되어서 / 시간을 잘 맞춰주어서 / 문제가 잘 해결되어서 + 감사합니다
- 효과: 피드백을 통해 '나의 작업이 팀에 도움이 되어서 뿌듯하다'라고 느낌
- 다음에도 인간들 (팀원과 사용자)의 만족을 위해 더 잘하고 싶음.
- 엔지니어 출신이 디자이너들을 리버스 엔지니어링 한 패턴
- 실전에서는 목소리 톤, 속도, 비언어적 표현도 관건
- 학습 샘플이 적어 개인차 있을 수 있음
- 사내 동료가 아닌 사외 외주는 짧고 명료한 소통을 선호할 수 있음
- 발화 양의 증가로 피로 증가 가능성
- 갑자기 바뀌면 무서움- 주어를 인간으로 바꾸는 것부터 단계적인 시도 권장
1. 주어를 인간으로
2. 해결책보다 문제 상황 설명
3. 맥락을 많이 공유할수록 좋음
4. 단정적이지 않은 추측성 어미 사용
5. 가급적 진심으로 감사 표현