Week 03

02-11-2015

Project One introduced
Databases
PHP

Introduction

By now, we have covered a fair amount of ground. You have a little tiny web server running on your laptop (isn’t it cute?). You’ve written your first bit of PHP. You’re starting to wrap your mind around design and how it’s a strange discipline that crosses multiple domains. You’ve also, hopefully, agreed that at the center of design’s pretty little heart, it’s all about solving problems. Hopefully, I’ve also convinced you that solving problems is easier when you have seen the problem before, but much harder when you have ambiguity. Unfortunately for all of us (or fortunately if you thrive on challenges), we’re living in an era of interaction design where the lines aren’t already drawn and all we have to do is color them in. Instead, we live in ambiguity. Folks are inventing stuff all the time that are new things that provide new ways of doing things. And that means we need some tools to help us make sense of ambiguity. We saw how the early printers made sense of their medium (slowly) and how cross-disciplinary teams that look at the real needs of users make faster progress (like the development of the mouse and the GUI). You saw how Cooper argues that one of the key tools that help us make sense of ambiguity is understanding our user’s goals and developing a goal-oriented product.

Last week, we were heavier on the design of things and a little light on the nerdery. This week, we’ll shift weight back and be heavier on the nerdery than on the design principles. We’ll also kick off Project One.

Interaction Design: Aggregating Knowledge of the Customer

In many ways, successful product design is about knowing what problems your product needs to solve. The readings from Cooper were all about getting your mind wrapped around problems folks have. At that stage, any good research effort would expose way more problems than you typically can solve. Another key to good product design is about compromises. You can’t solve all those problems, so which ones do you want to solve? Now, at this point, we could make a giant list of problems and point at the ones we want to try to solve. However, that’s focusing on the problems rather than on the goals of our users. So, what we really need to do is figure out which of our potential customers are we willing to tick off.

A while ago, Apple launched the iPad. Loads of folks laughed at it and said it was just a “big iPod Touch”. Today, the iPad rakes in more cash for Apple than all of the major PC manufacturers combined make off of laptop sales. Why did folks laugh at it? Because it said “no” to a ton of things. “No, you can’t have more than one window open on screen at once”. “No, you can’t run programs that are on your Mac”. “No, you can’t have access to the files and folders on the device”. No, no, no, no. However, by making those compromises, Apple was able to scale the total size of the operating system way down so that they could have lower storage requirements on the device so it was more portable. It also meant that developers could easily port their existing iPhone apps over to it. And it also meant that that pesky file system that was constantly confusing non-tech users simply didn’t exist. You see, Apple was willing to tick off power-users and technologist in order to win over the masses and craft a beautiful product. Contrast this with Microsoft and Windows 8 and Surface. Microsoft’s whole deal is that Windows 8 allows you to have a tablet with no compromises. However, by saying “yes” to all of those things the iPad says “no” to, they’ve created a frankenproduct that’s struggling in the marketplace.

37Signals is a hugely successful web-based software company. They often argue that all great software is “opinionated”. I think so too. Apple’s iPad is opinionated. Love it or hate it, you know what Apple thinks is worth doing with it. If you don’t like that, they’re more than happy for you to buy a more expensive Mac laptop from them. A handful of years ago 37Signals put together a handsome book called “Getting Real”. Next time you have a spare couple of hours, I’d check it out. Recently they’ve posted the whole thing for free (awesome) on their website. Go ahead and read all of chapter 4: Priorities. It’s a brief read, will probably feel more like a handful of blog posts than a chapter.

http://gettingreal.37signals.com/toc.php#ch04

Welcome back. So, how do we go about figuring out what the big idea is and who our customers are? Well, Cooper has some ways of figuring that out. He calls them Personas. Hunt down About Face 3 again on the library’s website and read chapter five, “Modeling Users: Personas and Goals”.

Hopefully that went well. So, now we have a little model we can follow. First, we do on-the-ground ethnographic research with potential customers to determine their goals and problems they have in accomplishing those goals. Next, we aggregate those goals and problems into straw-man characters that we call “personas”. THEN (and this is the important part), we recognize which of those personas we are willing to lose so we can delight the others.

Project One - Phase One: Research, Personas and the Big Idea

So, reading about doing research and creating personas is all well and good. But, you don’t really know anything until you actually do it. Next week, I’ll introduce the full scope of Project One. However, this week, I want you to get started by doing research and creating personas. Project One is about creating a functioning proof-of-concept of a web-based tool that helps college students get things done. Here’s the kicker, it needs to be about helping them get only one kind of thing done. That could be a tool that helps them get homework done. It could be a tool that helps them quit smoking. It could be a tool that helps them go from being a couch potato to running a marathon. It could be a tool to help them read Moby Dick. Whatever it is, it needs to be a large goal (“get homework done”, “quit smoking”, “run a marathon”, “read a long book”, etc.) that has multiple steps (“day one to run a marathon: stretch, run for 5 minutes, walk for 3, run for 5 minutes, walk for 3, run for 5 minutes, cool down, go home”, etc.) that the user needs to track over time. Those steps should be pre-defined by you. So, in other words, if someone wanted to stop smoking, you would pre-define how they should go about doing that for thirty days into discrete steps. You prescribe what they have to do. They use your tool to track their progress.

Once you have the large vision of what kind of product you’d like to build, you need to do ethnographic research to determine the needs of your potential customers using the techniques Cooper outlines. If you need a kick-start, I’ve linked a set of the design firm IDEO’s common research techniques to unstick your brain. This research does not need to be incredibly complex or time consuming. Talking to five to eight friends who would be in the target audience of your app for five minutes each is good enough. Visiting a location on campus that’s relevant to your product (like the Rec for a marathon training tool) and watching for problems is good too. Document this research through photographs and take copious notes. From that research, craft at least three personas in Word or something similar. One persona should be a primary persona, one a secondary or supplemental persona and one should be a negative persona.

Cooper doesn’t get too specific about the format a persona should take. Every team I’ve been on has crafted them slightly differently. For this class, I’d like them to be formatted like this:

So, for instance, let’s say you chose a stop smoking tool. In your research you may have found any number of reasons folks want to stop smoking and problems they have with stopping. Some may want to stop because their significant other is fed up with it. Some may want to stop for health reasons. Some have tried to stop before, but they have friends who smoke and the social pressures were too great to really stop. Others may have tried to stop before but lost sight of the health benefits of stopping. You’d craft these into personas. Finally, for the final step of this phase of the first project, is to outline what the big idea for your tool is. Write why your tool needs to exist in less than twenty words. That’s the Big Idea. So, for instance, a quit smoking tool’s big idea might be “Everyday, comfort detoxing-smokers by reassuring them that the side effect they’re experiencing is normal.” Or, it might be “Everyday, encourage ex-smokers by showing them how much healthier they are that day.” Or, for instance, your marathon training tool might be “Provide simple, but progressively harder, training regiments to transform a couch potato to a marathon runner in six months.”

Interaction Development: Databases

Last week, you set up a server (congrats) and did a tiny bit of PHP. This week, we’re jumping into the deep end of databases. Brace yourself. It’s, honestly, not that hard, but it does require thinking with a part of your brain you may not be used to. Watch the following four videos.

Week 3 Intro (watch this video)
MySQL 101 a (watch this video)
MySQL 101 b (watch this video)
MySQL 101 c (watch this video)

PHP Troubleshooting & Deprecated Messages

This section was added after finding some descrepancies/changes from when Artie recorded his videos and what we're using today. Hopefully these videos will help you in case you get stuck. I should also mention that when I hit a road block, I typically turn to Google searches for the answer. If I don't find the answer in about 15 minutes or so, I put it on the back burner and come back to it later. If I'm still having trouble, I turn to a friend; often times another pair of eyes working on the problem is all you need. For our class, you can turn to me for help. Also, don't sell your classmates short; you should be able to turn to them as well.

PHP Troubleshooting (watch this video)
Deprecated (watch this video)

Assignment

:-)