Saturday, February 21, 2009
Friday, February 20, 2009
On day 1: The user experience designer came prepared with basic design screens based on our prior customer discussions. We had a few CLOUD level summary use cases written on the Confluence wiki.
We then started the discussion at the summary level use cases and added SEA level use cases and some FISH level use cases to the page. While the discussion were going on the UI designer composed the UI on here computer while sharing her desktop with everyone else via Adobe Connect.
So all along the discussion about the workflow, everyone could see the proposed basic UI design and shape their questions and conversations around the use case and the associated UI screens. This was very effective.
I took charge of the use cases and expanded them where required. In some cases we realized we need new use cases and created new ones. As more and more use cases emerged, we grouped them by actors and summary use cases.
At the end of each 3 hours session, I sent a summary email with the use cases that were changed along with the action items if any. The development team added comments and thoughts below the use cases posted in the wiki.
We then started adding UI images to the use cases. The user experience designer added images to the use cases.
On day 10 we went through the use cases one by one, reviewed the completed UI screens and marked the use cases as complete. Some were identified for future discussions.
We concluded the design process we followed was very close to the agile software design model. Iterative design, frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid design of high-quality software, and a business approach that aligns design with customer needs and company goals.
Monday, February 16, 2009
- Say less about each use case: He argues that the use case name alone is useful. He says that the collection of use case names is an excellent working medium for manipulating the full set of use cases. This is true. We maintained all our use cases on a single wiki page and linked every use case heading to its own page. No big deal. But the list of use cases we had not written was highlighted in red and clearly indicated to everyone the status of the use case. It had not been written.
- Create clusters of use cases: We created a list of high level [Cloud level for those who know the Cockburn usecase hierarchy] use cases and then grouped the lower level [Sea level usecases in the Cockburn hierarchy] below them. This quickly gave us an idea of the high level use cases, the use cases below them and their status.
- Group Use Cases by Actor: We also grouped use cases by actors. We are building a learning system. So the actors were learners and administrators. This further clarified the use cases to the team.
Cockburn also says that the use cases can be grouped further by development team and release and by subject area. We have not gone there yet.
Mr. Cockburn talks about using Lotus Notes or spreadsheets to keep a list of use cases and cluster them. He wrote the book in 2001, when wikis were not popular. Probably that is why he did not mention the wiki.
However, it is is 2009 and Web 2.0 is here. We posted all the use case names in the wiki, clustered them by summary goals, and by actors and evolved the use cases over a period of a month and an intense one week design sessions where we uses the usecases as social objects for our discussion. Whn ever one of us was not clear about the discussion, it was possible to come back and ask the question, "Which use case are we talking about?".
While the team was discussing the product managers updated the use cases in the wiki with relevant details. The UI designer provided quick screen shots for inserting in the use cases.
At the end of each day's session the product managers sent the links to the updated use cases to the entire team. The development team added their comments, thoughts and questions in the wiki page. Since the product managers subscribed to the use cases wiki pages, product managers got instant updates of the questions, answers and confirmations.
After the first week of design sessions, the product team confirmed that the week has been very productive and the entire team had a good handle on the design. Not everything is done. But we know what we know and have a clear idea what we don't know. We know what we have done and what needs to be done.
If your product team is distributed, use a wiki to capture your use cases. It can be your secret weapon.
We use the Confluence Wiki to write our use cases.
I did not mention how our UI designer shared her screen using Adobe Connect so that all along the discussion everyone can watch the design morphing from conversation to onscreen elements. More about that later.
Sunday, February 15, 2009
Saturday, February 14, 2009
It is interesting that SocialText still refers to their software as collaboration software and not community software. May be the word collaboration is better understood than the word community. One of my colleagues from work told me yesteday that the "potential for collaboration is inherent to community but you do not necesserily achieve or enable community in collaboration".
Added Twitter feeds as well. Since I send tweets using my mobile phone while I am listening to a presentation or reading an article outside at a cofee shop, I think it is good way to share my quick thoughts.