Resist the urge to regress when a solution has problems. The only way out is through, with more knowledge. We all have a moral obligation to our descendants to be a force for the growth of knowledge, so that they may live like kings compared to us.
— Today’s email from The Listserve. They’re often good, but today’s was great.
True innovation, then, refers more to an idea’s impact, not the idea itself.
— Fransisco Inchauste in his excellent article in the second issue of Distance
Solving the wrong problem. (Taken with Instagram at Blenz Coffee)
Towards the end of a recent project at work, I came up with a technique to help us do more user-focused QA work, which was unambitiously titled the Scenario Card Game.
How does it work?
- You write down the main tasks that someone will do in your application, and print them off on something playing card(ish) size.
- Write down all the little nuance details that might make those tasks happen differently, and again print those off on something playing card sized. The best things to use here are things that a user might need, or unique facts about them that would change the task.
- Pick a task card, and few nuance cards (we used three). You now have a specific scenario to use when walking through your application. Check that everything makes sense together, if anything conflicts just put some cards back and draw new ones.
- At this point, you should actually use that scenario to walk through your app, and record the results. Were there bugs? Was it hard to figure out what to do because of the nuances?
- Make the app better. Repeat.
In our project, there was a lot of functionality, but people were having a hard time seeing how everything fit together. So we created some scenarios that outlined specific flows a user might go through, and developers/QA would walk through these to make sure everything was working. It was a pretty good system, but the scenarios were very perscriptive, which meant that after you had done the scenario once, people started seeing them as a bit of a chore, and it didn’t invite the level of creative exploration that we were hoping for.
So this game was an attempt to capture the big picture things that people would need to do, provide some constraints, but still leave lots of room for people to make their own decisions when testing them.
I like it because it combines testing the technical issues with the app (“there’s a bug on the account screen”), and usability/design issues (“how do I select a Spanish consent form?”). And it provides some more direction than “take a look at the app and see if anything is busted”.
Try it out, I’d love to hear if it helps you out on a project.
We originally tried this with a third card type: for personas. This was great because it humanized each of the scenarios, but the cards didn’t really change the scenarios in any way, so I think you could get by without them. If you already have personas created for your project, add them as a third card type. But if you don’t (we can argue about whether you need personas at a later date), I don’t think that should stop anyone from trying this out.
Create something you want to exist in the world
Evan Williams – Ten Rules for Web Startups
The whole article is good, but this resonates as the ‘why’ of building anything.
When was the last time you did something for the first time?
If you haven’t caught it already, Andrew’s got a great op-ed piece over on The Next Web about how we bootstrapped Flow. You can read it here.
Flow doesn’t fit my personal GTD workflow, but it’s great to read about local(ish) companies succeeding. The last few sentences of the article are great:
“There’s nothing wrong with venture capital. Given the right circumstances, it’s rocket fuel that can take your company to the next level. But why not try building the rocket first?”
After watching BJ Fogg’s fantastic Habit Design video last week, I’m going to be participating in his 3 Tiny Habits program this upcoming week.
You come up with 3 simple habits you want to form, submit them to him, and he emails you throughout the week to check if you’re on track, and provides suggestions for how you can make the habits simpler to increase the chances you’ll actually do them.
As per his habit design lecture, the idea here is that a habit is much more likely to be formed if it is incredibly simple and requires little motivation, which is the opposite of what most people focus on when trying to provide motivation to form habits/change behaviour.
Here are my three tiny habits for the week:
- After I finish a cup of coffee, I will fill up a glass of water.
- After I go to bed, I will open the book I’m reading.
- After I get undressed, I will put my clothes in the laundry hamper.
You’ll notice they’re all phrased in the same way: he suggests you tie new habits to well established ones, because you need a trigger to remember to do that action.
Pretty simple stuff, but it will be fun to see how well I do after a week (and then after a month or two).