프로젝트에 디자이너가없는 경우 개발자가 UI 모형을 수행해야합니까?

저는 독점적 인 웹 응용 프로그램을 만드는 소규모 팀과 함께 일하고 있으며 UX는 우리 직원이 운영하는 사람이기 때문에 우선 순위가 높지 않지만 작업을 더 쉽게하려고합니다.

개발자로서 새 화면을 만들기 전에 UI 모형을 만들어야합니까? 다른 사람들과 이야기하고 참조 모델을 갖기 위해 일반적으로 일반적인 레이아웃은 너무 환상적입니다. 코드를 맹목적으로 작성하기 전에 UML 다이어그램을 만드는 것과 비교했습니다.

저의 동료 중 한 사람은 이것이 터무니없고 그렇게하는 것이 나의 일이 아니라고 말합니다.

나는 종종 그러한 프로젝트에서 일하고 있으며 그 대답은 가능한 그렇습니다.

사람들은 훨씬 쉽게 찾을 비판 처음부터 해결책을 마련하는 것보다 몇 초안을 향상시킬 수 있습니다. 그래서 나는 두 가지 이유에서 초기 제도를 시작합니다.

• 문제 전문가에게 정보 제공 방법에 대한 인상을주십시오.
• 문제와 정보 구조에 대한 나의 현재 이해를 보여주십시오.

드문 경우지만 우리가 동의 한 것을 실제로 전달했다는 증거를 갖는 것도 좋았습니다 ...

목업은 환상적이며 개발자가 그렇게해서는 안되는 이유가 없습니다. (프로젝트에 UI 디자이너가있는 경우에도 개발자가 UI 레이아웃의 대략적인 초안을 작성하는 것이 편리 할 수도 있습니다.)

실제 화면처럼 보이는 모형을 만들지 않는 것이 좋습니다. 색상 및 테마와 같이 중요하지 않은 것에 초점을 맞추는 최종 사용자와 이러한 것을 공유하는 경우. 내가 추천하는 것은 종이에 손으로 그린 ​​그림이나 화이트 보드 스케치입니다. 또는 컴퓨터에서 연필 프로젝트 또는 Visio 와 같은 것을 사용하려는 경우 ( 여기서는 Jonathan Abbett의 일부 Visio 스텐실을 손으로 그린 ​​것처럼 보입니다.)

네 그럼요.

다른 사람이 귀하의 업무 수행 방법을 알려주지 않도록하십시오. 데이터 모델에 UML을 수행하는 것과 매우 흡사합니다. 개발자라고 가정하면 업무는 양질의 소프트웨어를 제공하는 것입니다. 목업이 도움이된다면 그것은 당신의 일의 일부입니다.

충실도가 낮은 모형을 만들어 실제 화면처럼 보이게하지 마십시오. 글꼴과 픽셀 및 테두리를 조정하는 데 시간이 너무 많이 걸리므로 사용자는 기능에 집중하기보다는 이러한 세부 사항에 집착하게됩니다. balsamiq과 같은 것이 이것에 좋으며 다른 유사한 도구는 의심의 여지가 없습니다. 실물 크기의 모형을 사용하면 사용자 및 개발 팀의 다른 구성원과 프로젝트 기능을 훨씬 쉽게 논의 할 수 있습니다.

"새 화면"을 디자인 할 때 먼저 UI의 대략적인 아이디어를 사용자 및 / 또는 동료와 논의하려고합니다. "코드"또는 "UML"사용자와 간단하게 작동하지 않습니다 (프로그래머 간에도 작동하지 않음). 그리고 처음 두세 개의 스케치를 버려야하거나 UI 요소를 적어도 많이 재정렬해야합니다.

따라서이를 신속하게 수행 할 수있는 그래픽 UI 디자인 도구가 있다면 사용하는 것이 좋습니다. 그러나 UI 요소를 수동으로 코딩해야하고 UI 요소를 제거하거나 다시 정렬하려면 많은 노력이 필요하지만 UI를 먼저 "코딩"하지 않는 것이 더 합리적입니다. 그래픽 그리기 도구를 사용하거나 연필과 종이를 사용하여 별도의 모형을 만드는 것이 훨씬 더 효율적입니다.

반드시 그런 것은 아닙니다. 모형이 거의 사용되지 않는 이유는 두 가지 이상 있습니다.

먼저, 당신이하려고하는 일을하는 것과 관련하여 잘 확립 된 산업 관행이 있다면, 그냥 계속 진행하면됩니다. UI 디자인의 기술을 발전 시키지는 않을 것입니다.

둘째, 최종 사용자는 종종 자신에게 무엇이 좋은지, 왜 그런지 알지 못합니다. 그들은 프로그램을 사용하기 시작할 때까지 (실제 또는 모의 데이터로) 알 수 없습니다. 정적 모형의 양이 도움이되지 않습니다.

"이전 N 화면과 같은 다른 UI 화면"을위한 약간 유연한 웹 프레임 워크를 사용하면 프로토 타입으로 시작하여 다시 정렬 할 수 있습니다. 멋진 일을하려고 할 때마다 모형을 만들어 동료들과상의하십시오.

항상!

저는 소규모 회사에서 일하고 있으며 유일한 "소프트"IT 담당자입니다. 나는 모든 요구 사항, 디자인, 코딩, 테스트 (누군가가 항상 테스트를 확인하지만), 데이터베이스 디자인 등을 수행합니다.

디자인 단계에서 코너를 절대로 자르지 마십시오. 최종 사용자가 감사합니다. 당신 때문에 너무 자신을 감사 할 것입니다 는 최종 사용자가 행복하기 위해 재 작업을 끝낸다. 실물 크기의 모형이 손으로 그린 ​​종이에 지나지 않아도 기대할 수있는 아이디어를 제공합니다. 무언가를 낙서하는 데 10 분이 걸리면 일주일의 시간을 절약 할 수 있습니다.

또한 코딩에 도움이됩니다. 그것은 당신이해야 할 일, 그것을 달성하는 가장 효율적인 방법 및 방해가 될 수있는 장애물에 대해 생각할 수있는 기회를 제공합니다.

예를 들어, 테이블 xyz에서 날짜를 캡처하지 않기 때문에 작성해야 할 "간단한"보고서가 처음 생각한 것보다 어렵다는 것을 알 수 있습니다. 또한 당신의 시야를 넓히고 팀, 상사 또는 심지어 당신이 최소한의 일 이상을 할 수있는 잠재적 인 미래의 직업 기회에 사용될 수 있고 "내 직업이 아니라"라는 상자 밖으로 나갈 수 있음을 보여줍니다 (<--- 심각하게, 그 사람이되지 마십시오, 우리 모두는 그를 싫어하거나 추가 학습의 기회를 제공합니다.

좀 더 일반적인 방법으로 살펴 보겠습니다 :

• 초안을 만드는 것이 좋습니다?
• 누가 초안을 작성해야합니까?

초안을 만드는 것이 좋습니다?

초안 작성은 주로 두 가지 이점을 제공합니다. 첫째, 초점을 제공하여 실제 작업 속도를 높입니다. 둘째, 작업이 완료되기 전에 작업 방향을 논의하는 것이 훨씬 간단합니다.

초안 작성의 단점은 시간을 사용한다는 것입니다. 만드는 데 4 시간이 걸리는 정교한 초안을 만드는 데 2 ​​시간을 소비하는 것은 의미가 없습니다.

귀하의 경우 모형 레벨에는 프로젝트에 소요되는 예상 작업량과 초안의 이점을 고려해야합니다. 이것에 따라 목업은 포스트잇의 10 초 낙서와 완전한 대화식 웹 사이트 사이에있을 수 있습니다. 매우 크고 비싼 프로젝트의 경우 전체 팀이 몇 주 동안 초안 작업을 수행하고 초안 초안을 만드는 것이 드문 일이 아닙니다.

누가 초안을 작성해야합니까?

여기서 정교하게 답변 할 필요가 없습니다. 초안을 만들면 혜택을받을 수 있습니다. 다른 사람이 귀하를 대신하여 초안을 작성하는 것이 도움이되는 경우 다른 사람에게 초안을 작성하도록 요청하십시오.

당신의 동료는 절대적으로 정확합니다. 내부 응용 프로그램은 일반적으로 미리 정의 된 모양이 있습니다. 또한 이러한 응용 프로그램의 경우 사용자는 최첨단 UI를 찾지 않습니다. 그들이 원하는 것은 효과적이고 사용하기 쉬운 것입니다. UI (내부 앱의 경우 강력하게 권장 할 것입니다)를 근본적으로 변경하려는 경우가 아니라면 기존 모양과 느낌을 따르십시오. 모형은 훌륭하지만 귀하의 경우 통증을 증가시킬뿐입니다.