Frequent spill

I’ve recently seen a lot of posts on Signal vs. Noise concerning the value of being a small company. They especially point out that small companies have the ability to get a personal relationship to their customers. Another point is that people need to stay on top of their game in small companies, otherwise they will be noticed for their lazyness.

The latter point got me thinking about the curriculum of the first few years of university. Mintzberg wrote about how most companies, when they start out being small, have an adhoc type of structure. Mintzberg suggested that for creative and innovative companies, the adhocracy was the most suitable. When small companies with an adhocracy try to grow, they move away from the adhocracy towards a new form of structure with more formalization and support staff – mostly into professional bureaucracies (fagbureaukrati in Danish). This change in structure would then be counterproductive for innovation and creativeness, as sharing of knowledge and working together would get more problematic.

So there you go 37 Signals – a good argument for staying small.

Innovation and creativeness are easier in small companies, but is it really that hard in large companies? Is growth possible for a small company if they want to keep their innovative abilities intact? Is it possible for a group of innovative workers remain to creative and autonomous in a larger company while still being controlled?

A possible solution to the problem could be to keep spinning off new autonoumous business units that act as individual companies? So a bunch of small companies instead of one big. Or maybe the solution is just to remain small? – at least in the minds of the customers.

The net works in mysterious ways! I just found a Japanese blog that chose to translate my Introducing UCD to XP paper to Japanese. This is too weird!

The whole idea of using personas is to create a specific fictional character, that allows the designers and developers to explore the problem domain. One of Cooper’s points is not to use descriptions of real-life people, as theese do not contain enough aspects to describe all the design-challenges in the problem domain. According to Cooper, a primary persona, which contains all the aspects needed to meet the design challenge, should be created. In other words, Cooper wants to design for only one person.

The thoughts behind Cooper’s method are great. I can really get into the “design for one person” deal. Unfortunately, written persona descriptions are often uninspiring. The designers and developers find it hard to engage in the persona descriptions, as they are just text and nothing more. How can the text descriptions become persons “part of your team”?

They can’t. I don’t believe they can as long as they are only text and nothing more. They should be complemented with something else.

A few weeks ago, I had a chance to discuss the use of personas in an agile developer environment with an XP team leader in a large US software company with a development branch in Denmark. The XP team leader did not find the persona descriptions engaging enough to be taken serious. The about 4 different personas were reduced to two “user types” – the regular user and the administrator. The dummy and the expert.

This is what should not happen! When real-person users are reduced to types of users, or even plain “the users”, we design for too many. The user represents many real-life users, so when using the term “the user”, we are talking about all of them. This means that “the user” can do this and that to use the system. This is not right. The actual real-life user only uses the system in a narrow defined way. “The user” uses the system in all the possible ways. Instead of letting “the user” bend and stretch to fit the software program, the software program should bend and stretch to fit the needs of the “real-life user”.

The XP team leader told me that they couldn’t engage in the personas as it was the text descriptions that were uninspiring. If the developers had real-life persons to pin the personas up to, it would be much better. I suggested using video-personas, but he was still reluctant to say it would solve his problems. Together we found that it might be necessary for the developers to meet “real-life users” representing each persona, letting the developers ask questions. When this was done and development started, the developers would still constantly be confronted with fictional e-mails, posters, etc, but also excerpts of video interviews with the real life people.

On top of this, user stories from good and bad experiences with the software product should be written down to be presented later for the developers.

Kathy Sierra recently blogged about neglecting the real users. On presenting user stories to the developers she wrote:

[...]almost everyone starts to squirm when they think about a real person becoming upset with them.

I recently sent a reduced-size paper about combining UCD and XP to a HCI/systems development conference. The first draft I sent out was created in a copy-paste manner from a larger paper, as an approaching deadline of the conference made it impossible for me to rewrite the paper into something that was actually fluent. So I wasn’t surprised that the paper got rejected by the conference. I received a very good and constructive criticism back from the person who was in charge of the HCI chair – mostly on the structure of the paper.

Although the criticism was very good, I was stunned by one point of critique:

“Also, we suggest to check the English language which is now a bit too creative/poetic at certain points.”

Come on! When did it become a bad thing to write with a little enthusiasm? I want to make whoever is reading what I write to be inspired more than bored. Why write something if it isn’t to let the reader think or have the same idea as you did? Let me asure you… my writing in the paper is far from poetic – but might be amusing in some places.

I’m about as much for agile development and free choice of processes as one can be. I’ve spent much time reading up on this topic, as I find it inspiring and generally fun. To get a broader view of the real world, I signed up for a Software Process Improvement (SPI) class at my university this semester, which is basicly just about CMM. I keep justifying the course by telling myself that it is good to know more about CMM than just knowing that it is about getting the organization from level 1 to 5. It probably is, but reading the curriculum of the course is about as horrific as it can be. Luckily about 50% of the curriculum is reflective on the underlying principles. Some articles even have an agile perspective – but still – reading praises after praises of something I find terribly misunderstood makes me want to tear the hair out of my head.

I find it so much harder to learn this stuff than when I read litterature that inspires me. I just finished a 15 page article, which took me around 1 hour due to the many breaks in the reading. It wasn’t boring, but as I did not agree with the article, my mind started to wander. Suddenly I found myself looking something else up google. Normally, I can just keep reading and reading as I get hooked to an inspiring text – but this is plain torture.

It annoys me that the price of learning what I am not inspired of is so high.

It is my quest and declared goal to remove as much documentation as possible when using personas and scenarios. Something is missing in agile development, and I believe the two UCD methods have much the missing in them that traditional agile development can learn from.

The developers shouldn’t be bothered with piles of documentation – neither should the project manager or the general management. If a group of people are appointed to creating the persona data as well as promoting the data, there is much to gain for the above mentioned groups of people (developers and management).

The developers and management shouldn’t need to read anything in order to understand and engage in the personas. The process should be as lean as possible. Tools for spreading the word include:

• Using real people. Introduce the personas with real people, who are actual persons who fit the persona descriptions. If the developers and project managers have a real person in their mind, it is much easier to take the use of personas serious.
• Making video personas. Watching real people makes engaging much easier.
• Posters, T-shirts, hand-outs. If the developers and project managers are constantly reminded about details (new and old) of the personas in a short and comprehendable form, they will not have to read loads of documents. This proves to be easier to engage in as well, as it can be hard to take a text-only-description serious.
• Emails from the personas. Create occational fictional e-mails from each persona, to make the impression that they are actually real – that the personas are real-life persons. Let the developers and project managers write back to the e-mails to ask questions. Either the e-mail can be answered by the persona-responsible person or forwarded to an actual person that fits the persona description.
• Collect real user stories. Whenever you hear a real-life user story, jot it down that piece of paper/notebook you always keep with you. Use theese user stories from the real life for arguments about features. You can even let one persona speak it? Real life user stories are always much better than fictional ones from the fictional personas.

I have before argued that it should be the scenarios that were specific in functionality and not the pesonas. That statement needs elaboration, as scenarios are much more than a list of requirements. If it was only a list of requirements, then why even consider mixing it with iterative development.

Using scenarios is a tool for reflection, just as the continous feedback of iterative development is. Besides showing functionality of a system, a scenario also shows (1) how the user will access the functionality and (2) how the experience of doing so is. The first of the two things is covered by iterative development, as the programmers decide how a specific feature will be implemented. The latter of the two things, how the user experiences the functionality is something which is neglected by most iterative development methodologies like XP.

Why is experience so important? Isn’t it just another buzzword used to attract customers?

There are other things in the world than plain functionality. Scenarios is a tool for conveying a concrete vision of the system: not an abstract goal nor a list of requirements. As the scenario is grounded in the persona of the user, the user interactions are guarenteed meaningful to the user (persona). The interactions are only meaningful to the user, if the user experiences the interactions like meaningful. The system might be able to do exactly what is needed, but if the functionality isn’t put together in order to make the interactions with the functionality meaningful, then the software is useless. In short – scenarios provide a tool for visioning the system beyond just the technological capabilities. XP does this as well with their real-life users – but using real-life users is much more expensive than creating text-based scenarios.

Scenarios can be used to explore functionality and how it works with the users. Instead of spending money on developing an actual prototype, scenarios can be used as sort of a soft prototype. The soft prototype, which is just text, can help expose the possible design for critique. On top of this, scenarios provide constraints. There are a load of things that could be designed, but only a few is truly needed.[1]

¹ Caroll, J. Five Reasons for Scenario-Based Design, Department of Computer Scienace and Center for Human-Computer Interaction, Virginia Tech, 1999.

There are two ways of approaching the development of new products. The market approach and the product approach.

In the market approach, you listen to the existing and future customers and users to find out how you can make your product appeal to them. Methods of choice in this approach are using focus groups, conducting interviews with people from the target market segment, looking at demographic stastics of what sells, and what does not. This is a somewhat passive approach that will only create products within the boundaries of what is seen before. You can argue if true innovation comes from the market approach.

Another way is the product approach. You focus is in the product itself and not on what people think of the product. It is more the product itself that dictates whether it appeals to the user or not than it is the user. When Apple released their new iPod Nano, the development wasn’t based on a market approach, but a product approach. Apple fixed something that was already doing great : The iPod Mini.

The market approach does not involve as much risk as the product approach. On the other hand, the potential return on investment (ROI) is much bigger with the product approach – as well as a negative ROI.

Sometimes it is better to just trust your own gut or seach for new product ideas in other places than with the customers – instead of listening to just what the customer wants.

You might discover something the customer didn’t know that he wanted.

When designing software, Allan Cooper suggests designing the entire user interface before development starts with basis in comprehensive field work. The comprehensive field work results in data about the target users in the market segment(s) that the software is intended for. This data is turned into persona decscriptions and scenarios, so that it is possible for the interface designers to engage in the minds of the target users. It is the personas and scenarios that are the most important tool of the Cooper way of designing software.

Cooper provides good tools for collecting multiple viewpoints about an interface. It is often expensive to use real users througout the sometimes lengthy design phase to provide feedback, which is why written persona descriptions come in handy. Furthermore the designeres can engage in the persona descriptions to discover things that the real-life-users can’t explain themselves. They have access to tacit knowledge that the real-life-users can’t make explicit themselves. These are just some of the positive aspects that personas provide.

A less positive aspect of the way Cooper designs software interfaces are conducting the whole design phase before development starts. New aspects of the problem domain emerges after coding starts. This requires new decision making, that will only cause harm if postponed to the end of the coding phase. No matter how much time and effort is used in the preliminary analysis and design phase, new aspects will always emerge. In some projects more than others (explorative vs. routine projects). Some problem domains require change. This is old news. In such problem domains that require change, more agile development approaches are preferred.

Can personas give frequent feedback on changing requirements? Aren’t the persona descriptions just an extract from the requirements of a given point in time? So if the persona descriptions were created in the beginning of the project, they represent the requirements of the beginning of the project?

If this is true, then in a problem domain with changing requirements, the persona descriptions needs to be constantly updated to represent the requirements from a recent point in time. Constantly updating the persona descriptions can be an expensive cost just as using real-life-users is an expensive cost.

Some tricks to help this are:

• Create general persona descriptions that are not requirement specific, but a general description of the character that the developers and designers can engage in. If the designers and developers can engage in the persona descriptions, then act of engaging in the descriptions represent the updated requirements.
• Let the scenarios be feature specific instead of the personas.
• The personas themselves should only serve the purpose of letting the designers and developers engage in the mind of the archetype of user the persona represents.

The most frequent critique of persona descriptions is that they are not inspiring. The developers can’t take them for something serious. On top of that, engaging in the personas take time – a scarce resource.

Any suggestions in solving this problem? How can we truly engage in the personas – and without too much effort and time?

Back in 1996 I started a webpage, which later grew into something bigger. I remember the dawning ages of that page, toxboe.net, where I was desperately trying to get traffic sending my link out to hundreds of irrelevant pages. In the recent years I thought back on this action as being quite ridiculous, as these few extra hits didn’t do much – especially as the extra hits didn’t come from visitors in my target group.

When I later started working as a web developer, I never thought once about where my clients got their hits from. The only thought that crossed my mind was how pathetic a visitor count of 200 a day were, compared to what I had going at toxboe.net.

Now I’m back in the new-webpage saddle again. Suddenly I start to realize how lucky I am by having as many hits as I am with toxboe.net – about 3000 unique visitors a day. And now again, it’s hard to resist spamming other sites with the URL of my new page. “Just to get it on google” has been the main argument to fulfill the temptation. As I believe (and hope) I am more mature than I was when I was in 1996, I will resist the temptation – but boy is it tempting to start spamming.

Hmm… well I guess I better start telling somebody about this blog, although it alone is a nice tool just to get my initial thoughts for my master’s degree thesis down.