ForUSE - Conclusions

A few days have passed and I've had time to reflect on the conference now. There were a lot of different angles on design and process covered. Below is a breakdown of the takeaways that were the foremost impressions.

Process
Larry Constantine said it best in the final conversation that was held between the remaining delegates on the last day. "Process is like the training wheels for learning a craft. When one has gained enough experience one knows when to throw it away." Ron Jeffries also had a good way of describing process. "Process is like a Kata, you practice techniques over and over and over to make you learn the art..." Having once studied Karate, the notion of practicing set techniques in different combinations really resonated with me. Through practice, you can draw on your route knowledge of individual techniques and combinations of them, to best solve a problem when faced with it.

The conference presented numerous different processes and ways of 'skinning the cat', but ultimately each set of activities (process) should be tailored to the individual characteristics of the project at hand. You could set down some 'touch-stones' or general guides, but ultimately these have to be vague so as not to be too prescriptive. I've learned a lot more about new techniques and general rules of thumb, so this should be very helpful in laying these 'touch-stones' in the right place.

Usage vs User
"In usage-centered design the focus is on usage - on the work users are doing and the tasks they are trying to accomplish. Users, rather than being the center of attention, are involved in limited and highly focused ways to help designers build tools that will better support the work being done." More on this at foruse.com.

The emphasis of Usage Centred Design is much more on developing software and using notation and language that enables proper dialogue with technical teams. I know this is going to be more powerful than I can imagine right now. The divide between tech and design varies according to the personalities on both sides of the fence. However, through this framework I am confident that we can really begin to communicate properly and constructively. Most technical folk I have known have not been resistant to the tenets of User Centred Design. However seeing the relevance of some of the exercises and techniques has proven a sticking point in the past. I still believe there are appropriate times for applying some of the less quantifyable techniques for gaining context about user goals. However, we need not bog down folk to whom this has no bearing on the job at hand, just as they would not ask me to help write a few lines of code.

The nice thing about Usage Centred Design (U-CD) as a set of techniques and an overall process, is it seems a lot more focused on getting the job done. The areas of User Centred Design (UCD) that have caused me the most trouble with management (and sometimes the team), are those that produce no tangible deliverable for the end product except documentation. U-CD seems not to have the same kind of 'bloat' around it and I think that combined with the best principles of SCRUM wrapped around XP (as illustrated here), it is the kind of process outline that will work flexibly enough to accommodate all projects.

The exact nature of how the agile processes and U-CD mesh is yet to be defined. But the conference had some good examples and success stories, so It looks promising.

Return on Investment (ROI)
XP has the capacity to measure and predict ROI according to chunks of work called 'Stories'. Each story is attributed indexes of value, expense etc and can be prioritised over other stories (according to its overall value) to ensure the optimum return on investment. It is this kind of surety that enables confidentent strategic decisions to be made in the context of a programme of projects.

A Company needs to ascertain what it defines as 'Value' and 'Quality' in order to make decisions about their products' development, based apon these indicators. This body of work should be thorough and consultative with audience and staff. There is also a need for a clear understanding of the business' strategic direction to guide this work. Assessing comparative ROI on any new process means measuring the running costs and revenue of the current and comparing it to that of the new. An accurate assessment of the current running costs and revenue (before the change in methodology) is integral to measuring success.

Breadth and Depth
Breadth and Depth refers to the overall body of work to deliver a product. Depth is exivalent to detail - we delve deeper into the solution. Breadth is more about the big picture such as overall infrastructure and architecture. Agile processes advocate that in each iterative cycle you address both of these. This takes the form of a rule that each cycle must deliver someting tangible like code and also deliver the broader project work too.

Breadth and Depth for design means approaching things differently to what I or most designers I know are used to. However, theoretically it makes sense to design things starting with a sketch, and defining levels of detail iteratively in collaboration with the entire team.