Usability makes the world work better.

The team spent Friday morning coalescing ideas and understanding about eastern Iowans and what we might be able to do for them. Thursday we sent out email surveys and called people to ask questions. Friday we discussed our interviews and identified some information needs that eastern Iowans might have:

  • Child rearing - online forums, daycare
  • Family Activities & events
  • Housekeeping/housework
  • Family dinner & nutrition
  • Crime news & enforcement & neighborhood watch
  • Baby news & family news
  • Local business & jobs
  • Farmers market
  • Grown-up things to do
  • Local news
  • Keeping in touch with friends, family
  • Night life
  • Making news gathering easier: most news-bang for time-buck

A favorite of mine is the need to make news gathering easier.

A new study from Medill’s Media Management Center called ” What It Takes To Be A Web Favorite” shows that people can be overwhelmed by the volume of stuff on a newspaper’s website. They see a enormous list of headlines in multiple columns on a web page, and get turned off. Another study from the AP called “A New Model for News” shows that readers really want depth in the news they consume, but often don’t get that in their daily reading. People will go from web site to web site looking for stories that provide more information and read the same story or similar stories over and over.

People don’t have a lot of time to read the news, but want in-depth news and are having trouble getting it. This issue was echoed by a few people we interviewed, and our team members recognized that this is something that they personally deal with.

It’s the usability, stupid.

UPDATE:
Let me talk a little about how we came to pick these topics.

We did a limited survey of people who volunteered to participate, and called them to ask some more in-depth questions. A few people were stay-at-home moms. Around half of the people had kids of some age. The rest didn’t. We then threw ideas around in a few rounds to come up with a list of things that jived with the activities and interests of the people we talked to and received survey responses from.

It’s certainly not exhaustive and definately rushed.

Team Crunchberry has adopted an agile software development process.  I’ll be writing about our process and sharing the outputs here on the Crunchberry blog every week.  But before I get down to business, let’s talk about agile.

Au Lapin Agile Fence by daveknapik

Au Lapin Agile Fence by daveknapik

How we did things back in the day

Traditionally, the software development process looked something like this:

After realizing that you need some new software, a team of ambitious people spend a long time, say, 6 months, writing a functional specification.  That is, a fat, three ring binder describing exactly what the software should do.

Then they hand the binder to another team, the developers.  (They’re the unusual chaps who don’t leave their caves much, but who hold the magic keys to make the computers work.)  They spend a long time, say 6 months, translating the functional specification into a piece of software.

They then hand the software back, a year after it was first conceived.

“Life moves pretty fast. If you don’t stop and look around once and a while, you could miss it.”

What can happen in a year?  Twitter catches on.  The stock market crashes.  Your competitor releases a new product.  A new congress is elected, and they change the laws.  It’s discovered that margarine is healthier than butter.  Your business model becomes obsolete.  And you’ve invested nine months in a product that nobody needs anymore.

And let’s just say that you’re living in a time warp, and the world remains completely static, who’s to say that you even got the requirements right in the first place?  If you’re wrong, you just invested a year of work in a system that doesn’t work for your users.

What is agile?

Agile software development is about accepting that it’s impossible to design up front.  It’s a tough idea to shake, but by embracing the chaos, you save yourself from perfectionism.  You’ll never get it perfect.

A common misconception is that agile is a free-for-all, anarchy even.  How can you develop without a plan?  Oh, there’s a plan.  Agile development is very strict.  Everything but the requirements is super tight.  Only with discipline, can you become free.

With agile you plan less up front, and correct your course along the way.  You design a little bit, build a little bit, test a little bit, and then look up.  Are we still on course?

(Though when a team tries to do a few things agile and skip the hard stuff, you gain little, and often get anarchy.  For instance, if you design and build in short cycles, but don’t ever ask a user what she thinks, how do you know if you need to correct your course?  It’s no better than the old way.)

There are many schools of thought on the correct rules for an agile team, but they’re all based on a basic set of principles.  In my next post, I’ll describe what we’re doing to be agile.  (And if you’re dying for more reading, the wikipedia (of course) has much much more.)