Unique challenges 특별한 시도들
Prototype everything in code 모든걸 코드로 프로토타이핑 하기
좋은 디자인을 만들기 위해선 어떻게 해야할까? 몇몇 사람들은 꽤 괜찮은 디자인으로 시작하고, 배포하고, 실제 데이터와 피드백으로 서비스를 개선할 수 있는 호사를 누린다. 반면 우리 팀은 그런 여유는 없었기 때문에(인프라나 기술 리소스 둘 다), 좋은 디자인을 위해선 실제로 배포하기 전에 최대한 많은 것들을 해둬야 했다. 이는 결국 얼마나 효율적으로 디자인을 전달하는게 중요한지로 귀결된다. 당신은 뭔가를 설계하기 전 디자인에 관해 깊고 양질의 대화를 나눠야 할 것이다. 그리고 기억해라. 우리 팀의 경우 수많은 언어를 각기 사용하는 자원봉사자와 이해관계자 모두와 대화를 나눴어야 했다. 이걸 들으면 이런 질문이 떠오를 거다: 어떻게 해야 디자인에 관해 가장 효율적으로 이야기하고, 최고의 논의를 끌어낼 수 있나? 내 답은: HTML과 CSS, JavaScript로 만들어진 수많은 작은 프로토타입이다. 당시 난 인터렉티브 디자인을 맡고 있었기 때문에 (스크롤링, 클릭, 타이핑 등) 가능한 많은 언어에서 지원되어야 했고, 유동적인 데이터에 의존했기 때문이다. (각 아티클은 다르고, 다른 내용을 가지며, 검색 쿼리는 다른 결과값을 던졌기 때문이다.) 이런 디자인을 효율적으로 평가하고 의사소통하기 위해 내가 찾았던 방법 중 최고는 명확하고 정확한 대화를 만들어주는 '프로토타입'이었다.
프로젝트가 시작될 때 난 기본이 되는 프로토타입을 하나 설계했다. 위키피디아 인터페이스에 몇몇 API가 적용되어 있는 형태여서 긴 아티클을 어떤 언어에서든지 로드할 수 있었다. 검색 박스나 실시간 검색 제안도 가능했다.
(후,,,이번주는 일이 많아서 여기까지,,,)
How do you get to a good design? Some people have the luxury of starting with a semi-good design, releasing it (in some limited way), then using real data and feedback to refine(개선하다) it. Since we don’t have that luxury (both in terms of infrastructure, and engineering resources), the process of getting to a good design needs to happen much more up-front, before releasing anything. This ends up putting emphasis on how effectively you communicate designs, and communicate about designs. You need to have many high quality, inclusive conversations about the designs before you build anything. And remember, in our case, inclusive of volunteers/stakeholders across many languages. So then the question becomes: how do you most effectively communicate designs, to facilitate the best discussions about those designs? My answer is: lots of little prototypes built with HTML, CSS, and JavaScript. Because the things I was designing were interactive (scrolling, clicking, typing, etc.), needed to be available in many languages, and relied significantly on dynamic data (e.g. each article is different and has a different table of contents, each search query returns different results, etc.), the best way I found to effectively evaluate and communicate such designs, that lead to clear, concrete conversations about them, was through prototypes.
When the project started I built a base prototype (code), which was the Wikipedia interface hooked up to a few APIs so I could load any article (with its table of contents), in any language, as well as use the search box and get live search suggestions. I then added the ability to switch the interface itself (all of the buttons, links, etc.) to various languages. For each feature/design decision I would build a new prototype on top of that base, exploring the question(s) at hand. The prototypes often included a little settings panel in the bottom corner that allowed you to toggle between the various options being explored. Here is a relatively simple one that explores various ways of indicating the active section in the table of contents (link):
