It Starts with the User Story

Having recently been asked about the difference between a use case and a user story, I came up with this explanation:

Use cases detail the interactions between an actor and the system in a sequence of steps and are generally used to capture the functional requirements of a system before implementation. Because of their scope, i.e., they take in more exception scenarios, they can be too large to be used for iteration planning since they would be split across multiple iterations. Also, there is a bit of a learning curve to interpreting use cases which can leave the non-technical customer out in the cold.

A user story is a short description of a feature as told from the point of view of the user (generally your persona). They consist of one or two sentences written in the language of the user, and are used to estimate the degree of difficulty to implement (which ties in with iteration planning). At Pathfinder, we also include acceptance tests when we write the user story as a way to set out the criteria that determines when the story's goals have been met. Again, written in plain English so that both technical and non-technical team members understand what success means for that feature.

For our Ruby on Rails projects, we're writing our user stories in a format that'll help the developers convert them into automated tests using the Rails framework:

As a [role]
I want [feature]
so that [benefit]

From here we create the acceptance criteria, which we write as scenarios in a specific format (givens, events and outcomes) in order to help with writing the automated tests:

Scenario 1: Title
Given [context]
  And [some more context]…
When  [event]
Then  [outcome]
  And [another outcome]…

We'll then go on to create flow diagrams, requirements and wireframes to further flesh out the details of this feature, but it all begins with the User Story and Acceptance Tests.

The Curse of Knowledge

You can never know too much about something, right?  Wrong, at least according to a December 30th article in the New York Times.  As we become experts in a particular domain, our ability to innovate diminishes.
"Andrew S. Grove, the co-founder of Intel, put it well in 2005 when he told an interviewer from Fortune, “When everybody knows that something is so, it means that nobody knows nothin’.” In other words, it becomes nearly impossible to look beyond what you know and think outside the box you’ve built around yourself."

Reading the article, I couldn't help but think back to my own experiences with this same sort of issue.  I blogged recently about two related ideas: how interface designers are sometimes guilty of thinking as designers--when they should be thinking as users, and about the mixed bag that is competitive research, which can limit the designers creative thinking by boxing them into predefined solutions.   

Now I see that it's part of a larger problem of expertise and creativity.  The more expertise one exhibits in a particular field, the harder it is to think creatively--to so called think 'outside the box', and the harder it is to imagine not knowing what you do.  The problem affects whole companies, as a certain way of thinking becomes entrenched, and it gets harder for it to adapt to a changing landscape.  The article cites the example of Eveready, the flashlight maker, who's powers-that-be couldn't imagine that their product could be effectively marketed to anyone other than men shopping at hardware stores.

According to Cynthia Barton Rabe, author of “Innovation Killer: How What We Know Limits What We Can Imagine — and What Smart Companies Are Doing About It,” the solution for Eveready, as for any organization bogged down in its own expertise, is an infusion of outside thinking.  Bringing the so called novices--the non expert users--into the discussion at the early stages of design, weather it be product or strategy design, opens the door for new ways of thinking that experts have long been insulated from.


    
     


Powered by ScribeFire.

Wheels on a boat

A couple of days ago someone sent me a link to a flash catalog piece...

I have seen these kinds of things before.

And I always wonder why the idea gets repeated. I suspect it is because catalog based retailers see the Book as some kind of golden calf which is due irrational worship. The downfall is in the data-density difference between print and screen is the culprit; print holds so much more that the on screen imitation is irrelevant. The magnifying glass shows a smaller width than a column of type; not being able to read a full line makes multiple lines an instantly rejected experience, fomenting shockingly derisive thoughts on the part of a user.

I have seen this done better, maybe it was a Lands End version... It popped up a new window which was larger and had better controls.

The next question is what would make it work? Is there value to this format that drives otherwise knowledgeable adults to keep trying this metaphor?

If you assumed a 1024 x 768 user base, you would have a larger  beginning state. A very large magnifying glass, or better yet- zoom capabilities, would allow you to move into the page. Which returns us to the question of value.

What is it that retailers are seeking here? I think it is the experience of browsing in a lateral fashion and focussing in on some desirable or intriguing item... A simple but durable pleasure. And the notion of lateral non-hierarchical browsing is certainly a mainstay of the web.

As well, they are looking to leverage the page layout techniques that they find successful in print. This is where things break down; cluttered web pages, whether imitating print or not don’t tend to function very well for impulse surfing. If the page design were less dense with more whitespace you might be able to leverage one medium against the other. However this becomes a series of decisions as to how your product offering combine with the semantic codes connoted by the design choices this would require.

Web-o-lutions

We have seen many evolutions in website concepts and design over the years. I was talking to my colleague Matt Nolker and I noticed a book on his desk - it was the Internet Design Project book, edited by Liz Faber, published in 1998.

It showed a bunch of commercially marginal but visually impressive sites from the late nineties; back when people put a great deal of energy into brochure sites. And some of them were beautiful - let’s take Swoon as an example. Great graphics, idiosyncratic vernacular forms. Nice work, yet it just looks like a dead zone eight years later.

It made me realize that brochure sites are beyond dead. This is not an easy admission, as I have a couple languishing out in the electronic ether. The currency of websites now is their very currency. When does it get refreshed, what value can be packed up and taken away, or better yet consumed now? Immediacy is so important that aesthetics are largely irrelevant.

With the expectation of daily content, the visuals fall into two classes; an access point to an information nugget or a focussed experiment. For the everyday maintenance, static, highly mediated marketing images are pointless. Look at ten sites and email me if you find a photograph of a business person who isn’t a stockphoto. Look at 20 sites, and you will start to see the same photos recur.

What a site requires is a visual language that is extensible, and dare I say these words, fun to update.

“Webisodes” – Storytelling, Interaction and Business Strategy Converge

If you haven’t heard the term, it’s probably just what you would think. A webisode is simply a short video or cartoon clip delivered on the web. Generally there is a sequence of webisodes purposed to encourage return visits (an example of the Zeigarnik effect – see our prior blog article).

Because the content is delivered on the web, it’s easy to integrate interactivity to encourage consumers to stick around .

Take Unilever’s on-line soap opera pitch for its “I Can’t Believe It’s Not Butter!” product. The series of animated on-line “webisodes” challenged the viewer to put together clues and solve a mystery to have a chance to win a prize. Though the contest is over, you can still visit the content.

The Case for Case Studies

Currently, I've been tasked with writing up our team's recent projects, for the immediate purpose of publishing these stories on our website to support our marketing efforts. Using case studies for this purpose is a recognized, and arguably successful, way for designers to document their successes and describe the ways a good design has contributed to a good software product or website.

But I always wrestle with the narrative. What is the story we want to tell? How design, detached from the larger context, was appropriate, optimal, on-target and on-budget? Shades, perhaps, of "the operation was successful, but the patient died"?

Classically, a case study provides an opportunity for providing "an exemplary or cautionary model." A good case study should equally document the mistakes and the milestones, the lessons learned as well as the goals achieved.

Does this alter the tenor of the corporate case study? Hopefully.

Technorati

  • --