A former colleague and current friend (well, until she reads this), Alice Toth, just published a fine blog on User Centric Design. She outlines the process very well (as I would expect) and she slyly doesn't tell you how its done (hey, we all gotta eat).
Alice was the assigned Information Architect on one of those 'projects from hell.' I was the Lead BA. Before I get started, I have always respected Alice's ability, genius and grace. Its too bad she didn't spend much time on our little venture into the third ring of Hell because she is always an asset. Pathfinder recognized this and promoted her to the second ring of Hell- she became a Project Manager while we of the third ring fried and sputtered.
Alice is a fabulous Information Architect (IA). After several discussions, She and I decided that BAs gather requirements and organize them in words, tables and diagrams, while IAs do the same using visual tools. A significant part of being an IA is to show up any wireframe I create in VISIO and they do freehand on a Mac. IAs are schooled in HMI (Human-Machine Interface) and the psycho-sociological uses of web browsers. Both do As-Is and To-Be workflow models (IAs call them scenarios). All in all, the two functions have many commonalities.
Alice was a superb resource when I had to create Best Practices and dovetail Agile Development with User Experience Design. And she can code. And it doesn't hurt that she's a genius without all that stepping on eggshells stuff one has to do around such folks. Very real and down to earth and a great friend.
So, it is with great reluctance that I take her to task for this statement on her latest Blog:
BAs define actors as a person, system or sub-system that needs to do something (a defined goal) using or connecting to the application. While Alice and I were aligning the processes of a BA and an IA, we decided a Persona was usually a class of Actors (i.e. usually more than one person). A Personas usually brings more than one goal to a session on the 'puter. In the Iterative and Waterfall Worlds, these have to be broken down into discrete sets of actions and reactions...and they called them Use Cases. And the PMO say that it was good.
But only for a while.
That there web thingie screwed everything up. Instead of a defined, step by step defined workflow, users can now do pretty much what they wanted (within constraint) as they damn well wanted to and watch video, listen to audio and talk back, through their browsers! Actually, it's much more important to folks like Alice and me that the browser can transmit Credit Card Numbers and PayPal Account detail....but that's another blog.
All this stuff caused Use Case Hyper-inflation and forced the Fed to impose Agility.
OK, I lied- there were a LOT of reasons Agile methods were created. Do you really think the sudden appearance of Web 2.0 and Software as a Service (SAAAAAAAS)- [hyperbole and sarcasm intended] and simultaneous popularization of Agile is a coindence? I don't think so. I can see the guy in the sailor suit with pocket protector up there on the virtual grassy knoll right now.
So we BAs create a series of User Stories that supports the creation of the new or revised workflow we designed and got sign off for at the beginning of the project. We make sure the DevTeam can create each User Story within a sprint, or we break the User Story down some more. Repeat until feature is complete and end user is happy. We use the Actors to identify who does what in the smaller chunks of User Stories. Sorry, its a habit. And it works. And it's not inhumane- I have always worked in a shop certified by the Anti-Cruelty to Actors Society.
'Actor' isn't vague- I always identify them in a separate chapter of the high level requirements and then in thre User Story or Use Case or Specification, I re-identify them. And Alice know damn well I never, ever let the DevTeam dismiss my Actors.
What's that you say? You read the Agile for the Waterfall Lover book and it states categorically the business team member or end user is supposed to write the User Story? Dream on, dude. They don't have the time or inclination to do that unless its in a JAD (Joint Application Design) session and the boss pays for brownies and lunch. The BA or IA write them and verifies them with the appropriate authority (stakeholder, Subject Matter Expert and/or end user). Then the developer who gets the task can go to the person who approved it and start the discussions. Or ask the BA or IA (since they are the only end user advocates on the DevTeam) or the BA/IA can facilitate the discussion. See what I mean? Nuthin's easy.
I have two problems with Alice's declaration of war in the allegedly inappropriate use of Actor and User:
This Blog brought to you by that little old troublemaker....me (remember those TV wine commercials?).
Alice was the assigned Information Architect on one of those 'projects from hell.' I was the Lead BA. Before I get started, I have always respected Alice's ability, genius and grace. Its too bad she didn't spend much time on our little venture into the third ring of Hell because she is always an asset. Pathfinder recognized this and promoted her to the second ring of Hell- she became a Project Manager while we of the third ring fried and sputtered.
Alice is a fabulous Information Architect (IA). After several discussions, She and I decided that BAs gather requirements and organize them in words, tables and diagrams, while IAs do the same using visual tools. A significant part of being an IA is to show up any wireframe I create in VISIO and they do freehand on a Mac. IAs are schooled in HMI (Human-Machine Interface) and the psycho-sociological uses of web browsers. Both do As-Is and To-Be workflow models (IAs call them scenarios). All in all, the two functions have many commonalities.
Alice was a superb resource when I had to create Best Practices and dovetail Agile Development with User Experience Design. And she can code. And it doesn't hurt that she's a genius without all that stepping on eggshells stuff one has to do around such folks. Very real and down to earth and a great friend.
So, it is with great reluctance that I take her to task for this statement on her latest Blog:
Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software.Hunh?
BAs define actors as a person, system or sub-system that needs to do something (a defined goal) using or connecting to the application. While Alice and I were aligning the processes of a BA and an IA, we decided a Persona was usually a class of Actors (i.e. usually more than one person). A Personas usually brings more than one goal to a session on the 'puter. In the Iterative and Waterfall Worlds, these have to be broken down into discrete sets of actions and reactions...and they called them Use Cases. And the PMO say that it was good.
But only for a while.
That there web thingie screwed everything up. Instead of a defined, step by step defined workflow, users can now do pretty much what they wanted (within constraint) as they damn well wanted to and watch video, listen to audio and talk back, through their browsers! Actually, it's much more important to folks like Alice and me that the browser can transmit Credit Card Numbers and PayPal Account detail....but that's another blog.
All this stuff caused Use Case Hyper-inflation and forced the Fed to impose Agility.
OK, I lied- there were a LOT of reasons Agile methods were created. Do you really think the sudden appearance of Web 2.0 and Software as a Service (SAAAAAAAS)- [hyperbole and sarcasm intended] and simultaneous popularization of Agile is a coindence? I don't think so. I can see the guy in the sailor suit with pocket protector up there on the virtual grassy knoll right now.
So we BAs create a series of User Stories that supports the creation of the new or revised workflow we designed and got sign off for at the beginning of the project. We make sure the DevTeam can create each User Story within a sprint, or we break the User Story down some more. Repeat until feature is complete and end user is happy. We use the Actors to identify who does what in the smaller chunks of User Stories. Sorry, its a habit. And it works. And it's not inhumane- I have always worked in a shop certified by the Anti-Cruelty to Actors Society.
'Actor' isn't vague- I always identify them in a separate chapter of the high level requirements and then in thre User Story or Use Case or Specification, I re-identify them. And Alice know damn well I never, ever let the DevTeam dismiss my Actors.
What's that you say? You read the Agile for the Waterfall Lover book and it states categorically the business team member or end user is supposed to write the User Story? Dream on, dude. They don't have the time or inclination to do that unless its in a JAD (Joint Application Design) session and the boss pays for brownies and lunch. The BA or IA write them and verifies them with the appropriate authority (stakeholder, Subject Matter Expert and/or end user). Then the developer who gets the task can go to the person who approved it and start the discussions. Or ask the BA or IA (since they are the only end user advocates on the DevTeam) or the BA/IA can facilitate the discussion. See what I mean? Nuthin's easy.
I have two problems with Alice's declaration of war in the allegedly inappropriate use of Actor and User:
- The use of the terms Actor and Usder are purposely vague. The whole idea of what a BA does is to abstract the entire work flow in order to define the function(s). This allows the Bidness Team and the DevTeam to read the dame stuff and envision the same thing. That's why they call it Functional Analysis.
- The UxD (User Experience Design) folks can and do carry this Persona thing way, way too far. I almost worked on a project that had about a half dozen personas identified. The UxD Team (not ours, thank goodness) not only had names- they captured pictures of each persona, knew her husband and her kids, where she lived, what car she drove and what got her drunk the Saturday night before. While the UxD Team goes off on those tangents... DevTeam Members are looking at each other and wondering what the hell is going on. I understand what the UxD Team is trying to do, and it does help define workflows, users and actors. I feel silly and unprofessional when I invoke a Persona. I feel like I'm talking about a dead guy or at a seance. And let's face it folks, the word persona is defined as: a character in a play or novel; A person's mask or facade; or someone's perceived but not actual personality.
| Carrie Ann Johnson, the one from Freemont High School, not the one that graduated College third in her class, clicks <Search> | 1. Browser sends search parameters to Search Engine. 2. Search Engine performs search and returns matches. 3. Content Manager and Web Server send results page to the browser. |
This Blog brought to you by that little old troublemaker....me (remember those TV wine commercials?).
Powered by ScribeFire.
Posts
I like personas. They bring fun into development, which is a good thing. Technically there is no much difference between Persona and Actor (or Role), but personas less formal and help to understand end users better.
ReplyDeleteHi Michael,
ReplyDelete1. Personas are emotional and abstract.
2. Actors are non-emotional and abstract.
I guess what I'm saying is that each side can go to extremes...and I've seen both sides do exactly that.
That said:
A. I've never had a problem explaining an Actor to an end user- the Actors are defined within the project documentation (I usually do that in the Functional Requirements during the Discovery/Planning Phase of the project) and within a Use Case (I don't usually define the Actor in a User Story.
B. If it's a choice between going extreme in abstracting Actors and dehumanizing them and going delightfully nuts on Personas, I prefer the former to the later- I feel less stupid.