This class actually went fairly similar to my expectations, in that we worked alongside people in computer science to make a more market-ready product than we tend to design. I think as a class it was successful given the fact that we only met once a week. I think it could be much more successful as a full alternative to our regular studio, provided the cs students could take that as an alternative to some classes as well. I understand this may not be realistic now, but seeing the similarities in our programs in terms of design and the ever-overlapping boundaries of the two subjects, I think in the future it could be possible. The class could be something really incredible if we allocated all our normal studio hours to it.

As far as our final project, I was pretty happy with how far we got. I think it could always be taken further, but considering the limited time we had to meet due to our schedules, I was happy with the result. In a perfect world we would have got some mason bees or set it up near other bee boxes for testing, but between training the network and making form decisions, we took longer than expected. I still believe the idea has potential, and I’d like to explore it more, if not with this team, than individually.


Wallet Prototype, Matt + Kirk

Design #1:

The first design focused on attaching the wallet to a phone case via a clip on the phone case. This allows the user to carry both as a single entity when travelling, but separate them when they are home, and may only want to keep their phone with them.

Design #2:

The second design is a more traditional bi-fold wallet, with a few features for convenience. The first is a conventional I.D. pocket on the outside for easy identification. We also put the pockets for payment cards sideways, so chips could be read without removing the card from the wallet. The final feature was an accordion membership card holder. Because most are read by a bar code, we thought they could be stored together and the accordion scanned all at once, with the store only recognizing its own card.

Design #3:

The final design was more minimal than the first two. It is simply an accordion style pocket on the back of a phone case to store cards in. There are many pocket cases available now, but they offer limited card storage and make it difficult to access cards stored in the back.

Reading 1 Responses


I thought some of the ideas in this article were very interesting. Taylorism to me sounds like micromanagement. I don’t see why they’d analyze peoples movements doing work and then tell them how to do the job. If they are going through that much effort of analysis, why not just replace the person at that point with a machine? I think the idea of creating systems that appear complex because of a complex input is smart. The Traces room seems like an interesting idea. I wonder how augmented reality stacks up against VR in terms of the experience really convincing the user, as Traces to me sounds more like augmented reality.

Wright, McCarthy, Meekison:

This reading was very analytical of the process of experiencing and, while I agree with the more broad statements about experience such as preconceptions influencing experience, I am not totally convinced by the framework presented. I think there are too many “distinct” steps involved. I agree that anticipating an experience helps shape it, but connecting and interpreting seem like largely the same step. They explain that connecting is a pre-linguistic step, but go on to refer to a website as “sleazy”. I also think they are overcomplicating the framework by separating reflecting and appropriating, is reflecting on our thoughts of a site during the experience not making it our own experience? They also grouped connecting/interpreting/reflecting in their example, which leads me to believe that the users had trouble understanding the differences in the framework as well.