« Reverse-engineering user reviews | Main | iPhone and the Dog Ears User Experience Model »
What comes after usability?
The software development process usually drives what users get. In the beginning, there was the Waterfall model based on a world where everything is known in advance and specs don't change (i.e. a figment). Users got something functional, just not what they wanted or needed by the time the software shipped. Then came various spiral flavors: Iterative, Agile, XP. Unlike waterfalls (which run in one direction and don't back up), spirals can produce software much more likely to match what users want. Spirals support usability, and usability drives the need for spiral development. But what comes after usability? And will new development approaches emerge to support it?
So, I guess I'm really asking two somewhat-related questions. This is just a first crack very rough look for me, so please feel free to hack away, remix, rearrange, and add your own more credible (or just as wild-ass as mine) ideas.
After Usability comes Flow
"Thanks for giving me something useable, well-designed, and useful. Now, can you make it as engaging as a game or sport? Can you keep me so immersed that time and all the clutter of daily existence drops away? Where I'm under a spell that's never broken by an intrusion from the software itself? Where the challenge is NOT in using the software, but in what I'm using the software TO DO?"
Even if users don't start demanding Flow... it's a huge opportunity and advantage for those whose products support it. (And one of the key attributes of products with passionate users)
To learn more about flow--and I strongly encourage us all to make a study of it--some resources include:
An excellent overview of flow theory by award-winning game designer Jenova Chen, including an enchanting, seductive game that implements a theory of flow.
Game design guy Raph Koster's blog, and don't forget his excellent book on A Theory of Fun.
And two of my earlier posts on this:
User Enchantment and Cognitive Seduction.
What about development models?
I really have no idea. People like Jonathan Kohl and Jason Gorman are talking about Post-Agilism, but there's no agreement on what that looks like or even means. Some see it as nothing more than the practical approach of taking the best of what works without being such a hard-core Agile zealot. In other words, "agile" with a lower-case "a" rather than The Church of Agile.
And in this post I'm really talking about the web-app world, not necessarily big corporate enterprise systems that don't have the pressure the new class of web-apps (or games) have. It's the new web-app development that needs ultra-fast releases and near-instant responses to user needs (not necessarily user requests). Is there a Post-Agile model that works for this? Or is just faster, tighter iterations?
Do we speed up the spirals or do we do something completely different? How does this fit with things like, say, the 37Signals somewhat controversial Getting Real approach? I say "controversial" because some see it as nothing new at all, or worse--a fly-by-the-seat thing that absolutely Does Not Scale, or...
So, what do you think?
(And if I were smarter than I actually am, I would have done this artwork more napkin-sketchesque so you'd realize just how rough my thoughts are on this. As if that wasn't obvious...)
Posted by Kathy on January 7, 2007 | Permalink
TrackBack
TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a00d83451b44369e200d83462f84469e2
Listed below are links to weblogs that reference What comes after usability?:
» Développement itératif d'un outil simple : le gourdin from Freestyle
Kathy Sierra de Create passionate users s'interroge sur l'évolution des processus de développement informatique et établit une sorte de pyramide de Maslow de l'utilisateur : À la préhistoire, c'est-à-dire il y a dix ans, l'utilisateur [Read More]
Tracked on Jan 8, 2007 3:47:15 PM
» Fundstücke zu Social Media News Release, Corporate Blogging, Web2.0-Design und Flow from Moderne-Unternehmenskommunikation.de
Autor: Jörg Hoewner
Endlich hatte ich mal wieder Zeit, meine Feeds systematisch zu durchforsten, von den über 22.000 ungelesenen Posts in meiner Vienna-RSS-Reader-Darstellung blieben am Ende einige interessante Linktipps übrig:
Die Social Media News R... [Read More]
Tracked on Jan 13, 2007 10:22:55 AM
» Saturday Links for the Week -- January 13, 2007 from How to Save the World
[Read More]
Tracked on Jan 13, 2007 8:01:56 PM
» Why would anyone purchase online learning? from PILOTed
Why would anyone buy or use any product? That’s not a rhetorical or an easy question. If you ask the purchaser or user of a particular product, you might be able to get a very specific reason. But, the more [Read More]
Tracked on Jan 19, 2007 10:54:16 AM
» Speaking the same language from Counting marbles in the sky
I have to admit, Im a great fan of Calvin Hobbes. When I saw this strip about the snacks and the cookies I recognized a situation which is very common in our business: you talk to the client or the developer team, hopefully a meaningful ... [Read More]
Tracked on Jan 29, 2007 1:59:02 AM
» Welcome to the Groove Advisor! from Groove Advisor: Work in progress
Readers probably know some of the Groove history , and know that Groove was acquired by Microsoft in [Read More]
Tracked on Jan 30, 2007 1:18:41 PM
Comments
For me, the difference you're articulating is the difference between usability as a discipline and user-centered design as a philosophy.
Usability is a huge step in the right direction - but its practitioners tend to focus on measuring the completion of tasks. What's the metric for the user being in flow? It's probably often related to time spent in the task or reuse/revisits (assuming those are goals) - but that doesn't quite get it.
How do we capture that info without resorting to "tell us what you think" post-task surveys?
The only way I know how to design for flow is to immerse myself in the user's world to the extent I can bear and my clients can wait for. The more I study and empathize with my users and their goals, the better I understand how to design for flow.
I'm reminded of how I feel when I watch usability tests. What's important isn't the report afterward - percentage of tasks completed and whatnot. It's what I gain from watching and empathizing with the pain I've inadvertently inflicted on the users with my assumptions, seeing in sharp relief the degree to which I've inevitably embedded my own preferences and biases into the design.
So I'd say usability has the tools to get us there, but the design team has to engage its own emotions in order to understand what they're seeing and take appropriate action.
And there's room for us to purposefully elicit and encourage that emotional connection with the users.
Another thought that occurs to me: The best design ideas often come from people designing what they themselves want, right? That's a shortcut way of ramping up passion.
Does anybody remember the book _Descartes' Error?_ Fascinating study of brain injury and how emotions are required for good decisionmaking.
Posted by: Susan Price | Jan 8, 2007 9:06:15 AM
I think you're moving from developers being distant from customers (waterfall), to developers being close to customers and responsive to them (agile), and the "flow" step is when customers become developers.
For this to work, you need to include features to allow non-technical customers to build parts of your application and share these with others. Technical developers should produce the architecture that allows them to do this.
Posted by: Richard Jonas | Jan 8, 2007 9:22:01 AM
Great post! I absolutely love your focus on flow. I met Dr. Csikszentmihalyi a few times while at Claremont McKenna College (taking a few courses at Claremont Graduate school where he teached) and have been fascinated by flow ever since.
I've been working hard to find the answer to your question about the development process necessary to capture flow in a web application. Up to this point I can say that the only thing that really works for me is to do dozens of usability tests on almost every little feature. This doesn't mean calling people in from the streets. I just call someone over from the other side of the room and pay very close attention to their body language as they use the application.
I can't say I'm very good at it, but I think I am getting better. You can see some of the fruits of my efforts in my two web apps:
My current belief is that you need to apply an 80/20 rule of sorts where you isolate 20% of your app that is the most fundamental user experience and spend 80% of the time trying to get it perfect.
In any case I think it is a very fundamental question to the future of web application (maybe software in general) development.
Posted by: Jared | Jan 8, 2007 9:27:15 AM
"Jonathan Kohl and Jason Gorman are talking about Post-Agilism, but there's no agreement on what that looks like or even means."
Let's all find out together. :) Jason and I both independently thought of the term "post-agilism" because we were afraid that the industry would stop innovating. We both felt stuck in the "Agile" mode, and noticed others who had worked through the Agile movement, and then said: "That was fun. Some things worked well, others not so well. What's next?"
Post-agilism as I have witnessed it is like you mention, a reaction to dogmatic zealotry, like philisophical skepticism. I've also seen behavior towards processes that is like scientific skepticism, or falliblism, that seeks to question process claims through investigation and scrutiny. That's the "process skepticism" side. "Does this process 'X', as one of many tools I can use help us reach our goals of satisfying and impressing the customer? If not, why? What can we try that might work better?"
Jason and I are both hoping that the neologism "post-agilism" will help spur people to try out new ideas, and help create the new future of software development. We have a long way to go before we can say we have arrived, and discovery and innovation are a lot of fun. We can learn a lot from those who came before, including the Agilists.
Thanks for the link, and keep up the great posts.
-Jonathan
Posted by: Jonathan Kohl | Jan 8, 2007 9:47:09 AM
To me this seems to be an internal business issue as opposed to a user centred design issue. Whether or not your product/service meets user needs should not be dependent on what development model you use.
I'd re-phrase 'Development models affect users' to 'Users don't care about development models'. Users just want to get things done.
I would advocate an approach where you *plan* to involve users both at the beginning, and a few times throughout, the development lifecycle. Additionally, users should also be involved 'when it feels right'.
I appreciate that ‘when it feels right’ is not very scientific, but if 5 people in a business are debating whether something is easy to use, or useful, or enjoyable, then it should 'feel right' to involve users. If these debates happen every 3 weeks, then get a small number of users in, observe them using the product/system, and iterate. If the debates happen every week, then get a smaller number of users involved and iterate faster.
On Flow: Sometimes Flow is important, sometimes not. I don’t think it should always be an aspiration for the development team. If the user’s goal is narrow and time sensitive e.g. to pay a bill online, then entering a state of Flow is arguably not a good thing:
"I lost track of time because I was having a whale of a time paying my bill online".
:)
On the flipside, if the goal is broad e.g. ‘book next year’s holiday’ or ‘check out my friend’s photos’, the state of Flow is indeed the ultimate user experience.
Posted by: Paul Adams | Jan 8, 2007 10:27:30 AM
I want to slip something in beneath your base need Kathy. Before functionality, it seems to me that we increasingly want speed of response/achievement - not in terms of completion but in terms of seeing progress - if there's a time lag anywhere, we get frustrated. If you don't believe me, Bill Gates says as much in his Scoble show chat today when revealing that the key customer gripe with IP TV etc is the time it takes to change channels. The function is there, it just doesn't work fast enough.
Posted by: John Dodds | Jan 8, 2007 10:38:24 AM
For this to work, you need to include features to allow non-technical customers to build parts of your application and share these with others. Technical developers should produce the architecture that allows them to do this.
If you're talking about something like the Flickr API, then I'd agree with your comment, but never make the mistake of thinking that the average end-user is going to want to do this as a regular part of their interactions with your application.
Posted by: fiat lux | Jan 8, 2007 10:50:08 AM
I agree with an earlier comment that the most obvious way to go beyond "spiral" models is to have the actual users create the software.
The problem is that somewhere in the hierarchy of user needs is "effortlessness". Even a partial or inefficient solution that I can use right now without any extra work is probably better than an "optimal" one that makes me build my own software.
So that leaves us with sped-up spiral (agile, post-agile, whatever) in order to deal with a constant stream of user requests (some of which will be wrong, but quickly rolled back in the next upgrade).
I think this model is unlikely to work except in areas where constant change is tolerable.
And do you really want a new version of Word, Outlook, or even Flickr every day or even every month?
The best way to create flow in my opinion is to dedicate time learning the problem domain and environment of the users, and doing everything possible to create invisible happiness.
Invisible happiness is created when something just works without the user being aware that a "feature" is being used. Like the way your web browser does a "redirect" automatically when necessary, or when your new radio auto-detects channels that are accessible.
Posted by: Dave Churchville | Jan 8, 2007 10:55:47 AM
A word on behalf of the poor waterfall: your list is a great exemplifier of why in some organizations (like mine, here in the bowels of Oracle), waterfall is king. For companies where product complexity means 18-month development cycles, where each and every feature developed has half a dozen stakeholders with barely-overlapping needs, and where a missing, buggy or ill-conceived feature might cost you two to five years of 7-figure sales deals, production really is king. It may lead to exactly the type of Big Boring Business Software that you're not generally talking about with your blog, but for some folks, the waterfall is sadly appropriate.
At the enterprise-level, spiral development is really just sequential waterfalls. Your Maslow-esque functionality-to-flow spectrum is absolutely true, and with smaller development organizations, every effort should be made to be out there on the flow-focussed edge. In some places, getting the coordinated functionality right is so hard that the best that smart people can achieve, sadly, is just making sure that the features are delivered correctly. But if only more of them(us) would ask your sainted question: "How does this help our user(s) kick ass?"....
Posted by: JimDesu | Jan 8, 2007 11:01:15 AM
I'd like to see the next development in lifecycle models not be "post agile" but "helping people implement agile." I don't think the Church of Agile has yet done the necessary work to help actual businesses in the real world (of larger size, geo-diversity, etc.) learn how to agilate their organization.
I'm a big fan of agile practices, or "acknowledging reality" as I like to call it. But, for all the why-you-should-do-it and the what-it-looks-like-when-it's-done, there's not nearly enough here's-how-you/we--do/did-it. Unless I'm looking in the wrong place, there's a lot more rhetoric and success stories about agile than there are tools for real businesses which might be big, messy and political.
Maybe it just won't work for them, in which case we don't yet need post agility so much as we need agility's bigger cousin. Let's slow the roll on the next wave until this one's crested--which I think it is far from doing.
Posted by: Justin D-Z | Jan 8, 2007 11:07:34 AM
Web-based applications have the advantage of "permananet beta" that has been so abused.
Why not offer user accounts on the test environment, but keep that test environment separate?
Online multiplayer games have done this for some time - play on the "beta" server, and you get all the cool goodies before everyone else. There's just a chance your character will be deleted.
So, have Google Mail, then have Google Mail Beta (which has new features almost daily, some of which make it and some of which don't).
Posted by: Ben | Jan 8, 2007 12:57:41 PM
A long while back, I heard a company promote the following analogy. The original model has always been the waterfall. The iterative spiral model was described as a "whirlpool", in keeping with the water theme. These folks suggested that the whirlpool would replaced with the "jacuzzi" model, which consists of lots of tiny whirlpools all over the place, each doing a tiny little part of the big job, even though it looks chaotic from a distance.
Posted by: Kiaser Zohsay | Jan 8, 2007 1:03:30 PM
I think if the term post-agilist takes hold I'm going to be sick.
Interesting post though and I'll be checking out your linked resources.
Posted by: James | Jan 8, 2007 1:39:58 PM
FYI-- I am currently in San Franciso at the MacWorld conference, so my online time is very sketchy. I added a few comments here, but I'm not sure how much I'll be able to do in the next three days.
=======================
Thanks everyone for adding to this. One thing that's really confusing me is the relationship between flow and ultra-fast releases. Are they orthogonal? Or in some cases incompatible? Or in some cases (I suspect) is the ultra-fast releases that help create flow -- given the right application, where cognitive seduction is enhanced incrementally with each new nano-release.
Jonathan: Thanks so much for jumping in here. I'm glad you're thinking about this (and talking about it, and getting the rest of us to think and talk about it). I especially appreciate that your goal is forward innovation more that it is about any one specific direction.
John: Good point -- I put appropriate response times in with usability, and certainly they're an absolute prereq for flow. So, yes, I agree that it doesn't matter if the thing does what you want if the performance is so slow that it takes you out of the experience (or even just gives you time to drift away...) I realize that performance is relative to the application -- latency in a midi application is deadly, and even tiny fractions of a second can degrade the experience. On the other hand, a lot of us have gotten used to much greater lag times when bandwidth is the bottleneck...
Posted by: Kathy Sierra | Jan 8, 2007 2:38:07 PM
This is all fantastic stuff and I have insisted that all my friends and colleagues visit this site regularly. But, as an Englishman, I feel I should point out that "the bouncer will toss you" has some very unsettling connotations in the UK depending on you sexual preferences! ;-)
Posted by: Ian Green | Jan 8, 2007 3:45:51 PM
Agile is a risk aversion strategy. you can't go too far off track if the iterations are frequent. The customer wants to add a feature half way through, they also get to choose what should be dropped. etc...
But over here at Passionate Users we like to talk about Death by Risk Aversion.
Can we iterate our way to innovation? Is an exercise in ass covering the way to kick ass?
Posted by: Yo Baby | Jan 8, 2007 7:10:43 PM
Wait. Where's the Dialogue?
What we've been doing at PLANET ARGON is taking the principles of the Agile manifesto and finding a way to accelerate collaboration between clients, users, and our design and development team through a cool tool that we call Dialogue-Driven Development.
Posted by: Robby Russell | Jan 8, 2007 7:36:20 PM
Nice stuff, Kathy. Flow equals invisibility or transparency, where the tool simply disappears. Beyond flow (we should be so lucky) comes anticipation. I recognize how hard it is to make software and services that reflect this hierarchy, but shouldn't we expect more?
Posted by: Tim Peter | Jan 8, 2007 10:12:09 PM
Warning: Possibly feeling grumpy this morning :-)
But gosh-darn it I /so/ hate the phrase "post-agile" since it's meaning always seems to map on to "agile done right" as far as I'm concerned. Grump. Moan. Etc.
I'd also disagree that agile approaches are risk-aversion strategies. They are risk management strategies - which means (if done right) they let you take /more/ risks since you are more in control.
I know the agile teams (and by "team" here I'm including the customer) I've worked on are much more open to trying out ideas an experimenting since they're doing it in a safe environment.
Posted by: Adrian Howard | Jan 9, 2007 4:47:35 AM
I like Dave's comment:
The problem is that somewhere in the hierarchy of user needs is "effortlessness". Even a partial or inefficient solution that I can use right now without any extra work is probably better than an "optimal" one that makes me build my own software.
And thing that Adrian really hit the nail on the head with his remarks on the phrase "post-agile" and agile as risk-management rather than risk-aversion. Using the term often represents a misunderstanding of what it means to work in an agile way. Much of what you describe as post-agile is just doing agile well.
I am becoming a believer in this site, very timely posts on great subjects. Kudos.
Posted by: Ben Edwards | Jan 9, 2007 9:22:56 AM
I am not sure "usability" is a cracked problem. I think the word itself is plain wrong.
Posted by: Mario | Jan 9, 2007 10:07:12 AM
This is very timely for me as just last week I decided to write an article on how Flow can be used to improve e-learning. I'm still at the thinking and research phase, so my ideas are not extremely well reasoned at this point.
I found a study by Ruth Rettie (An exploration of flow during Internet use http://www.kingston.ac.uk/~ku03468/docs/An Exploration of Flow during Internet Use.pdf) where she lists this finding -
Respondents felt that flow was more likely when they were activley involved (e.g. selecting options, communicating) and getting immediate responses.
So I am exploring the idea of 5 "concentric circles" for designing e-learning. Circles are numbered from 1 (innermost) to 5 (outermost).
Circle 1 - New Information
Circle 2 - Prerequisite Information
Circle 3 - Help, Analogies, Examples, Etc.
Circle 4 - Advanced Information
Circle 5 - Links to Additional Information
Some learners may be able to work through the material just using Circle 1, others might need Circles 1-3, and others may need/want all 5 circles. The basic idea is that everything a learner needs to learn is available and only a click or 2 away. No need to search the web, send an email asking a question, look in the book --- everything is available within the lesson.
Now will this lead to Flow? I don't know, but I think flow is not possible without it.
I see a great deal of similarities between designing a program or system and designing a lesson or course, so I hope this was relevant.
Posted by: Rich | Jan 9, 2007 11:49:53 AM
I think instead of Flow Model it should be called the Fluid Model because software should be more like water and shape itself to a users needs and task objectives as s/he using the system.
I see a system where a user clicks on a particular file lets say a word document or picture and instead of an application launching and taking you to another screen, the software launches around the the file with a your latest used commands. This then affords better interaction with the files and systems. If a user chooses to launch it at full screen the software allows them. If the software is not installed in the system it goes out and brings in a temporary web tool to view the file automatically with out installing anything just passing the encrypted stream to a service which loads and displays it with a read only message to make a more fluid usability. This of course depends on a interconnected full time web. I think people really don't care what software created any particular file, just open it, let them see it and if its worth editing, make it easy for that install this part as well.
In the business world of software at work, for the most part, people that I write software for do not tend to want to use it because it looks pretty or function gracefully or is fast. They just want to complete a task and get back to surfing or whatever they were doing as fast as possible. They use maybe 10% of all those office commands so why are the Software Giants continuing to focuses on more functionality and only moderate usability trends. It's Money, even though people don't use the new functionality they still want the upgrade. It's a psychological thing and security thing.
What we learned in Usability this past year is a great indication of were we might focuses some of our energy this year.
For concept drawings of the interface I'm working on click here.
Thanks for the post.
Posted by: Jose F. Sosa | Jan 9, 2007 11:54:27 AM
Here's my spin on process and the products it produces. Process is just how you get things done in a reasonable amount of time with a certain amount of quality. Waterfall's only original reason for existence was so that its creator could introduce Spiral. Of course the spiral methodology has evolved into the different forms we have today.
I think it is funny when I hear of "agile" being a process, because it is a mindset. The idea is that you have certain preferences for how you do things. In short its the mantra to favor people interacting over a mechanical and boring process. Let's face it, no one wants to do things just because "the process" says we should. Talking to people is fun, and we get more out of it.
The next evolution in getting done what is good for the user has to recognize the "soft" requirements. Everyone with a degree seems to scoff at the requirement "Make it friendly to use". It makes me want to take their degree and burn it. The criticism is always "how do you test it?" If you can't test it then how can you make it a requirement? Nevertheless, it is very important to at least attempt.
My personal evolution of the software development process starts with goals. What are the goals for this thing that we are building? What does the client need for this to do for them? Goals aren't hard testable requirements. They are the aspirations for the software and the people writing it. It's where things like "user friendly" and "kicks *ss" belong.
It's also where the rubber meets the road. If you created a slick little app, but it fell short on a critical goal--maybe even the mission statement for the project--then the project was a failure. Even if it satisfied all the "requirements". Ok, so the PC term for failure is "a learning experience", but call it what it is.
Posted by: Berin Loritsch | Jan 10, 2007 7:08:32 AM
As a game designer, designing for flow is my job. Achieving it is of course not easy. My favorite game company is PopCap, which produces a small number of superb titles, in contrast to most other casual game publishers. They were the company that started the casual game industry with the release of Bejeweled, and they remain on top of that market.
So what is their development process? A spiral? Some other shape? Their process is iterative to be sure, but the key is not the shape of their process but their absolute commitment to high standards. I think the same principles apply to Apple's design process. To summarize:
1. Set a very high standard of user experience quality. This requires a great deal of imagination -- to imagine something way beyond what you have seen before. It's striking to me how Apple was able to imagine a phone more radical than what any of its fans could imagine (http://appleiphone.blogspot.com/).
2. Be ruthless in achieving this standard. The key to PopCap's success is that they take as much time as it takes to achieve quality. In an industry that takes as little as 3 months to crank out a title, they can take several years. They also kill most of their titles early in development, rather than release inferior titles. Of course this can be expensive. My less expensive solution as a freelance game designer is to have a portfolio of projects that includes some smaller faster projects that let me experiment with many ideas quickly. I then harvest the best ideas and use them in my bigger projects.
3. Hire really smart people, and have them work in small interdisciplinary teams.
Posted by: Scott Kim | Jan 10, 2007 8:58:24 AM
The comments to this entry are closed.
