Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added Reflection

...

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.

Reflections

The design process of World Insider allowed us to get a strong understanding of the strengths and importance of iterative design. We realized that a thorough study of the problem we wished to solve and the target user space, tied with the knowledge that we acquired throughout the course of the class about good principles of UI design, translated without much difficulty into a very clear, unambiguous design.

After every iteration of the creation of World Insider, we realized the value of user input, which is naturally key of user-centered design. Starting with the paper prototype, which forced us to carefully layout in paper the concept and make it more tangible, we learned the value of having the initial iterations as cheap and fast as possible because feedback from users could immediately be incorporated in the design. Also, catching flaws at such early stages definitely saved us much time of coding. For instance, something as seemingly trivial as label names could be so utterly confusing for users and some of the tasks like “Find and Add friends” would become instantly faster by adding a “My Friends” tab on the menu bar, rather than having a friends panel under “User Account”.

Another interesting lesson was that even though new terminology seems to emerge and evolve constantly in the internet-world, one has to find a compromise between originality and conventionality. Conventionality usually seems to increase information scent and learnability. For example, in our initial prototype, we had the world map under the label “My World” and it took users quite a bit of exploration (~30-40 seconds) to find the map, whereas changing it to “My Map” made the search time pretty much instantaneous. 

For the computer prototype, it proved to be really efficient to have figured much of the design beforehand. Although it may have been good to decide on what technology to use at an earlier stage just to have more time to get acquainted with it, we feel in general that having made the decision to use Adobe Flash after we had done our paper prototypes and carried out the initial round of testing let us be very free and unconstrained about the design. Even though it was a challenge to learn many new technologies (since we were all new to javascript, html, css, actionscript, php, etc. before this class), having focused our energy foremost in making the design of the front-end as simple and intuitive as possible, was definitely an approach that worked well for us.

Once we came to the computer implementation, in particular the back-end, we did realize however many constraints imposed by our choice of technologies . An advantage of the waterfall model though, was that having already iterated a few times over our design, we found it easy to detach from our code, and keep making changes to our initial design. For instance, we quickly learned that it was so much easier to deal with data grids when coupled with a database in the back-end, and although visibly it was not as appealing as we would have liked, we chose to use datagrids extensively.  This is where perhaps a deeper understanding from the beginning of Flex, php and Database management might have been helpful since we could have perhaps invested time into making our own components that would look closer to our design, rather than having to conform to using datagrids, but we take this as a great learning experience.

User testing was also another great learning experience, not only because of the feedback, but the process of designing the briefing, story board and scenarios, also proved out to be really helpful. It required us to carefully think about the goal of the website, and articulating the steps we envisioned users doing most frequently really kept reminding us that we are not the users. Besides we would always be pleasantly surprised by positive feedback, and all the constructive feedback helped us give direction to each iteration. In particular, after the heuristic evaluation, we compiled an extensive list of all the things we could change. If we were to do it again, perhaps we would have prioritized a few of the issues and fixed them really well instead of trying to do all of them. In the end though, for time constraints we did have to make some compromises, such as deciding to implement at the very last all picture capabilities, including profile pictures, friend pictures, and trip pictures, but we don’t regret it because we did not want to sacrifice functionality and design clarity for adding extra features that we probably wouldn’t have had time to perfect. However it was a crude reminder of how creativity in a website and functionality as rich as that of well-established magnate websites such as facebook is hard to attain in the first few iterations.

We look forward to continuing to experiment with our World Insider, and continue spiraling out in our design of World Insider, especially to bring in much of the functionality we envisioned like adding pictures and facebook capabilities.