Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.

Working through the iterative design process this semester, we have come to a number of realizations, The importance of early testing is immense, given the relative strength of modifications early in the process compared to late in the process. The duration of this project exposed tasks and decisions we had not previously encountered, giving us new insight into project design, rather than just implementation. With the lessons we gleaned, we of course have several elements of our approach that we would amend should we tackle the project a second time.

The strength of early testing cannot be overstated. With this second round of user testing, even with repeated requests for advice and constructive criticism, the users were reluctant to make any complaints. Compared to the overwhelming willingness of our users in the first set of trials (using paper prototypes), the value of feedback is like night-and-day. The information we gained from our paper prototyping was invaluable in making many elements of our design more approachable for our users. The information we gained from this second round of testing was negligible at best - every criticism we heard was something we had already recognized as a problem ourselves. This realization harkens back to the lecture on prototyping: one advantage of low-fidelity prototypes is they let users feel more comfortable making criticisms; high-fidelity prototypes look like they have taken much work to complete, and so users are less likely to criticize the work. The reality of this discrepancy between low-fidelity and high-fidelity products was plainly illustrated through our own experiences.

With this semester-long project, we encountered many tasks and design decisions we had not encountered before. By virtue of the project being scheduled over the whole term, rather than simply in the last few weeks of the term, we were called upon to handle design, testing, and implementation of the project, rather than the more typical just-implementation structure of other classes. As a consequence, we had the opportunity to interview many individuals working in the fashion industry, as well as run user tests with enormous sheets of paper and some pens. This new set of tasks forced us to work outside of our comfort zones, and we consequently gained a whole lot of project-building experience. Additionally, by having all the elements of this project be tied to a single project, rather than executed as separate, isolated exercises, we formed a particular bond to the product we were producing. This imposed continuity led to a much stronger final product, as we were truly invested in our product after putting in so many hours over the course of the semester.

If we were to start the project over from the beginning, the biggest element we would like to change is increasing our focus on the early steps of the project. In particular, discovering a worthy problem and designing a proper solution to that problem - with real user input - took us far longer than we anticipated. With more time focused on this task early, the subsequent elements of the project likely would have felt more natural; illustrating a clear problem and way to solve it are critical to a project's success. Likewise, as mentioned earlier, the low-fidelity prototyping yielded the best feedback from our users. If we took a second pass at this assignment, focusing even more on getting the most out of those low-fidelity prototypes would invariably benefit the final product we produced. Nevertheless, the final tasks of actual implementation and verification tests (QA testing, as it were) are still very valuable; even the best design is useless without an implementation.

In all, we believe that we gave a fair allotment of time to each task. Convincing ourselves to spend more time on the early tasks of the project would have been valuable, to be certain. However, our consistent commitment throughout the semester has yielded a product that we feel sufficiently meets the criteria of the class and of our users.