소프트웨어 하우스에서 UX/UI 디자이너로 일한 첫해에 배운 11가지

소프트웨어 하우스에서 UX/UI 디자이너로 첫 직장을 시작한 지 사실 1년이 넘었습니다. 어떤 사람들은 프로젝트가 다양하고 독립성이 요구되기 때문에 UX/UI 경험을 시작하기에 가장 좋은 곳이 아니라고 생각하지만 저는 크게 문제가 되지 않았습니다. 나는 꽤 큰 스튜디오에서 건축 보조원으로 일했고 홍보 및 그래픽 디자인 분야의 학생 조직에서 "프리랜서"로 일했습니다.

그러나 햇빛과 무지개가 전부는 아니었습니다 . 리브랜딩 결정과 첫 직장 시작 사이에 4개월도 채 걸리지 않았고 그 결과 그 직책에 필요한 모든 영역을 배우고 이해하지 못했습니다. 일반적으로 후배들은 회사의 서로 다른 팀, 주로 프로젝트의 비즈니스 및 영업 부분 간의 협력의 중요성에 대해 많이 배우지 않습니다.

다음은 UX/UI 디자인에서 첫해에 만난 몇 가지 문제입니다.

1.MVP 및 KPI

이것은 내가 첫 프로젝트를 작업하면서 접한 거의 완전히 낯선 개념이었습니다. 물론 내부 프로젝트 였지만 작업은 캐주얼했고 모든 프로젝트 참여자에게 다양한 문제에 대해 물어볼 수있었습니다. 그때 비즈니스 분석가와 프로젝트에서 그들의 역할을 알게 되었습니다. 소프트웨어 하우스에서 제품의 가장 중요한 부분인 제품의 비즈니스 측면에 대해 배웠습니다. 이전 업계 경험이 있는 MVP와 KPI는 다른 이름으로 가려져 존재했을 수도 있지만 클라이언트와의 워크샵에서 실질적인 결정은 여기에서 경험한 것입니다.

2. 업무상 요구사항, 요구사항 수집, 고객과의 확인, 확인

제 생각에는 이것이 제품 디자이너의 작업에서 가장 필수적인 부분입니다. 회사에서 저는 부분적으로 또는 전적으로 요구 사항을 수집하고 클라이언트와 확인하는 책임을 졌습니다. 때로는 클라이언트의 구조에 부드럽게 침투하여 비즈니스 요구 사항을 수집한 비즈니스 분석가와 협력하기도 했습니다. 이 단계에서 클라이언트의 산업 및 프로세스에 대해 배우고, 클라이언트에게 우리가 이 작업을 수행하는 이유를 설명하고(모르는 경우) 실제로 설계 중인 제품에 대한 이 정보를 지속적으로 수집하는 것이 중요합니다. 나는 사용자 스토리와 수용 기준 및 잠재적 위험을 적어서 이렇게 했습니다. 고객 입장에서 우리에게 주문한 제품의 시각적인 측면은 이미 이 단계에서 중요하므로 이러한 요구 사항을 수집하는 가장 매력적인 형태는 중형 목업을 만드는 것입니다. 부분적으로 제안된 콘텐츠가 있는 모형. 이것은 제시될 수 있는 많은 제안 중 하나라는 것을 기억하는 것이 중요하므로 그러한 버전의 프로젝트에 첨부할 가치가 없습니다. 이 단계에서는 클라이언트가 요구 사항을 수집하고 확인하는 방법을 설정하여 정보 흐름의 명확성을 염두에 두어야 합니다. 이 단계를 닫지 않으면 잠재적인 위험(결정 변경 또는 프로젝트 일정에 영향을 미치는 새로운 요구 사항 추가)으로 인해 개발을 진행할 수 없습니다. 또한 우리는 제품을 생성하고 요구 사항을 수집하며 이미 문서를 수락하거나 개발하는 단계에 있으며 갑자기 비즈니스(예: 사용자)가 프로세스를 이해하지 못한다고 선언합니다.

3. 시간 추정 - 과소평가 또는 과대평가

사실 대부분의 시간은 목업 생성, 기존 라이브러리 사용자 정의 또는 사용자 정의 라이브러리 생성 및 문서 작성에 소요됩니다. 초보 디자이너가 이것에 소요될 시간을 예측하는 것은 종종 매우 어렵고 어떻게든 해야 합니다. 특정 작업에 소요되는 시간을 여러 번 과소평가했고 한 번은 과대평가하기도 했습니다. 하지만 제 생각에는 이 기술은 경험과 함께 제공됩니다. 그러한 상황에서 특정 시간 버퍼를 갖는 것이 좋습니다. 항상 늦게 전달하는 것보다 더 빨리 전달하는 것이 좋습니다.

4. 투구, 돛, 배 - 자립

내 경험상 지금까지 나는 호텔 객실과 복도 천장의 조정 설치 또는 이른바 Back of House 부품과 같은 프로젝트의 작은 측면만 제어하면 되었습니다. UX/UI 디자이너로서 첫 번째 프로젝트에 정식으로 배정된 후 프로젝트 팀의 유일한 디자이너였기 때문에 제품에 대한 책임이 훨씬 더 컸습니다. 한편으로 이것은 저에게 고상한 일이었지만 다른 한편으로는 회사의 많은 책임과 전반적인 신뢰였습니다. 지금까지는 저에게 잘 맞았는지 모르겠습니다. 아마도 업계 경험이 거의 없는 사람으로서 제품을 전적으로 책임지기에는 너무 이른 것 같습니다. 제게는 상당한 시험이었지만 클라이언트와 팀 모두 저에 대해 만족해 하셨기 때문에 결국 그 순간을 위해 이 프로젝트 작업을 잘 수행할 수 있었던 것 같습니다

5. UX 단계에서 연구, 오히려 그것의 부족

클라이언트는 디자인 단계에서 UX 리서치를 수행하는 시점에 대한 지식이 없는 경우가 많습니다(그렇다면 이러한 정보를 제공한 클라이언트에 대해 영업 부서에 감사하십시오!). 이것은 소프트웨어 하우스의 일반적인 단점입니다. 제품 회사에서, 모임과 컨퍼런스에서 나눈 대화를 통해 불행히도 이것이 디자인 프로세스에 관한 표준이 아니라는 것이 분명해졌습니다. 그럼에도 불구하고 클라이언트에게 UX 리서치에 대한 프리젠테이션을 수행하고 그것이 중요한 이유와 시간을 얼마나 절약할 수 있는지 제시하는 것은 항상 가치가 있습니다. 첫 번째 예는 비즈니스 프로세스가 이해하기 매우 복잡한 제품을 개발하고 있었는데 사용자가 잘 이해하지 못했기 때문입니다. 클라이언트와 함께 요구 사항 수집 단계로 돌아가야 했습니다. 프로세스에 대해 자세히 학습한 후 다시 수집하고 모형을 개선하고 개발을 계속합니다. 목업의 프로토타입을 만들고 미래의 사용자(클라이언트 팀 중 한 팀의 직원)와 함께 사용성 테스트를 수행할 시간이 있었다면 이런 일은 피할 수 있었을 것입니다. 그때에도 우리는 훨씬 나중에 나온 문제를 식별했을 것입니다.

6. 문서 작성

이것은 실제로 클라이언트가 확인하는 데 필요한 작업입니다. UX 문서 작성을 위해 문서 준비에 대한 Autentika의 자세한 문서를 사용했습니다(https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/폴란드어로).

그것을 만드는 데 매우 유용했지만 100% 충분하지는 않았습니다. 그 당시 내가 만들고 있던 제품의 프로세스 다이어그램은 매우 복잡했기 때문에 이유 때문에 분석가에게 갔고 그들의 도움을 받아 사용 사례 사양과 허용 기준이 있는 더 자세한 프로세스 요구 사항을 대신 만들었습니다. 물론 지금은 그런 문서화를 조금 더 다르게 하겠지만 그 시점에서는 꽤 만족스러웠습니다.

7. 방법론? 그들은 존재합니까?(아니요)

대부분의 소프트웨어 회사는 고객에게 개별적으로 접근하여 반복적으로 작업하려고 합니다. 특히 "시간이 없다"거나 유일한 디자이너로 일하기 때문에 기판 간 조사가 거의 수행되지 않기 때문에 이러한 상황에서 책 프로세스를 계획하는 것은 어렵습니다. 궁극적으로 설계 방법론은 Agile을 기반으로 하지만 프레임워크는 서로 상당히 유사하며 오히려 Discover, Define, Design, Develop 및 Delivery/Deploy 단계로 나눌 수 있습니다(Double Diamond의 단계가 포함된 확장된 5D). .

8. 고객에 대한 이해

이것이 애플리케이션 설계 수준에서 고객과의 협력의 핵심입니다. 종종 클라이언트(특히 비 IT 산업)는 UX가 무엇인지, UX가 무엇인지, 프로젝트의 첫 단계에서 제거할 수 있는 문제가 무엇인지 모릅니다. 내 경험의 좋은 예는 비즈니스 요구 사항을 완료하기 위해 lo-fi 목업을 제시했을 때입니다. 회의에는 lo-fi 목업의 디자인에 대해 매우 불확실한 클라이언트의 마케팅 팀도 포함되었습니다. 그것들이 모두 같은 페이지에 있지 않았기 때문에 목업은 기능과 제품이 어떻게 작동해야 하는지에 대해 이야기할 수 있는 기회일 뿐이라는 사실에 대해 다시 한 번 이야기했습니다. 불행히도 이것은 프로젝트의 그 시점에서 응용 프로그램의 디자인과 관련이 없는 목업에 사용된 서체에 대해 마케팅이 언급하는 것을 막지 못했습니다 . 결국, 주제는 상당히 빨리 해결되고 이해되었지만, 바로 되지 않았다는 사실은 UX에 대한 주제가 회사에서 완전히 알려지지 않았음을 나타냅니다. 디자인 단계의 맨 처음에 클라이언트에게 우리가 어떻게 작업하고, 무엇을 발표할 것인지, 클라이언트로부터 어느 정도 입력이 필요한지에 대한 논의와 함께 짧은 프리젠테이션을 할 가치가 있습니다. 그리고 물론 그것이 그에게 가치가 있는 이유입니다.

9. 개발자와 협력

종종 개발자는 솔루션과 관련하여 매우 좋은 정보를 제공하고 매우 기술적이고 논리적인 질문을 하므로 솔루션에 대해 생각해 볼 수 있는 좋은 주제가 된 경우가 많습니다. 그러나 때때로 그들은 그들에게 더 간단하고 사용자의 관점에서 반드시 좋지 않은 솔루션을 제안하므로 여기에서 변경을 제안할 가치가 있는 것과 변경을 중지하고 내린 결정을 설명할 가치가 있는 부분의 균형을 적절하게 유지해야 합니다.

10. API, JSON, LDAP, 오케스트레이터 및 기타 이상한 단어

이는 개발자와 전체 IT 커뮤니티가 사용하기 때문에 UX로서 알아야 하는 애플리케이션 개발의 핵심 개념입니다. 그들을 알게 되면 엔지니어와 더 잘 대화할 수 있을 것입니다. 당신은 모릅니다. 가급적이면 처음에 물어보십시오. 하지만 저에게는 이러한 개념에 대한 이해가 개발자가 만든 구현 문서를 검토한 후에야 이루어졌습니다. 응용 프로그램의 내부 통신 다이어그램을 통해 많은 것을 이해할 수 있었습니다 작동.

11. 스프린트 작업, 일일 프로젝트, 스프린트 계획 및 레트로(스펙)

그들은 프로젝트에서 일어나는 일을 완전히 제어할 수 있는 귀중한 회의입니다. 여기에서 프로젝트 관리자는 중요하며 필요할 때 개입합니다(예: 고객이 준비를 변경하려고 할 때). 우리가 민첩하게 작업하는 경우(거의 모든 프로젝트) 스크럼 마스터도 마찬가지입니다.

보시다시피 이것은 제가 IT에 입사했을 때 알게 된 많은 것들입니다. 이 목록이 흥미롭기를 바라며 이 목록이 UX/UI 경력을 고려하고 있거나 이 업계에서 일하는 사람들에게 도움이 될 것입니다!