In my last post, I started to cover some ground on how Agile and UCD can fit together. These postings come from a discussion on agile usability in which Robert Biddle of Carleton University, asked me three very good questions.
Q1: are the UI designers and programmers within the same team but do different kinds of tasks, or do they do both?
Q2: what are the UI stories (or backlog items) like, especially for user research?
Q3: do the UI stories count as "done", even when no software has been written?
My answer to Question 1 essentially elaborates on my previous post: UI designers and UI programmers are just another flavor of business analyst or programmer and they would collaborate with the other analysts and programmers on all the tasks that need to be done including user research and usability testing.
For example, a team could have a person who has skills in UI design and UI programming. That person could pair up with another analyst to do user research in one iteration, then pair up with a developer to code the UI part of a story(s) in another iteration. A team may also have a person who is a UI designer and experienced in user research but not experienced in UI programming. That type of person would stay completely in the analyst / customer proxy role doing things like user research, product design, acceptance testing, facilitating showcases with the stakeholders, and also any needed product documentation.
The other programmers on the team would also pair up with UCD analysts as needed to have conversations, investigate solutions to a problem interface, and conduct or witness research into the user experience.
Q2: what are the UI stories (or backlog items) like, especially for user research?
We have to be careful with the term "story". "Story" is a thing that developers implement. "Tasks" are things that have to be done to get stories through the pipeline. Tasks are activities people do to figure out what the story should be, realize the story in code, or verify the story is done. You have a UI story if you have something that can be stated like this:
As a mother, I want to be able to search for a doctor who can treat my child's condition and practices close to my home. Acceptance: The search functionality must be easy to find on the home page, you can search by all or part of a medical term (e.g., cancer, scoliosis, juvenile diabetes) and/or a location (city, state, zip), the search results will include the doctor's names, specialities, location(s) and photo.
You have a UI task if you have something that can be stated like this:
Interview/observe 6-10 mothers of children under the age of ten to understand how they would search for and find a doctor for their child on the internet.
Or this:
Interview/observe 6-10 mothers of children under the age of ten to gather information on their expectations for a children's hospital website.
Or this:
Analyze interview results and identify new candidate stories for inclusion in the current or future development phases.
You definitely make the coding stories visible in the master story list and track their progress, but you may not build a backlog of all of the tasks. High-level tasks might be treated "as if" they were stories so it is easy for the entire team to be aware of overall progress and activities for the iteration, but your tracking system would have some type of physical distinction between the analysis/UI tasks and the coding stories.
For example, your information radiator/story wall would likely use color or parallel tracks to distinguish coding stories from other activities. The development track might show stories 2, 3, and 4 in play while your analysis/UI track might show that story 1 is out for customer and UI acceptance testing, detailed requirements discovery is starting for story 5, and user research (UI task) relevant for proposed backlog stories 6, 8 and 9 is in-progress.
A lot of tasks are not made visible because it's just too much noise. But people still report status and blockages in daily stand-ups -- I'm going to be late finalizing the requirements for story 5 because I can't get a meeting with Mr. Y; we need to get the XML spec for the interface to system G before we can complete story 3; our user interviews are proceeding on schedule and we have no problems to report.
I'll cover question 3 in another post since that also has a long-ish answer.
Great post!
ReplyDeleteIt's always interesting to see how the worlds of design and implementation overlap.
The problem I've seen when the UI designer is the implementer is the danger of being influenced by what's easiest to implement rather than best for the user.
A slightly off-topic point, but perhaps phrases like:
"As a mother, I want to be able to search for a doctor who can treat my child's condition"
... should read "As a *parent*..."?
Matt, thanks for the input. I agree that the politically and culturally correct phrase does seem to be, "as a parent..." but for this particular client, a hospital specializing in critically ill children, the design research gathered over several years in a close relationship demonstrated that 90+% of the time, it was the mother who handled all of the scheduling and related bureaucratic correspondence. For these families, it was not unusual for the mother to have given up a job in order to work full-time on managing all of the aspects of the child's healthcare needs.
ReplyDeleteHmm, ok, a bit of context helps. But, and without wishing to be argumentative, even if we're only talking about 10% of the user base then isn't it a shame to lose visibility on them so early in the process?
ReplyDeleteAnd as for the power of language, if 90% of the software developers in your organisation are male, do you act as though they're all men...?
Just my 2 cents
Matt, there are a lot of things going on your comment. I am imagining us having coffee sometime. It could be an interesting conversation.
ReplyDeleteAnyway. Paragraph one seems to be jumping to a conclusion that we've lost sight of a portion of the user based on one example out of many project stories. Not fair to jump to conclusions. I'm sure you're familiar with the 80-20 rule and agree that if any project covers 80+% of its target users/usage first, we can always circle back and adjust for the rest if it is different and if the business value justifies it.
On paragraph two, I just heard a tremendously interesting thing on NPR yesterday AM about a linguist who had studied that very thing...how languages that characterized things as masculine or feminine actually pre-disposed their native speakers to have masculine or feminine perceptions of those things ( http://www.npr.org/templates/story/story.php?storyId=102518565&ps=cprs ). So if our linguistic framing of "software developer" is masculine, maybe our organizational behavior is predetermined even if 90% of the team is female. But that's a completely different discussion...we could take it offline.
Hey Marjorie,
ReplyDeleteFair point about 80/20 - I'm sorry if it sounded like I was being critical, it was just a concern.
And yes, the language thing is fascinating :)