Consider Quality

Documentation Complete!

After successfully defending our thesis project at our final presentation and making all necessary edits and changes, we are happy to announce that we have completed our thesis documentation! Our book (all 195 pages of it!) can be found at the following link:

Thank you one last time to our committee, our professors, our classmates, and our families and friends who encouraged us and guided us throughout the progress of this thesis. Thank you also to the experts and consumers who provided numerous insights into consumer products and decision-making. All of your support greatly enriched the outcome of our thesis.

Building a Book

In the past few weeks we have been busy putting together our thesis documentation…a book that we anticipate will be about 180 pages! We submitted the first version of it to our committee and will be spending the next week making minor adjustments. We will post the final documentation on here once it is complete, so stay tuned!

Final Developments

Since our last committee meeting, we have made a few adjustments to our proposal for an interface and database. For one, we  decided to title our interface Quality of Purchase Connection (QPC). This play on the traditional UPC emphasizes the larger scope of our thesis – addressing the  issues of the discount culture by creating a system that connects product performance results with transparency of supply chain practices and making this information accessible to users.

We also designed a logo to emphasize connection.

We also refined our user experience storyboard to reflect the look and feel of our interface.

Since completing these two new components, we have concluded development on our project. We have a short time left and will be spending the remainder of the semester compiling a book, a presentation and a display for an exhibit.

Second Committee Meeting

We have carefully documented our progress over the past few weeks, and earlier this afternoon, we shared our recent progress during our second committee meeting. We would like to thank Dr. Ben Olshin and Will McHale for attending and providing feedback on our direction.

Our presentation started with an overview of our first committee meeting, offering a recap of concepts that we had presented and some of the feedback that we determined to be most helpful to our progress. Our earlier concepts, the consumer guide, the cellular conscious, and the personal barometer, had helped to influence our thought process and we felt that it was appropriate to restate them to explain our progress in the last month.

The remainder of the presentation focused on our prototype development, as well as gathering user feedback to refine our prototype. To explain how we came about our current model, we included the majority of our background research into existing classification and certification systems, technology, software, and user interfaces. We shared a portion of our early graphics, but focused more heavily on the latest iterations of our user interface and the overall functionality.

Feedback on our work was very positive, and we were excited to see that our recent developments were so well received. Most of the concerns raised by our committee members centered on walking both our audience and the user through our interface in an intuitive and user-friendly way. They also expressed that we should continually emphasizing the larger picture as we explain how our database and interface was developed; while the splash page and graphics are key to engaging consumers, we could not lose sight of what they represent underneath – they all tie into the economy and consumer behavior. They suggested that we map how our prototype fits into the larger context of our project in a visual sense.

Based on this feedback, we have started developing diagrams of our system and our process, and hope to tie together our work both more clearly and more concisely within the next week. From here we will revisit our graphics and user interface, but its final development would surely be accomplished with the assistance of web developers. We and our committee members agree that because the online component of our project is only a part of our project as a whole, we do not wish to emphasize it too heavily.

Refining Our Design and Developing a Site Wireframe

Now that we felt we had a strong system to communicate how purchases fall on the hierarchy to consumers and we developed the basis for the barometer, we began developing a wireframe for the splash page of our interface. The largest portion consists of a live feed of friends and their recent purchases. We wanted to emphasize the social aspect of our interface, because we feel like that has the highest potential to continually get people to log in. It also mimics the shopping experience, because from interviews, we learned people enjoy sharing their purchases with friends and vice versa. The column to the right of the feed is focused on the user’s personal purchasing and enticed the Care and Share functions of our site; the personal statistics and barometer are clearly visible in the upper right hand corner, and recent purchases which can be rated lie just below that. The Compare component, which is intended for use in the retail setting, it is not emphasized on the splash page. However, product comparisons would still be accessible and integrated deeper within the framework of the website. While the splash page is an important part of our initiative, refinement of the interface is not our main focus – it is important to note that the project is about using design to address a larger problem. The database and interface are a plan for a concept that we see most applicable to addressing the larger issues of the discount culture.

Refining Our Design and Simplifying Visuals

The feedback that we received from sharing our information design with others provided us with a clear path to improve our prototype. Although we initially tried to use a spectrum from blue to pink to show the overall level of a purchase, we found that this was too obscure. We decided instead to focus on showing the user a combination of two measures. Since we previously determined that if a product performs better than the average the daily cost was more important than if a product was local, we chose to use color to represent better than average or worse than average daily cost. This also solved our problem of a low daily cost not seeming rewarding (when, in fact, the lower the daily cost, the better). The user could learn that pink meant quality and blue did not. In addition to showing daily cost by color, we would provide the actual daily cost score. This was important since a $0.08 average was estimated. We determined we could use simple icons to show if a product was bought at a local retailer (and later if it achieved high retailer and manufacturer corporate responsibility. This system seemed to work nicely because we could also separate daily cost from whether a retailer is local when need be. The diagram below communicates this system to the user and shows how points would be gained from each purchase.

We then adapted this system to give the user feedback on his or her recent purchases. It was still important to show the user how spending feeds back into the local economy and ranks in daily cost, but this could be buried a little deeper into the splash page and brought up only when the user initiates it.

Experimenting with Visuals and Gathering Feedback

We have been developing a number of trial visualizations, which would ultimately feed into our interface. There are two main visuals we needed to flesh out. First, we needed a way to quickly convey to the consumer how any purchase ranks on the purchase hierarchy and how this ranking correlates to earning points. After all, getting consumers to understanding quality of purchase is the heart of our project. There are two components to each purchase—if the daily cost is above or below $0.08, and if the purchase is made at a privately owned, local retailer— which we had to consider when designing these graphics. We also wanted to keep open the possibility of expanding our graphics if we were to later add in retailer corporate responsibility and manufacturer corporate responsibility. Through the use of color and icons, we attempted to clarify the two measurements of each purchase and where each point was gained or lost.

Second, we wanted to show the user how his or her personal spending over time ranks on quality of purchase, as well as how it feeds back into the local economy and ranks in daily cost. This would help reinforce to the user that the two measurements used to determine purchase of quality have real effects.

As in our previous work, we felt that it was essential for us to collaborate with others outside of our project to acquire feedback on our trials in visual communication. We spoke with both fellow designers and others who may be potential users. The information that we gathered by sharing our system helped us not only to limit the visual feedback we would give users, but it also helped us refine the graphics.

Ease of use was a primary concern of our evaluators, and they expressed interest in some sort of tutorial to guide them through the system. Based on this feedback, we took steps to simplify the information and emphasize the most important parts.

Creating a Structure of Measures

Encouraging consumers to continuously interact with the system would require motivation, so we commenced work on the structure of the point system. In addition to receiving points for quality purchases, we wanted to reward users for other actions. Writing reviews is essential to the creation of the database. Although having a particularly positive or negative experience with a product is often enough for a user to write a review (as seen on Amazon) receiving points for leaving basic and extended reviews would encourage consistency. When the user is in the store and considering purchases, scanning barcodes of similar products would help us to group products by similar functionality in the database.  Therefore, we discussed the possibility of providing some benefit to engage in this act as well. Although we are still uncertain if points would be rewarded for scanning products (we don’t want to encourage mindless scanning of every item in a store just to gain points, since this would defeat the purpose), it is under consideration.

The following diagram illustrates the basic structure of the points system.

Addressing Roadblocks

As we narrowed the combination of measures that would be fed back to the user, we found that we needed to create guidelines for some the measures (for instance, how far back would the barometer measure from the current date). We hit a number of obstacles that could hamper its success, and did our best to troubleshoot these problems and create a remedy:

A lower Daily Cost means better performance, but this does not seem rewarding. We could use “Savings Earned” (the difference in Daily Cost from other similar purchases), but this would not be feasible without comparing products’ functionality. Over time, this may become possible as the system grows and encompasses more products, but at this time, we will have to find another way for the user to immediately grasp that a lower number means better performance.

The review section will become a running inventory of everything I own- that’s a lot! To prevent users from being swamped with recent purchases, products in the review section would need to be rotated each time the user logs in. Once a product is deemed “No Longer Using” or “Busted”, it will be removed from the review section and put into a backlog of the users’ purchases. If a product is reported to be “Working perfectly” or “Beginning to Break Down”, it will be removed from the rotation for a few weeks. Rotating the products could also encourage consistency with reviews by bringing up new items each time the user logs in.

Products with a really long lifespan will not have feedback for a long time.

Some product testing would be done before the database is public, but initially it will work best with products that have a lifespan of 1-5 years. However, it is possible that even just seeing that a large number of people have purchased a product and are still finding it to be “Working Perfectly” could be enough to allow others to trust it.

These issues, plus many more, will require innovative solutions to ensure that they do not interfere with the system’s ability to connect with users and influence positive change. However, we feel that by acknowledging such issues now, it will be easier to move forward in a responsible manner without overlooking potential downfalls that might result in failure or inconsistencies.

Telling a Story

Since much of our work up to this point focused on refining the details of our database (the hidden part, which consumers would not see), we developed storyboards of our prototype ideas to show what the user would experience. We had to consider the progression of the different pieces we had been discussing, as well as what type of infrastructure would be most intuitive for the user. While we had not yet shared our emerging design with actual users, we deemed the story to be an important tool to help explain our work to others in a way that is easy to understand. The slideshow below depicts our two storyboards, which will be narrated during our future presentations.