Tuesday, January 28, 2014

INFR 4350 - User Research Methods

One of the main concepts we discussed last week in class was how research into user centered design could be conducted. Over the week I encountered two types of these research methods. I learned a lot about the two research methods and I thought that it was a cool coincidence that they both occurred in the same week that we learned about them.

For those of you that don't know, I work as a Peer Tutor at the Student Learning Center (SLC) found on campus. The SLC also manages an online student learning portal called NOOL. Since I've started working on at the center, NOOL went over some heavy redesign. So last week I was invited to participate in a focus group to figure out how NOOL can be improved before it relaunches.

It's supposed to be an infinity sign in the middle. (NOOL)

The focus group itself was pretty small. Aside from the conductor there six other UOIT students from various programs such as game development (myself), business, science, engineering and so on. I thought that having people from different programs was pretty important because it gave the group different perspectives.

For example, I'm a programmer and as a result a lot of times when I'm looking up information online, it's tailored for programmers and programming concepts. So my idea of what a good learning resource site should look like was different from what other students wanted.

Plain text, nice and skimmable. (Autodesk)

I thought that it was pretty nice to have different opinions on the design of the website. From a designer's point of view it would be useful to hear opinions clash so that they get a better understanding of what their potential users want and how they can deliver that.

The next research method that I experienced was observational research. I participated in the Global Game Jam this last weekend and we had a large group of people working on our game. We split it up into essentially three divisions: programmers, artists and level designers.

A level design drafted up by one of our designers.

Once we got the core scripts created and implemented, we gave the project to the level designers to create their levels. Unity makes it really easy to make changes on the fly, so after their levels were done the level designers did observation tests to see how their designs would be received.

When I played through some of the levels, I would play the game in a way that the level designer didn't anticipate, such as skipping a portion of the level by jumping from a specific platform to another. As a player I didn't think too much about it, but the designer would make a note of all the things they didn't expect and take them into account when tweaking their levels.

A screenshot from the finished product.

Through observational research by having other people play through their level designs, the designers were able to improve and fix up their levels after taking into account how players play their game. Overall I feel that a simple user research technique like that allowed us to make a better game.

Monday, January 20, 2014

INFR 4350 - The Human Factor in Software Development

Well, it's been a while since I've written a blog. It's a new semester and with it comes a new set of courses, so blog writing begins again! One of the courses I have this semester is Human Computer Interaction, or HCI. HCI is a topic that I'm pretty interested in as it deals with the understanding of how the relationship between humans and computers can be improved.

Obviously, the human factor in that relationship is pretty important. The last week's lectures had a large focus on human-centered design, or the tailoring of products to human needs and wants. In order to develop a good game or piece of software, you have to do user testing. Back in second year, my GDW game was called SHFTed and I did some user testing at Level Up.

People testing out our game at Level Up.

I remember that at that point, I was really happy with the state of the game that our team created. When we brought it to Level Up, we had a lot of people play it. More importantly, we had a lot of external people play it. The reception for the game was generally positive, but we also got a lot of feedback on the design of the game.

Having an outside perspective on your game really makes a big difference. We got feedback on things that we never really thought about and discovered issues that we never saw. Taking that feedback into consideration, we took the week afterwards to fix up our game and to polish it up. The result was that it made our game even better and more fun for when we presented it at UOIT GameCon.

The end result of our game.

A more recent example of when I realized user testing is really important was during the winter break. I worked for the company Digital Leisure over the break creating a Maya plugin in Python to smooth out the design-to-art workflow.

Now, I never worked in Python before, let alone create a Maya plugin. However, I learned about Maya in school and made some (terrible) models in it before, so I understood the general pipeline and workflow in Maya. As a result, when I was designing the plugin I had a good idea of what I thought would be useful or important.

I don't like Python. But that's a rant for another blog post. (Wikipedia)

So I started working on this plugin, and I was actually pretty excited about XYZ features and meh about ABC. When I showed it to the artists though, I often found that they glossed over XYZ and liked ABC a lot more. They also gave me suggestions to do IJK, which I often either didn't think they needed or didn't think of.

That was a pretty interesting experience for me. It made me realize that despite thinking I knew what my users wanted, in reality they often wanted something else. It really showed me the importance of user testing and constantly getting feedback from the users. If I never got feedback from them, I would've gave them a system that they just didn't want or need, which is just a big waste of time for both parties.

Fun fact, the Maya script editor is also a giant waste of time. Charcoal is so much better. (Autodesk)

Going forward, I'm definitely going to be actively seeking out more people to test out my creations. Especially if they are designed for other people to use. I'm hoping this course will expose me to new ways to improve my designs.