My final project experience was overall pretty good.  I really enjoyed working on the bee project.  I found the topic interesting and I learned a lot about design.  As for my CS experience, I used this class as a way to learn some new technologies that I hadn’t used before, so I spent a lot of time using AWS, specifically S3 and Lambda.  Toward the end of the final project,  however, I felt like I was spending more time working on learning than I did actually getting the job done.  I also felt that toward the end of the project, that I was not actually very useful.   We took a while to get started and then by the time that we actually needed to produce our results, we needed more from the design side than we did from the programming side.  We needed to get more done, but I didn’t know how to help.

Overall, I think the class had a lot more design than I expected.  Of course, looking back, this is dumb because clearly design is in the title of the course.  But I didn’t feel equipped as a computer scientist to keep up with what the design students were doing.  Part of this is my project choice because there wasn’t a lot of computing that needed to be done, or could be done to actually solve our problems with the time frame that we had.  The wallet exercise at the beginning of the class seemed very drawn out to me.  The computer science students seemed to be learning, but the design students seemed bored by the exercise.  Furthermore, I think that the class could benefit from some more structure.   On one hand it was nice that we could pick our topics, but on the other hand, we couldn’t get started until about 5-6 weeks in.  And at that point, we had done so little work at the beginning of the course that we were not invested in our project when we needed to do more work later on.

Machine Learning Readings

Intelligence on Tap

I think this article does a very good job at outlining some issues with designing with machine learning.  My favorite part is when he addresses “AI coming of age.”  He really hits the nail on the head about the GPUs and massive data sets paving the way to allow for machine learning to really thrive.  However, I do think that this should raise some concern.  Consider who has massive data sets available to them.  I sure don’t.  The need for large amounts of data raises the barrier of entry for designers.  If we want to utilize AI in a project, we are limited by the data available to us.  This means that we can’t just add AI powered components to a product unless the data we have access to allows it.  A possible solution is to gather our own data, but this is a catch-22.  The device will need a large number of user to get the feature to work, but in order to get a large number of users, we need the working feature.  Therefore, I thoroughly agree that services to supply AI to the common man will be available in the near future, just look at Amazon Web Services and Google Cloud, they are already starting.  But I am still skeptical about how to integrate AI into everyday products due to the private nature of collected data.

UX Design Innovation

I think that the main takeaway from this paper is that machine learning is hard to integrate into design projects.  One thing I would specifically like to comment on is that it is difficult to prototype with AI.  Consider autocorrect on your phone.  This is a design feature that is deeply rooted in machine learning, and it has gotten better over they years.  But it didn’t start out that way.  It took years to train, and it doesn’t even work perfectly now.  I machine learning is to be implemented seamlessly, in a more critical position in some other project,  then the device simply would not work before the model model is trained.  This means that early in the design process the feature will seem less powerful than it really is because there is no way that a prototype has access to the same data as a product that has penetrated the market.

A Billfold with a Twist – Matthew Wong and Zac Fischel


A Billfold with a Twist


Our target user is college aged man who leads a busy lifestyle. Although he prefers to use cards of all different kinds, he does occasionally carry a small amount of cash. When storing cards, he prefers them to be cleanly organized and easily accessible. Because his ID provides access to the local public transport, it needs to be easy and quick to flip out and show. All of these need to be packed in a slim but capable package that won’t come undone or unorganized during his busy lifestyle.

Let’s call him Dirk.



Really liked subtle details like moving the slide/opening

Fan feature would have to be really durable

I would agree that moving the slide is a good idea.  It was a feature that we realized was needed very late in our design process, but it was very obvious as we tried to use our wallet.   I also think that the slot design lends itself very well to fanning a deck of cards, an experience that many users are already familiar with.

Furthermore, it’s true that the fan would have to be durable.  We would probably use some kind of brass bushing in a final design so that it could slide easily, but still be attached.  Of course, if we actually built this wallet to be sold, we would have to do more research into the design of this feature.  Another idea could be to use metal snap buttons to keep everything together.


Response to Week 1 Readings

“The Engineering of Experience” by Phoebe Sengers

I found this reading to very interesting. Sengers’ list of heuristics for designing experiences is especially so. She suggests that even simple interactions can lead to rich, meaningful, and complex experiences for the user. She contributes the complexity to the user. I would add, however, that simple interactions very often result in incredibly complex systems, so some of the complexity must be attributed to this as well.

While I found this reading to be very insightful, I did disagree with Sengers’ repeated assertion that Taylorism is the cause of office “paraphernalia,” as Keyes calls it, being introduced to the home. I see these items as tools of convenience, and not not invaders from my place of work. Take the to-do list for example. Nobody set out to engineer my chore-doing experience, my use of a to-do list evolved naturally because forgetting to do something causes me frustration in the future.

“Making Sense of Experience” by Peter Wright, John McCarthy, and Lisa Meekison

This reading was also interesting to me, although I took issue with Section 3.2, Making sense in experience. In particular, I don’t really understand how connecting is different from recounting. In the example given, the authors use an example of “redness and flesh tones” giving the impression of “sleaziness.” Is this not relating the current experience to a past one? Is the difference between these connecting and recounting just when the analysis takes place? I’m not sure. Furthermore, why are interpreting and reflecting separate? I am not convinced that they should be. What use is it notice a feature or interaction without reflecting on the impact? What’s worse is that Section 4, The Framework in Use, uses an example that combines connecting, interpreting, and reflecting all into one example and does not provide clarification.