Design and User Experience in an Agile Process
The hallmark of the agile process is its short release schedule. Developers on a project might spend two weeks adding onto a product, release it, and then move into another two week iteration before another release. This yields efficient development, with little wasted effort and a great opportunity to adapt to change throughout the development process.
For designers and user experience architects, the process might not seem as efficient. Often, a design team will spend weeks creating the design for a project, only to see the fruits of their labor adversely affected as the developers take the design into their own hands as requirements and interfaces change.
This talk presents a methodology for ensuring that an agile project maintains its design and user experience integrity throughout the project. This happens by staggering the involvement of every aspect of the team, with user experience and design teams working on the third iteration, for example, while the development team works on the second iteration. At all points, everyone on the team is in a position to innovate for future iterations as well as learn from the outcome of past iterations.
With a carefully crafted process integrating agile user experience planning, agile design, as well as agile development processes, a project team can ensure that the results are well-designed while still maintaining all the advantages of traditional agile development.
comments
You had the best designed presentation slides I saw in the whole conference ;-)
Could have done with a shorter "what is agile" part of the talk. Wished the speaker spent more time on more details of the process they use....
Thanks for the feedback, folks. Always willing to hear how to do a better job of talking about this stuff.
If you are interested in checking out the slides, which admittedly make little sense outside the context of the talk, they're posted here: http://www.slideshare.net/whafro/design-and-ux-in-an-agile-process-presentation
Feel free to get in contact with me if you have any questions -- I'm happy to help or bounce ideas around.
Hi, Jackson... as a really old fogey in this biz (Univac 11/08's, Spectra 75s, PDP 11/34s, HP1000s, VAX, Lisa, Cadmus UNIX boxes, PC/1, PC/AT, Mac, Mac II ... anyone?), I was much taken by the progress in language.
What you called, or what are called "user stories" -- "The user needs to upload several photographs at the same time,"-- used to be called "functions" in a "functional specification."
I was pretty pleased by the fact that, when the Mac II came out and my little outfit began building Designer's Assistant in 1986, I was able to rewrite the func. spec. I'd created with XyWrite II, then III, on a PC/AT, mostly as a large outline, on the Mac II as a work of fiction called "The Designer's Assistant User Manual," with screen-grabs, menu-mockups 'n' all--tools just pretty much sitting there (or as free-ware) on the Mac--so that our funding users could help edit the func. spec. And in a context/environment with which they were eminently familiar, namely, the user manual.
I thought this user manual approach was an order of magnitude more useful than the "func. spec." or "user requirements" of yore.
But "user stories" is a whole 'nother leap into the æther. Maybe it's the onset of autumn, but I can imagine a group of users and designers, recorders, zithers, cell-phone-cameras, 12-string guitars in hand, circled around a campfire, bellies full of S'mores, swapping "user stories."
What a hoot! (That'd be from the obligatory owl, of course, offering adscititious commentary.)
Someone might perform a very useful service by compiling a "Developers' Dictionary Through the Millennia--or months, whichever comes sooner" for the Web2.0 community. It might help prevent hundreds of person-years of wasted time, effort, misunderstanding, etc.
(My example of this: Not that it took 'em all that long, but the gang at Urbana-Champaign, 'cuz they had no grounding in computer typesetting, newspaper editorial computer technology, threw out about 20 years of development that finally separated "content" from "form"--that is, separated the words from "in-line markup" or HTML. (in the case of typesetting, it was separation from IBM's earliest FDP-markup (field-developed-program) using command begin/end delimiter pairs--maybe ASCII 17 & 18 -- like, say, ?CC10p,87,9.5,10?--change column to 10 picas, use font 87, set 9.5 points on 10 points of leading.
To get those attention-frazzling inline codes removed, the industry, by 1976, had fastened upon "display modes" in the text (regular, bright, underlined, underlined bright, slanted, slanted bright, slanted underlined bright, reversed regular... 16 in all), linked to "Format" files or "Style" files. (ever hear of Style Sheets or even Cascading Style Sheets?--that'd be the 1976 format files and linked format files (you could call/invoke one format file from another.) And, oh golly gee, the format file could link more "form" attributes to the "display mode": first line indent, flush left, or right, or center, or justified columns, leading, line-spacing (Tex-rhymes with bleech--had "river control" and "hanging punctuation" in the early 80s, If I recall. It took Adobe maybe another 20 years to add these sophisticated typesetting amenities to InDesign, I think it was/is).
So, for lack of a multi-disciplinary lexicon/dictionary, say, a whole lotta people spent a whole lotta time reinventing entire railroads, never mind wheels.
Fortunately, such "failures to know of and learn from history, where relevant," aren't as lethal as the unlearned lessons from war. (Which, of course, is now described as "bringing freedom and democracy to the oppressed-who-live-on-oceans-of-oil")
Web2.0 Dictionary, anyone?
(And, while I'm at it, howsabout mass transit access (like, the subway?) to Javits Center? I editorialized against building Javits w/o subway access way back in 1972 or so. But who listens to talking heads on TV, anyhow.)
Great visual representations of data in the slides. I think some audience members could have benefited from a high-level overview of the agile process and its controversy.
Great session. Not having known much about the agile process this was really great to see.
Thanks