Reading seminar 2 - Linnéa Björklund

Chapter 6

Brainstorming is hard… It’s especially hard for me not to think critically during the process, to remember that even outlandish ideas are welcome. Larry Tesler’s thought on beginner mistakes are really good, like the tendency to design only for someone like you. (Stanislavsky! I never did get his method acting to work for me…)

Of the structures I like

Metaphors: Oh, this sounds cool!

Brainwriting: Sounds like a less chaotic and more controllable way of doing the “Say Yes” thing we did at one of the exercises.

Questioning: Why is an important question that often gets forgotten.

Design principles is basically deciding what your most important focus points are, and seem really helpful. But how do you decide what the most important bits are?

Brainstorming can be mysterious indeed. One of the more difficult bits, especially for engineers who are not used to think outside the box.

Chapter 7

Oh god, the constraints...How, who, with whose money? You, what skills you have and so on is really important and can tend to be forgotten. Can I really do this? 

I heard a game developer say once that if people are complaining about the load times, just put a progress bar there. That seems about right about the importance of feedback. Also, delays that you are used to are not a concerning as when something that usually works fine just doesn’t. With feedforward you need to be careful so that what you say is how the action is then perceived. 

Everything should be standardized, always! Okay, Cooper has a point with unless it’s markedly, significantly better but standards becomes better just by being a standard. Ctrl-C is in my muscle memory, I can’t change that.

Magical Number Seven, like in one of Jan Gulliksens lectures. Although wasn’t it five numbers a person could remember? Maybe that was just me having an off day.

Chapter 8

I didn’t think about the thing with Western vs Eastern cultures, and the reading order with left to right or right to left. Squint test: proof that the easiest way is sometimes the best. Sound effects can be used as feedback as well, like the clicking sound when you type on a smartphone keyboard.

We should probably work a lot on low-fidelity prototypes, but for the controller/remote we need to build a physical prototype. You can’t judge something like that that you can’t hold.

Testing, testing, testing. How will we find the time? Where will we find the users? It’s a good thing we had lectures explaining the testing bit in more detail, otherwise I’d be terrified at the prospect. (I still am, a little).

The difference between a high fidelity prototype and a final development is important, but if I understand things correctly we won't actually get to final development.