teehan+lax / Lessons in Learning: Creating a Functional Prototype

캐나다의 디자인회사 >teehan+lax는 최근 >hyper-lapse라는 흥미로운 작업을 보여준 곳입니다. 관심이 가서 살펴보다가 괜찮은 내용이 있어서 번역을 해봤습니다. 외국 디자인 회사는 어떻게 일할까? 하는 궁금증을 가진 분들이 많은데, 사실 프로세스 자체가 특별하다기 보다는 계속 더 좋은 방법을 시도해보고 적용해나갈 수 있는지가 여부가 더 문제가 아닐까 싶습니다.

원문은 >여기서 볼 수 있습니다.

————-

Lessons in Learning: Creating a Functional Prototype
January 16, 2013 

Modern web and browser technologies are now capable of supporting features that give us the ability to build websites that go beyond hyperlinked media. In a recent project, we had the opportunity to create a web-based product for a client. In an effort to create a realistic prototype for the web app, we decided to explore technologies extending beyond the HTML/CSS/JavaScript realm. We wanted to take advantage of the client’s existing API and integrate the content from their database, rather than create static templates with placeholder content.
모던 웹 브라우저 기술들은 이제 우리로 하여금 기존의 hyperlinked media를 뛰어넘는 웹사이트를 구축할 수 있게 해주는 기능들을 지원하고 있다. 최근의 프로젝트에서 우리는 web-based 작업을 할 기회를 얻었다. 현실적인 웹앱의 프로토타입을 만들기 위해서, 우리는 HTML/CSS/Javascript 영역을 뛰어넘어 확장하는 기술들을 탐험해보기로 하였다. 우리는 클라이언트가 제공하는 API의 장점을 살리고, 컨텐츠를 그들의 데이타베이스와 통합하기를 원했다. 단지 정적인 템플릿과 placeholder 컨텐츠 말고.

Getting to this goal required a change to our workflow. The traditional approach of separating tasks by disciplines into progressive phases would not work for this type of project; we had to adopt a more agile approach.
이 목표를 달성하려면 우리의 workflow를 변화시켜야 했다. 한 단계씩 분리되어 작업이 진행되는 기존 방식의 접근은 이런 종류의 작업에 적합하지 않았다. 우리는 새로운 agile 방식에 적응해야 했다. 

Traditional vs. Agile

In a traditional workflow, tasks are based on disciplines and are scheduled one after another. First the analysis and planning is completed, followed by design, development and QA. The finished product is then presented and delivered to the client. Although there are rounds of feedback, revisions and collaboration within this workflow, for the most part each discipline is tackled separately until completion before the next task can start. Progress is measured by which activity has been completed.
일반적인 workflow에서 분야별로 각 task들은 다른 task 뒤에 위치하고 있다. 먼저 분석과 기획이 끝나면, 디자인과 개발 그리고 QA가 뒤따른다. 마무리된 제품은 클라이언트에게 납품된다. 이 workflow에도 피드백, revision, 협업 등의 과정이 있지만, 다음 단계가 시작하기 전에 각 과정의 대부분은 완료될 때까지 여러 문제로 씨름하게 된다.

In an agile workflow, instead of planning around one complete deliverable, this process breaks down the requirements into key features. Workflow is managed by the priority of features, which are iterated and built on rather than creating one final product. Each iteration is shared with the client to review. Progress is measured by how many features have been completed. Tasks may still be separated by disciplines but can be worked on concurrently.
Agile workflow에서는 기획을 먼저 다 마무리 짓지않고  key feature 단위로 요구사항들을 쪼갠다. Workflow는 feature들의 우선순위에 따라 관리되고, 하나의 최종 작업을 만들지 않고 feature들을 반복적으로 계속 다시 build하게 된다. 

Technology used

There are manymany tools to choose from but after some research and testing, we settled on angular.js, a JavaScript MVC, to create a dynamic web application. We also used Twitter Bootstrap and LESS for fast prototyping and more efficient CSS as well as Git for version control.
여러 연구와 테스트로부터 우리가 사용할 수 있는 아주 많은 툴들이 있었고, 우리는  Angular.js, Javascript MVC를 사용해서 다이나믹한 웹어플리케이션을 만들기로 했다. 우리는 또한 Twitter Bootstrap과 LESS를 사용해 fast prototyping을 하고 CSS와 Git의 버전관리를 이용했다.

Lessons Learned

Wins

  • Being able to use dynamic content makes it easier to identify functionality issues and see how the designs work in context.
  • Different activities can run concurrently, tasks can overlap. There still needs to be some lead time between tasks but not as much as required in the traditional flow.
  • Code is not used to fake the functionality of features just to be tossed out and replaced in production. Instead, the code is written to be production ready and can be delivered and used as-is.
  • If cost or time becomes an issue, thoughful decisions can be made about which features can be left out.
  • If there are changes to the project timeline, the prototype may not have all of the planned features but will still be functional.
  •  다이나믹한 컨텐츠를 사용할 수 있게 되면서 기능적인 이슈를 더 쉽게 해결할 수 있었고, context에서 디자인 작업이 어떻게 진행되는지 알 수 있었다.
  • 서로 다른 여러 활동이 동시에 진행되고 오버랩될 수 있었다. Task들 사이에 약간의 시간이 여전히 필요했지만 기존의 workflow만큼은 요구되지 않았다.
  • 기능적인 요소들이 버려지거나 대체되는 fake code를 만들지 않았다. 대신 코드는 실제 작업에 쓰일 수 있게 만들어졌고, 그 상태로 마지막까지 적용되었다.
  • 비용이나 시간이 이슈가 되었을 때 어떤 feature가 제외될 수 있는지 신중한 결정을 할 수 있었다.
  • 프로젝트의 일정에 변화가 생겼을 때, 프로토타입은 계획된 feature들을 다 가지고 있지 않더라도 여전히 유용했다.

All of these things let us make decisions by actually using the product. Usage is oxygen for product design.
이 모든 것들로 인해 우리는 제품을 실제 사용해보면서 결정을 내릴 수 있었다. 프로젝트 도중에 실물을 실제로 사용해본다는 것은 제품 디자인에서 있어 산소같은 요소이다.

Challenges

  • Getting used to tearing down code and designs, rebuilding and redesigning over and over again is a hard adjustment. You have to learn how to be flexible and expect the inevitable.
  • Deciding where to draw the line between creating a pixel perfect prototype versus a functional prototype when time becomes a factor can be tough and often happens on a case by case basis.
  • The project team and client have to have the resources to create and maintain the technology used.
  • 코드와 디자인을 분해하고 다시 구축하는 일이 반복되는 것은 힘들고 세심한 조정이 필요한 일이다.
  • 시간이 중요한 요소가 되었을 때, 보기에 더 좋은 프로토타입과 기능적인 프로토타입 중에 어떤 것을 만들지 결정하는 것은 어려운 일이고 때로는 경우에 따라 결정이 달라질 수 있다.
  • 프로젝트팀과 클라이언트 모두 새로운 것을 만들고 유지할 수 있는 쓰이는 기술적인 리소스를 가지고 있어야 한다.

Managing many concurrent activities and making informed tradeoffs takes a lot of executional discipline.
 동시에 진행되는 많은 활동들을 관리하고, 변경사항에 대해 계속 관심을 기울이는 것은 많은 실무적인 규칙이 필요하다.

As with any process, tool or technology, one solution may not work for all situations. There needs to be some experimentation to find the right fit. Despite some of the challenges using a different approach, the project was a success because the final deliverable had more value than what would have been accomplished using the traditional approach.
어떤 프로세스나 툴, 기술이나 하나의 솔루션은 아마 모든 상황에서도 항상 유용하지는 않을 것이다. 적절하고 올바른 방법을 찾기 위해서는 약간의 실험이 필요하다. 기존과 다른 방법을 시도하는 도전에 대한 어느 정도의 논란에도 불구하고, 프로젝트는 성공적으로 완료되었고, 기존의 방법을 사용해서 성취할 수 있었을 결과보다 더 가치있는 성공을 거두었다.

We’re excited to continue in this direction because we strongly believe it will help us get better at making digital products and services that people love and want to use.
우리는 이 새로운 방법이 사람들이 좋아하고 사용하기를 원하는 디지털 프로덕트와 서비스를 만드는데 더 도움이 될 거라고 믿고, 계속 이런 시도를 하려고 한다.

Reference: http://www.agile-process.org/

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *