IT story

일부 개발자에게는 왜 좋은 UI 디자인이 그렇게 어려운가요?

hot-time 2020. 5. 5. 19:40
반응형

일부 개발자에게는 왜 좋은 UI 디자인이 그렇게 어려운가요? [닫은]

우리 중 일부는 UI 디자인의 부드러운 측면 ( 특히 나 자신 ) 으로 어려움을 겪고 있습니다. "백엔드 코더"는 비즈니스 로직 및 데이터 계층 만 설계 할 운명입니까? 유쾌하고 유용한 프리젠 테이션 레이어를보다 효과적으로 디자인하기 위해 뇌 를 재교육 하기 위해 할 수있는 일이 있습니까?

동료는 나를 포함한 몇 가지 책을 추천 한 사이트의 디자인을 , 나를 생각하지 마십시오 과 왜 소프트웨어는 짜증 ,하지만 난 다른 사람들이이 지역에서 자신의 결함을 제거하기 위해 무엇을했는지 궁금?

직접 말하겠습니다 :

이를 개선하는 것은 지침으로 시작하지 않습니다. 소프트웨어에 대한 생각을 재구성하는 것으로 시작합니다.

대부분의 하드 코어 개발자들은 거의가 제로 자신의 소프트웨어의 사용자와 공감을. 사용자의 생각, 사용자가 사용하는 소프트웨어 모델을 작성하는 방법 및 컴퓨터를 일반적으로 사용하는 방법에 대한 실마리 는 없습니다 .

전문가가 평신도와 충돌 할 때 나타나는 전형적인 문제는 다음과 같습니다. 일반인이 어떻게 10 년 전에 전문가가 이해 한 것을 이해하지 못하는 것이 어리석은 것일까 요?

거의 모든 숙련 된 개발자가 파악하기 어려운 사실을 인정하는 첫 번째 사실 중 하나는 다음과 같습니다.

평범한 사람들은 소프트웨어와 개념이 크게 다릅니다. 그들은 프로그래밍의 실마리가 없습니다. 없음 제로. 그리고 그들은 신경 쓰지 않습니다. 그들은 신경 써야한다고 생각하지도 않습니다. 당신이 그들을 강제로하면, 그들은 프로그램을 삭제합니다.

이제는 개발자에게는 믿을 수 없을 정도로 가혹합니다. 그는 자신이 생산 한 소프트웨어를 자랑스럽게 생각합니다. 그는 모든 단일 기능을 좋아합니다. 그는 코드의 작동 방식을 정확히 알려줄 수 있습니다. 어쩌면 그는 이전보다 50 % 더 빠르게 작동하는 믿을 수없는 영리한 알고리즘을 발명했을 수도 있습니다.

그리고 사용자는 신경 쓰지 않습니다.

이런 멍청이 같으니라고.

많은 개발자가 일반 사용자와 함께 일할 수 없습니다. 그들은 존재하지 않는 기술 지식에 의해 우울해집니다. 그렇기 때문에 대부분의 개발자는 부끄러워하고 사용자가 바보라고 생각합니다.

그들은 아닙니다.

소프트웨어 개발자가 자동차를 구입하면 자동차가 원활하게 작동 할 것으로 기대합니다. 그는 보통 타이어 압력, 그런 식으로 작동시키는 데 중요한 기계적 미세 조정에 대해서는 신경 쓰지 않습니다. 여기서 그는 전문가 가 아닙니다 . 그리고 미세 조정이없는 자동차를 사면 다시 돌려주고 원하는 것을하는 자동차를 구입합니다.

영화를 좋아하는 많은 소프트웨어 개발자. 상상력을 자극하는 영화. 그러나 영화 제작, 시각 효과 제작 또는 훌륭한 영화 스크립트 작성 전문가는 아닙니다. 대부분의 얼간이는 복잡한 감정을 표시하고 분석에 거의 영향을 미치지 않기 때문에 행동에 매우 나쁘다. 개발자가 나쁜 영화를 본다면 영화 전체가 나쁘다는 것을 알게됩니다. 얼간이는 IMDB를 구축하여 좋은 영화와 나쁜 영화에 대한 정보를 수집하여 어떤 영화를보고 피해야하는지 알 수 있습니다. 그러나 그들은 영화 제작 전문가가 아닙니다. 영화가 나쁘면 영화로 가지 않거나 BitTorrent에서 다운로드하지 않습니다.

전문가로 일반 사용자를 줄이는 것은 무지입니다. 전문가가 아닌 분야 (그리고 너무 많은 분야)에서 그들은 다른 분야의 전문가들이 그들의 제품이나 서비스를 사용하는 일반인에 대해 이미 생각했을 것으로 기대합니다.

이를 해결하기 위해 무엇을 할 수 있습니까? 프로그래머로서 하드 코어가 많을수록 일반적인 사용자의 생각에 덜 개방적입니다. 그것은 외계인이며 당신에게 실마리가 될 것입니다. 당신은 생각할 것이다 : 나는 사람들이 수 있는지 상상할 수없는 적 지식의 부족으로 컴퓨터를 사용합니다. 그러나 그들은 할 수 있습니다. 모든 UI 요소에 대해 다음을 고려하십시오. 사용자가 내 도구에 가지고있는 개념에 맞습니까? 어떻게 그를 이해할 수 있습니까? 이것에 대한 유용성을 읽어보십시오. 좋은 책이 많이 있습니다. 과학의 전체 영역이기도합니다.

아, 그리고 말하기 전에, 나는 애플 팬입니다.)

UI 디자인 은 어렵다

질문에 :

대부분의 개발자에게 UI 디자인이 왜 그렇게 어려운가요?

반대의 질문을 해보세요 :

대부분의 UI 디자이너 에게는 왜 프로그래밍 이 어려운 가요?

UI를 코딩하고 UI를 디자인하려면 다른 기술과 사고 방식이 필요합니다. UI 디자인은 코드를 작성하는 것이 일부 디자이너가 아닌 대부분의 디자이너에게 어려운 것처럼 일부 개발자가 아닌 대부분의 개발자 에게는 어려운 일입니다 .

코딩이 어렵다. 디자인도 어렵다. 둘 다 잘하는 사람은 거의 없습니다. 훌륭한 UI 디자이너는 거의 코드를 작성하지 않습니다. 그들은 방법을 알지 못하지만 여전히 훌륭한 디자이너입니다. 그렇다면 왜 훌륭한 개발자가 UI 디자인을 책임 져야합니까?

UI 디자인에 대해 더 많이 알고 있으면 더 나은 개발자가되지만 UI 디자인을 책임 져야한다는 의미는 아닙니다. 코드를 작성하는 방법을 알면 더 나은 디자이너가 될 수 있지만 UI 코딩을 책임 져야한다는 의미는 아닙니다.

UI 디자인을 향상시키는 방법

UI 디자인을 향상시키고 자하는 개발자에게는 3 가지 기본 조언이 있습니다.

  1. 디자인을 별도의 기술로 인식합니다 . 코딩과 디자인은 별개이지만 관련이 있습니다. UI 디자인은 코딩의 하위 집합이 아닙니다. 다른 사고 방식, 지식 기반 및 기술 그룹이 필요합니다. UI 디자인에 중점을 둔 사람들이 있습니다.
  2. 디자인에 대해 알아보십시오 . 적어도 조금은 요 아래의 긴 목록에서 몇 가지 디자인 개념과 기술을 배우십시오. 좀 더 야심이 있다면 책을 읽고, 회의에 참석하고, 수업을 듣고, 학위를 받으십시오. 디자인을 배우는 방법에는 여러 가지가 있습니다. UI 디자인에 대한 Joel Spolky의 책 은 개발자에게 좋은 입문서이지만 더 많은 내용이 있으며 디자이너가 그림을 찾는 곳입니다.
  3. 디자이너와 협력하십시오 . 당신이 할 수 있다면 좋은 디자이너. 이 작업을 수행하는 사람들은 다양한 제목으로 이동합니다. 오늘날 가장 일반적인 제목은 UXD (User Experience Designer), IA (Information Architect), ID (Interaction Designer) 및 유용성 엔지니어입니다. 코드에 대한 생각만큼 디자인에 대해서도 생각합니다. 당신은 그들에게서 많은 것을 배울 수 있고 그들은 당신에게서 배울 수 있습니다. 그러나 그들과 함께 할 수 있습니다. 회사에서 이러한 기술을 가진 사람들을 찾으십시오. 누군가를 고용해야 할 수도 있습니다. 또는 일부 회의에 참석하거나 웹 세미나에 참석하고 UXD / IA / ID 세계에서 시간을 보내십시오.

배울 수있는 몇 가지 구체적인 사항이 있습니다. 모든 것을 배우려고하지 마십시오 . 아래의 모든 것을 알고 있다면 상호 작용 디자이너 또는 정보 설계 자라고 할 수 있습니다. 목록 상단 근처의 것부터 시작하십시오 . 특정 개념과 기술에 중점을 둡니다. 그런 다음 아래로 이동하여 분기하십시오. 이 물건을 정말로 좋아한다면, 그것을 진로로 생각하십시오. 많은 개발자들이 경영진으로 이주하지만 UX 디자인이 또 다른 옵션입니다.

UI 디자인이 어려운 이유

좋은 UI 디자인은 크게 다른 기술이 필요하기 때문에 어렵습니다.

  • 기계에 대한 깊은 이해 . 이 그룹의 사람들은 먼저 코드에 대해 걱정하고 사람들은 두 번째로 걱정합니다. 그들은 깊은 기술 지식과 기술을 가지고 있습니다. 이를 개발자, 프로그래머, 엔지니어 등이라고합니다.
  • 사람과 디자인에 대한 깊은 이해 :이 그룹의 사람들은 먼저 사람들에 대해 걱정하고 코드 둘째에 대해 걱정합니다. 그들은 사람들이 정보, 컴퓨터 및 주변 세계와 어떻게 상호 작용하는지에 대한 깊은 지식을 가지고 있습니다. 이를 사용자 경험 디자이너, 정보 설계자, 인터랙션 디자이너, 유용성 엔지니어 등이라고합니다.

이것이 개발자와 디자이너 사이에서이 두 그룹의 근본적인 차이점입니다.

  • 개발자는 그것을 작동 시킵니다. TiVo, iPhone, 즐겨 찾는 웹 사이트 등에서 기능을 구현합니다. 실제로해야 할 일을 실제로 수행합니다. 그들의 최우선 과제는 그것이 작동하는 것입니다.
  • 디자이너는 사람들이 그것을 좋아하게 만듭니다 . 그들은 상호 작용하는 방법, 모양 및 느낌을 파악합니다. 그들은 응용 프로그램, 웹 사이트, 장치 사용 경험을 디자인합니다. 그들의 최우선 순위는 개발자가 만드는 것에 사랑을 느끼게하는 것입니다. 이것은 사용자 경험의 의미이며 브랜드 경험과 동일하지 않습니다.

게다가, 프로그래밍과 디자인은 다른 지식과 다른 기술뿐만 아니라 다른 사고 방식을 요구 합니다. 좋은 UI 디자인에는 두 가지 사고 방식, 지식 기반, 기술 그룹이 모두 필요합니다. 그리고 하나를 마스터하는 데 몇 년이 걸립니다.

UI 디자이너가 코드 작성을 어렵게 생각하는 것처럼 개발자는 UI 디자인을 찾기가 어렵습니다.

내 디자인을 개선하는 데 실제로 도움이되는 것은 동료 개발자, QA 담당자, PM 또는 특정 위젯이나 화면을 시험해 보는 사람을 얻는 것입니다.

다른 사람이 처음으로 소프트웨어를 사용하는 것을 볼 때 알게 될 놀라운 사실

궁극적으로 그것은 공감에 관한 것입니다. 사용자의 입장에서 자신을 맡길 수 있습니까?

물론 도움이되는 한 가지는 "자신의 개밥을 먹는 것"입니다. 응용 프로그램을 실제 사용자로 사용하고 성가신 것을 보는 것입니다.

또 다른 좋은 아이디어는 응용 프로그램을 사용하여 실제 사용자를 볼 수있는 방법을 찾는 것입니다. 단방향 미러, 화면 비디오 캡처, 사용자의 비디오 카메라 등이 포함 된 유용성 랩처럼 복잡하거나 간단 할 수 있습니다. 복도를 걸어가는 다음 사람을 사용하여 종이 프로토 타이핑으로

다른 모든 방법이 실패 할 경우 UI가 너무 복잡하기보다 너무 단순하면 거의 항상 더 좋습니다. "오, 나는 그것을 해결하는 방법을 알고있다. 사용자가 선호하는 모드를 결정할 수 있도록 체크 박스를 추가 할 것이다." 곧 UI가 너무 복잡합니다. 기본 모드를 선택하고 환경 설정을 고급 구성 옵션으로 설정하십시오. 아니면 그냥 놔둬

디자인에 대해 많이 읽으면 그림자와 둥근 모서리 등에 쉽게 매달 수 있습니다. 중요한 것은 아닙니다. 단순성과 발견 가능성은 중요한 것들입니다.

대중적인 신화와는 달리, UI 디자인에는 말 그대로 소프트 백엔드가 없으며 적어도 좋은 백엔드를 디자인하는 데 필요한 것 이상은 아닙니다.

다음을 고려하세요; 훌륭한 백엔드 디자인은 훌륭한 개발자가 잘 알고있는 상당히 견고한 원칙과 요소를 기반으로합니다.

  • 낮은 커플 링

  • 높은 응집력

  • 건축 패턴

  • 업계 모범 사례

  • 기타

좋은 백엔드 설계는 일반적으로 여러 상호 작용을 통해 이루어지며, 테스트 또는 실제 사용 중에 얻은 측정 가능한 피드백을 기반으로 초기 청사진이 점차 향상됩니다. 때로는 백엔드의 작은 측면을 프로토 타입하고 격리 등으로 시험해야합니다.

좋은 UI 디자인은 다음과 같은 사운드 원칙을 기반으로합니다.

  • 시계

  • 여유

  • 피드백

  • 공차

  • 간단

  • 일관성

  • 구조

UI는 또한 테스트 및 평가판을 통해 반복되지만 컴파일러 + 자동 테스트 슈트가 아닌 사람들을 통해 탄생합니다. 백엔드와 마찬가지로 업계 최고의 실무, 측정 및 평가 기술, UI를 생각하고 사용자 모델, 시스템 이미지, 디자이너 모델, 구조 모델, 기능 모델 등의 목표를 설정하는 방법이 있습니다.

UI 디자인에 필요한 기술은 백엔드 디자인과는 매우 다르기 때문에 먼저 학습하지 않고도 좋은 UI를 수행 할 수있을 것으로 기대하지 않습니다. 그러나이 두 가지 활동은 공통적으로 설계 과정입니다. 좋은 소프트웨어를 디자인 할 수있는 사람이라면 누구나 시간을 투자하는 한 좋은 UI를 디자인 할 수 있다고 생각합니다.

휴먼 컴퓨터 인터랙션 과정을 수강하는 것이 좋습니다. 온라인 자료를 보려면 MIT 및 Yale 사이트를 확인하십시오.

이해와 사용법에서 구조적 vs 기능적 모델

Thorsten79 의 우수한 이전 게시물 은 소프트웨어 개발 전문가 대 사용자의 주제와 소프트웨어에 대한 이해가 어떻게 다른지 알려줍니다. 인간 학습 전문가는 기능적 정신적 모델과 구조적 정신적 모델을 구분합니다. 친구의 집으로가는 길을 찾는 것은 두 사람의 차이점에 대한 훌륭한 예가 될 수 있습니다.

  • 첫 번째 접근 방식에는 일련의 세부 지침이 포함됩니다. 고속도로의 첫 번째 출구를 타고 100 야드 정도 좌회전 한 후 등. 이것은 기능 모델의 예입니다. 특정 목표를 달성하는 데 필요한 구체적인 단계 목록. 기능적 모델은 사용하기 쉬우 며, 단순한 실행을 생각할 필요가 없습니다. 분명히 단순성에 대한 패널티가 있습니다. 가장 효율적인 경로가 아닐 수 있으며 예외적 인 상황 (예 : 교통 우회)이 완전히 실패로 이어질 수 있습니다.

  • A different way to cope with the task is to build a structural mental model. In our example that would be a map that conveyes a lot of information about the internal structure of the "task object". From understanding the map and relative locations of our and friend's house we can deduct the functional model (the route). Obviously it's requires more effort, but much more reliable way of completing the task in spite of the possible deviations.

The choice between conveying functional or structural model through UI (for example, wizard vs advanced mode) is not that straight forward as it might seem from Thorsten79's post. Advanced and frequent users might well prefer the structural model, whereas occassional or less expirienced users — functional.

Google지도는 훌륭한 예입니다. 기능적 모델과 구조적 모델이 모두 포함되어 있기 때문에 많은 탐색 네비게이션도 포함됩니다.

문제의 또 다른 차원은 UI를 통해 제공되는 구조 모델이 소프트웨어의 구조에 매핑되지 않아야하며, 당연히 사용자 작업 또는 관련된 작업 개체의 구조에 매핑되어야한다는 것입니다.

여기서 많은 어려움은 많은 개발자들이 소프트웨어 내부 구조에 대한 좋은 구조적 모델을 가지지 만 소프트웨어가 목표로하는 사용자 작업의 기능적 모델 만 가질 것이라는 점입니다. 좋은 UI를 구축하려면 작업 / 태스크 객체 구조를 이해하고 UI를 해당 구조에 매핑해야합니다.

어쨌든, 나는 여전히 공식적인 HCI 과정을 충분히 강하게 추천하지 않습니다. 휴리스틱 , 게슈탈트 물리학 에서 파생 된 원칙 , 인간이 배우는 방법 등과 같은 많은 것들이 있습니다 .

유용성과 물건에 중점을 두지 않고 지금과 같은 방식으로 모든 UI를 시작하는 것이 좋습니다.

대체 텍스트 http://www.stricken.org/uploaded_images/WordToolbars-718376.jpg

이제 이것을 생각해보십시오.

디자이너는 자신이 추가 할 항목이 없을 때가 아니라 제거 할 항목이 없을 때 완벽 함을 달성했다는 것을 알고 있습니다. — 생 텍쥐페리

그리고 이것을 디자인에 적용하십시오.

많은 개발자들은 코드를 작성할 수 있기 때문에 모든 것을 할 수 있다고 생각합니다. 인터페이스 디자인은 완전히 다른 기술이며, 대학에 다닐 때 전혀 배우지 못했습니다. 단지 자연스럽게 오는 것이 아닙니다.

또 다른 좋은 책은 Donald Norman 의 The Everyday Things 디자인입니다 .

디자인과 미학에는 큰 차이가 있으며 종종 혼란스러워합니다.

아름다운 UI를 위해서는 예술적이거나 최소한 미적 기술이 필요합니다. 불행히도 많은 플래시 기반 API에서 볼 수 있듯이 충분하지 않고 UI를 사용할 수 없습니다.

사용 가능한 UI를 생성하려면 인간이 컴퓨터와 상호 작용하는 방법, 심리학의 일부 문제 (예 : Fitt의 법칙, Hick의 법칙) 및 기타 주제를 이해해야합니다. 이에 대한 교육은 거의 없습니다. 내가 아는 개발자는 JUnit 책 등에서 사용자 테스트 책을 선택할 것입니다.

우리 중 상당수는 "핵심 프로그래머"이며 UI를 프로젝트의 성공을 방해하거나 방해 할 수있는 요소가 아닌 정면으로 생각하는 경향이 있습니다.

또한 대부분의 UI 개발 경험은 매우 실망 스럽습니다. 우리는 오래된 VB와 같은 장난감 GUI 빌더를 사용하고 못생긴 접착제 코드를 처리해야하거나 Swing에서 레이아웃을 정렬하는 것과 같이 끝없이 좌절시키는 API를 사용합니다.

Slashdot로 이동하여 Apple 관련 기사에 대한 의견을 읽으십시오. 많은 사람들이 Apple 제품이 특별한 점에 대해 이야기하고 iPod 및 iPhone의 성공을 유행이나 엉덩이에 빠뜨리려는 사람들에게 알리는 것을 알게 될 것입니다. 그들은 일반적으로 기능 목록을 살펴보고 이전 MP3 플레이어 또는 스마트 폰이하지 않은 아무것도하지 않습니다.

아이팟과 아이폰을 좋아하는 사람들은 매뉴얼을 참조하지 않고 사용자가 원하는 것을 간단하고 쉽게하기 때문에 좋아합니다. 인터페이스는 인터페이스가 이해하기 쉽고 기억하기 쉬우 며 직관적입니다. 나는 이전 버전에서와 같이 MacOSX의 UI를 좋아하지는 않지만, 그것이 화려 함을 위해 약간의 유용성을 포기했다고 생각하지만, iPod과 iPhone은 최고의 디자인의 예입니다.

첫 번째 캠프에 있다면 평범한 사람이 생각하는 방식을 생각하지 않으므로 좋은 사용자 인터페이스를 말할 수 없기 때문에 잘못된 사용자 인터페이스를 만들 수 있습니다. 이것은 희망이 없다는 것을 의미하는 것이 아니라, 좋은 인터페이스 디자인 원칙과 좋은 UI를 인식하는 방법을 명시 적으로 배워야한다는 것을 의미합니다. 분명히 좋은 UI를 가지고 있다고해서 UI를 만들 수있는 것은 아닙니다. 예를 들어, 문학에 대한 저의 감사는 (현재) 출판 가능한 이야기를 쓰는 능력으로 확장되지 않는 것 같습니다.

따라서 좋은 UI 디자인에 대한 감각을 개발하십시오. 이것은 단순한 소프트웨어 이상으로 확장됩니다. Don Norman의 "The Everyday Things의 디자인"은 고전이며, 다른 책들도 있습니다. 성공적인 UI 디자인의 예를 들어 차이를 느끼기에 충분할 수 있습니다. 새로운 것을 생각하는 새로운 방식을 배우고 즐길 수 있음을 인식하십시오.

내가 잡는 경험의 주된 규칙은 한 번에 두 가지를 모두 시도하지 않는 것입니다. 백엔드 코드로 작업하는 경우 작업을 마치고 휴식을 취한 다음 UI 모자를 착용 한 상태로 돌아갑니다. 코드를 작성하는 동안 코드를 사용하려고하면 잘못된 사고 방식으로 코드에 접근하여 결과적으로 끔찍한 인터페이스가 생깁니다.

훌륭한 백엔드 개발자이자 UI 디자이너가 될 수 있다고 생각합니다. 그냥 작업하고 주제에 대한 독서와 연구를해야합니다 (밀러의 # 7에서 Nielsen의 아카이브까지). UI 디자인이 가장 중요한 이유 를 이해하십시오 .

나는 그것이 창의적이어야 할 필요는 없지만 백엔드 개발과 같이 배워야 할 매우 체계적이고 구조적인 것입니다. 사람들이 가장 큰 유용성 괴물을 만드는 UI로 '창의적'을 얻는 사람들이 있습니다 ... 내 말은, 100 % 플래시 웹 사이트를 살펴 보는 것입니다.

편집 : Krug의 책은 정말 좋습니다 ... 특히 웹용으로 디자인하려는 경우 읽어보십시오.

여기에는 여러 가지 이유가 있습니다.

(1) 개발자가 사용자 관점에서 사물을 보지 못합니다. 이것은 일반적인 용의자입니다 : 공감 부족. 그러나 개발자가 사람들이 원하는만큼 외계인이 아니기 때문에 일반적으로 사실이 아닙니다.

(2) 또 다른 가장 일반적인 이유는 개발자가 자신의 물건에 너무 오랫동안 머물렀고 오랫동안 물건을 가지고 있었기 때문에 자신의 물건이 다른 사람에게 너무 친숙하지 않다는 것을 깨닫지 못하기 때문입니다 .

(3) 또 다른 이유는 개발자가 기술이 부족하기 때문입니다.

MY BIG CLAIM : UI, 휴먼 인터랙션 디자인, 프로토 타입 책을 읽습니다. 예를 들어, 명백한 디자인 : 웹 응용 프로그램 디자인에 대한 상식적인 접근 방식, 생각하지 말 것 : 웹 사용성에 대한 상식적인 접근 방식, 순간을 디자인하는 것.

How do they discuss task flows? How do they describe decision points? That is, in any use case, there are at least 3 paths: success, failure/exception, alternative.

Thus, from point A, you can go to A.1, A.2, A.3. From point A.1, you can get to A.1.1, A.1.2, A.1.3, and so on.

How do they show such drill-down task flow? They don't. They just gloss over it.

Since even UI experst don't have a technique, developers have no chance. He thinks it is clear in his head. But it is not even clear on paper, let alone clear in software implementation.

I have to use my own hand-made techniques for this.

I try to keep in touch with design-specific websites and texts. I found also the excellent Robin Williams book The Non-Designer's Design Book to be very interesting in these studies.

I believe that design and usability is a very important part of software engineering and we should learn it more and stop giving excuses that we are not supposed to do design.

Everyone can be a designer once in a while, as also everyone can be a programmer.

When approaching UI design, here are a few of the things I keep in mind throughout (by far not a complete list):

  • Communicating a model. The UI is a narrative that explains a mental model to the user. This model may be a business object, a set of relationships, what have you. The visual prominence, spatial placement, and workflow ordering all play a part in communicating this model to the user. For example, a certain kind of list vs another implies different things, as well as the relationship of what's in the list to the rest of the model. In general I find it best to make sure only one model is communicated at a time. Programmers frequently try to communicate more than one model, or parts of several, in the same UI space.

  • Consistency. Re-using popular UI metaphors helps a lot. Internal consistency is also very important.

  • Grouping of tasks. Users should not have to move the mouse all the way across the screen to verify or complete a related sequence of commands. Modal dialogs and flyout-menus can be especially bad in this area.

  • Knowing your audience. If your users will be doing the same activities over and over, they will quickly become power users at those tasks and be frustrated by attempts to lower the initial entry barrier. If your users do many different kinds of activities infrequently, it's best to ensure the UI holds their hand the whole time.

Read Apple Human Interface Guidelines.

I find the best tool in UI design is to watch a first-time User attempt to use the software. Take loads of notes and ask them some questions. Never direct them or attempt to explain how the software works. This is the job of the UI (and well written documentation).

We consistently adopt this approach in all projects. It is always fascinating to watch a User deal with software in a manner that you never considered before.

Why is UI design so hard? Well generally because the Developer and User never meet.

duffymo just reminded me why: Many Programmers think "*Design" == "Art".

Good UI design is absolutely not artistic. It follows solid principles, that can be backed up with data if you've got the time to do the research.

I think all programmers need to do is take the time to learn the principles. I think it's in our nature to apply best practice whenever we can, be it in code or in layout. All we need to do is make ourselves aware of what the best practices are for this aspect of our job.

What have I done to become better at UI design?
Pay attention to it!

It's like how ever time you see a chart on the news or an electronic bus sign and you wonder 'How did they get that data? Did they do that with raw sql or are they using LINQ?' (or insert your own common geek curiosity here).

You need to start doing that but with visual elements of all kinds.

But just like learning a new language, if you don't really throw yourself into it, you won't ever learn it.

Taken from another answer I wrote:

Learn to look, really look, at the world around you. Why do I like that UI but hate this one? Why is it so hard to find the noodle dishes in this restaurant menu? Wow, I knew what that sign meant before I even read the words. Why was that? How come that book cover looks so wrong? Learn to take the time to think about why you react the way you do to visual elements of all kinds, and then apply this to your work.

However you do it (and there are some great points above), it really helped me once I accepted that there is NO SUCH THING AS INTUITIVE....

I can hear the arguments rumbling on the horizon... so let me explain a little.

Intuitive: using what one feels to be right or true based on an unconscious method or feeling.

If (as Carl Sagan postulated) you accept that you cannot comprehend things that are absolutely unlike anything you have ever encountered then how could you possibly "know" how to use something if you have never used anything remotely like it?

Think about it: kids try to open doors not because they "know" how a doorknob works, but because they have seen someone else do it... often they turn the knob in the wrong direction, or pull too soon. They have to LEARN how a doorknob works. This knowledge then gets applied in different but similar instances: opening a window, opening a drawer, opening almost anything big with a big, knob-looking handle.

Even simple things that seem intuitive to us will not be intuitive at all to people from other cultures. If someone held their arm out in front of them and waived their hand up-and-down at the wrist while keeping the arm still.... are they waiving you away? Probably, unless you are in Japan. There, this hand signal can mean "come here". So who is right? Both, of course, in their own context. But if you travel to both, you need to know both... UI design.

I try to find the things that are already "familiar" to the potential users of my project and then build the UI around them: user-centric design.

Take a look at Apple's iPhone. Even if you hate it, you have to respect the amount of thought that went into it. Is it perfect? Of course not. Over time an object's perceived "intuitiveness" can grow or even fade away completely.

For example. Most everyone knows that a strip of black with two rows of holes along the top and bottom looks like a film strip... or do they?

Ask your average 9 or 10 year old what they think it is. You may be surprised how many kids right now will have a hard time identifying it as a film strip, even though it is something that is still used to represent Hollywood, or anything film (movie) related. Most movies for the past 20 years have been digitally shot. And when was the last time any of us held a piece of film of ANY kind, photos or film?

So, what it all boils down to for me is: Know your audience and constantly research to keep up with trends and changes in things that are "intuitive", target your main users and try not to do things that punish the inexperienced in favor of the advanced users or slow down the advanced users in order to hand-hold the novices.

Ultimately, every program will require a certain amount of training on the user's part to use it. How much training and for which level of user is part of the decisions that need to be made.

Some things are more or less familiar based on your target user's past experience level as a human being, or computer user, or student, or whatever.

I just shoot for the fattest part of the bell curve and try to get as many people as I can but realizing that I will never please everyone....

I know that Microsoft is rather inconsistent with their own guidelines, but I have found that reading their Windows design guidelines have really helped me. I have a copy on my website here, just scroll down a little the the Vista UX Guide. It has helped me with things such as colors, spacing, layouts, and more.

I believe the main problem has nothing to do with different talents or skillsets. The main problem is that as a developer, you know too much about what the application does and how it does it, and you automatically design your UI from the point of view of someone who has that knowledge.

Whereas a user typically starts out knowing absolutely nothing about the application and should never need to learn anything about its inner workings.

It is very hard, almost impossible, to not use knowledge that you have - and that's why an UI should not be designed by someone who's developing the app behind it.

"Designing from both sides of the screen" presents a very simple but profound reason as to why programmers find UI design hard: programmers are trained to think in terms of edge cases while UI designers are trained to think in terms of common cases or usage.

So going from one world to the other is certainly difficult if the default traning in either is the exact opposite of the other.

To say that programms suck at UI design is to miss the point. The point of the problem is that the formal training that most developers get go indepth with the technology. Human - Computer Interaction is not a simple topic. It is not something that I can "mind-meld" to you by providing a simple one line statement that makes you realize "oh the users will use this application more effectively if I do x instead of y."

This is because there is one part of UI design that you are missing. The human brain. In order to understand how to design a UI, you have to understand how the human mind interacts with machinery. There is an excellent course I took at the University of Minnesota on this topic taught by a professor of Psychology. It is named "Human - Machine Interaction". This describes many of the reasons of why UI design is so complicated.

Since Psychology is based on Correlations and not Causality you can never prove that a method of UI design will always work in any given situation. You can correlate that many users will find a particular UI design appealing or efficient, but you cannot prove that it will always generalize.

Additionally, there are two parts to UI design that many people seem to miss. There is the aesthetical appeal, and the functional workflow. If you go for a 100% aesthetical appeal, sure people will but your product. I highly doubt that aesthetics will ever reduce user frustration though.

There are several good books on this topic and course to take (like Bill Buxton's Sketching User Experiences, and Cognition in the Wild by Edwin Hutchins). There are graduate programs on Human - Computer Interaction at many universities.

The overall answer to this question though lies in how individuals are taught computer science. It is all math based, logic based and not based on the user experience. To get that, you need more than a generic 4 year computer science degree (unless your 4 year computer science degree had a minor in psychology and was emphasized in Human - Computer Interaction).

Let's turn your question around -

Are "ui designers" doomed to only design information architecture and presentation layers? Is there something they can do to retrain their brains to be more effective at designing pleasing and efficient system layers?

Seems like them "ui designers" would have to take a completely different perspective - they'd have to look from the inside of the box outwards; instead of looking in from outside the box.

Alan Cooper's "The Inmates are Running the Asylum" opinion is that we can't successfully take both perspectives - we can learn to wear one hat well but we can't just switch hats.

I think its because a good UI is not logical. A good UI is intuitive.

Software developers typically do bad on 'intuitive'

A useful framing is to actively consider what you're doing as designing a process of communication. In a very real sense, your interface is a language that the user must use to tell the computer what to do. This leads to considering a number of points:

  1. Does the user already speak this language? Using a highly idiosyncratic interface is like communicating in a language you've never spoken before. So if your interface must be idiosyncratic at all, it had best introduce itself with the simplest of terms and few distractions. On the other hand, if your interface uses idioms that the user is accustomed to, they'll gain confidence from the start.
  2. The enemy of communication is noise. Auditory noise interferes with spoken communication; visual noise interferes with visual communication. The more noise you can cut out of your interface, the easier communicating with it will be.
  3. As in human conversation, it's often not what you say, it's how you say it. The way most software communicates is rude to a degree that would get it punched in the face if it were a person. How would you feel if you asked someone a question and they sat there and stared at you for several minutes, refusing to respond in any other way, before answering? Many interface elements, like progress bars and automatic focus selection, have the fundamental function of politeness. Ask yourself how you can make the user's day a little more pleasant.

Really, it's somewhat hard to determine what programmers think of interface interaction as being, other than a process of communication, but maybe the problem is that it doesn't get thought of as being anything at all.

There are a lot o good comments already, so I am not sure there is much I can add. But still...

  • Why would a developer expect to be able to design good UI?
  • How much training did he had in that field?
  • How many books did he read?
  • How many things did he designed over how many years?
  • Did he had the opportunity to see the reaction of it's users?

We don't expect that a random "Joe the plumber" to be able to write good code. So why would we expect the random "Joe the programmer" to design good UI?

Empathy helps. Separating the UI design and the programming helps. Usability testing helps.

But UI design is a craft that has to be learned, and practiced, like any other.

Developers are not (necessarily) good at UI design for the same reason they aren't (necessarily) good at knitting; it's hard, it takes practice, and it doesn't hurt to have someone show you how in the first place.

Most developers (me included) started "designing" UIs because it was a necessary part of writing software. Until a developer puts in the effort to get good at it, s/he won't be.

To improve just look around at existing sites. In addition to the books already suggested, you might like to have a look at Robin Williams's excellent book "The Non-designers Design Book" (sanitised Amazon link)

Have a look at what's possible in visual design by taking a look at the various submissions over at The Zen Garden as well.

UI design is definitely an art though, like pointers in C, some people get it and some people don't.

But at least we can have a chuckle at their attempts. BTW Thanks OK/Cancel for a funny comic and thanks Joel for putting it in your book "The Best Software Writing I" (sanitised Amazon link).

User interface isn't something that can be applied after the fact, like a thin coat of paint. It is something that needs to be there at the start, and based on real research. There's tons of Usability research available of course. It needs to not just be there at the start, it needs to form the core of the very reason you're making the software in the first place: There's some gap in the world out there, some problem, and it needs to be made more usable and more efficient.

Software is not there for its own sake. The reason for a peice of software to exist is FOR PEOPLE. It's absolutely ludicrous to even try to come up with an idea for a new peice of software, without understanding why anyone would need it. Yet this happens all the time.

Before a single line of code is written, you should go through paper versions of the interface, and test it on real people. This is kind of weird and silly, it works best with kids, and someone entertaining acting as "the computer".

The interface needs to take advantage of our natural cognitive facilities. How would a caveman use your program? For instance, we've evolved to be really good at tracking moving objects. That's why interfaces that use physics simulations, like the iphone, work better than interfaces where changes occur instantaneously.

We are good at certain kinds of abstraction, but not others. As programmers, we're trained to do mental gymnastics and backflips to understand some of the weirdest abstractions. For instance, we understand that a sequence of arcane text can represent and be translated into a pattern of electromagnetic state on a metal platter, which when encountered by a carefully designed device, leads to a sequence of invisible events that occur at lightspeed on an electronic circuit, and these events can be directed to produce a useful outcome. This is an incredibly unnatural thing to have to understand. Understand that while it's got a perfectly rational explanation to us, to the outside world, it looks like we're writing incomprehensible incantations to summon invisible sentient spirits to do our bidding.

The sorts of abstractions that normal humans understand are things like maps, diagrams, and symbols. Beware of symbols, because symbols are a very fragile human concept that take conscious mental effort to decode, until the symbol is learned.

The trick with symbols is that there has to be a clear relationship between the symbol, and the thing it represents. The thing it represents either has to be a noun, in which case the symbol should look VERY MUCH like the thing it represents. If a symbol is representing a more abstract concept, that has to be explained IN ADVANCE. See the inscrutable unlabled icons in msword's, or photoshop's toolbar, and the abstract concepts they represent. It has to be LEARNED that the crop tool icon in photoshop means CROP TOOL. it has to be understood what CROP even means. These are prerequisites to correctly using that software. Which brings up an important point, beware of ASSUMED knowledge.

We only gain the ability to understand maps around the age of 4. I think I read somewhere once that chimpanzees gain the ability to understand maps around the age of 6 or 7.

The reason that guis have been so successful to begin with, is that they changed a landscape of mostly textual interfaces to computers, to something that mapped the computer concepts to something that resembled a physical place. Where guis fail in terms of usability, is where they stop resembling something you'd see in real life. There are invisible, unpredictable, incomprehensible things that happen in a computer that bare no resemblance to anything you'd ever see in the physical world. Some of this is necessary, since there'd be no point in just making a reality simulator- The idea is to save work, so there has to be a bit of magic. But that magic has to make sense, and be grounded in an abstraction that human beings are well adapted to understanding. It's when our abstractions start getting deep, and layered, and mismatched with the task at hand that things break down. In other words, the interface doesn't function as a good map for the underlying software.

There are lots of books. The two I've read, and can therefore reccomend, are "The Design of Everyday Things" by donald norman, and "The Human Interface" by Jef Raskin.

I also reccomend a course in psychology. "The Design of Every day Things" talks about this a bit. A lot of interfaces break down because of a developer's "folk understanding" of psychology. This is similar to "folk physics". An object in motion stays in motion doesn't make any sense to most people. "You have to keep pushing it to keep it in motion!" thinks the physics novice. User testing doesn't make sense to most developers. "You can just ask the users what they want, and that should be good enough!" thinks the psychology novice.

I reccomend Discovering Psychology, a PBS documentary series, hosted by Philip Zimbardo. Failing that, try and find a good physics textbook. The expensive kind. Not the pulp fiction self help crap that you find in Borders, but the thick hardbound stuff you can only find in a university library. This is a necesesary foundation. You can do good design without it, but you'll only have an intuitive understanding of what's going on. Reading some good books will give you a good perspective.

If you read the book "Why software sucks" you would have seen Platt's answer, which is a simple one:

  1. Developers prefere control over user-friendliness
  2. Average people prefere user-friendliness over control

그러나 귀하의 질문에 대한 또 다른 대답은 "왜 일부 개발자에게는 치과학이 그렇게 어려운가?"입니다. -UI 디자인은 UI 디자이너가 가장 잘 수행합니다.

http://dotmad.net/blog/2007/11/david-platt-on-why-software-sucks/

참고 URL : https://stackoverflow.com/questions/514083/why-is-good-ui-design-so-hard-for-some-developers

반응형

'IT story' 카테고리의 다른 글

HTML 속성의 길이에 제한이 있습니까?  (0) 2020.05.06
라이브러리가로드되지 않음 : mysql2 gem으로 OS X 10.6에서 'rails server'를 실행하려고 할 때 libmysqlclient.16.dylib 오류  (0) 2020.05.05
ld : 프레임 워크를 찾을 수 없음  (0) 2020.05.05
파일을 특정 개정으로 재설정하거나 되돌리려면 어떻게해야합니까?  (0) 2020.05.05
for 루프 내에서 JavaScript 클릭 핸들러가 예상대로 작동하지 않음  (0) 2020.05.05

'IT story'의 다른글

  • 현재글일부 개발자에게는 왜 좋은 UI 디자인이 그렇게 어려운가요?

관련글

댓글

티스토리툴바