Methodology

Let the UI drive the requirements

  • Thursday, 24 May, 2007
  • By:

Conventional approaches to building software applications start with a Big Idea. Someone needs (to define an application) “a program that gives a computer instructions that provide the user with tools to accomplish a task“.

Someone picks up the big idea and breaks it down into a smaller list of “requirements”, things that the application must do to fulfil the Big Idea. In conventional waterfall development Business Analysts will spend a while documenting the list of requirements in some detail – in agile approaches they will do it as they go in a far more “lightweight” manner. Maybe a technical architect will draw up a blueprint design of the solution. Regardless, soon the developers will start writing code. With either agile or waterfall the user interface usually only starts to emerge at this stage. Until then, everything is coded in words (and maybe some boxes and arrows showing flow).  Only late in the process does the UI emerge.

Returning to that definition of an application, IT development seems to spend most of its time in the “a program that gives a computer instructions” world, and often looses sight of “provid[ing] the user with tools to accomplish a task”.

How about a different focus. Start with the user interface. Take the Big Idea and illustrate it. Draw pictures of what the tools will look like, how the user will interact with them. Sketch storyboards, wireframes, lo-fi prototypes, paper mock-ups, call them what you will. Use this as the primary requirements document, supported by explanatory text and detail where we required. These may be stories or use cases, but let the visual representation of the big idea drive the requirements rather than it being almost an afterthought.  Start with the UI and specify the functionality from that rather than the other way round.  After all, it will be the UI that the user uses to accomplish their task, not the computer instructions.

Software Dams and recipient participation

  • Wednesday, 4 April, 2007
  • By:

There once was a time that international development was all about big capital projects, building dams and the likes. Times change, now the focus is on eliminating poverty; DFID “focus [their] aid on the poorest countries and those most in need”. There is a realisation that those big projects did very little to address poverty, indeed they kept countries poor forcing them into debt (read Confessions of an Economic Hit Man for a cynical view of this). And besides, dam projects are rarely successful and before you know it they silt up.

A focus on reducing poverty requires a new approach. It requires an understanding of the root problems, it means spending time with the poor to understand their circumstances to be able to create appropriate and sustainable solutions rather than prescribed programmes that develop and maintain a dependency culture.

There are parallels here with the IT industry. Much of the IT game remains focussed upon those big projects. Software dams that can be launched with great fanfare but do little sustainable good to those most in need. The customer.

Before I wound up in IT I worked in international development. My PhD. “Ergonomics tool and methods for use in Industrially Developing Countries” was based on working with farmers in Sub Saharan Africa, looking at how technology is transferred and how it can be made more appropriate, sustainable and usable. Many of the tools and techniques I used in the bush I apply with the corporations I work with today. These came under the umbrella of “Participatory Technology Development” and “Participatory Rural Appraisal”.

Rather than the delivering the white elephants of expensive machinery that you see littered around Africa, Participatory Technology Development is an approach for developing simple low cost innovative solutions that have the ownership of the community who work with researchers to build them. The PTD framework starts with gaining a shared understanding problems and opportunities. This is followed by defining priority problems then experimentation. Experimentation is collaborative with options derived from indigenous knowledge and support from the researchers experience and expertise. The farmers own the experiments and the results. This leads to the next step of the framework; sharing the results with farmer led extension. (Traditionally dissemination of agricultural advice is done by agricultural extension officers – government employees who despite their best intentions preach too the farmers, sharing centrally defined agricultural advice rather than the more appropriate, locally developed technologies that the farming community have developed themselves). The final step to the process is the researchers withdrawing, leaving the community with the capacity to continue the process of change.

(Sounding like agile?)

If PTD is a framework, then PRA is a basket of tools and techniques that can be used to support it. These can be broken down into nine categories:

  • Secondary data reviews – reviewing existing sources of information
  • Workshops – getting key stakeholders round the table (or more appropriately under the banyan tree)
  • Semi-structured interviewing – talking to people with a loose conversation direction
  • Ranking and classification techniques – identifying “things” and ordering them according to different criteria. (Often this will involve moving pebbles around boxes drawn in the sand).
  • Diagramming, illustrations and graphics – pictures to convey ideas and concepts, through “boxes and arrows”, Venn diagrams and charting to cartoons and imagery
  • Mapping – drawings or models that represent the local environment
  • Structured observation – watching people doing
  • Timelines – What happens when, for example seasonal calendars, a line in the sand and people put pebbles down against the time to show when crops are sown, harvested, how the price fluctuates, labour migration etc.
  • Community meetings – meeting the whole community rather than just the immediate stakeholders who participate in stakeholders. Showcases?

Are you building a Software Dam? Or are you focussing your aid on those most in need? PTD and PRA are approaches that have developed to help introduce appropriate, sustainable improvements to the life and wellbeing of subsistence farmers. Much of their content can be transferred to IT projects, helping introduce appropriate, sustainable improvements to the life and wellbeing of customers / users.

Do you know who you are building for?

  • Monday, 12 March, 2007
  • By:

Senior management in both Tescos and Sainsburys have to spend some mandated time every year at the checkout in the stores. This keeps them in tune with what it is like to be at the front line. Taking them out of the realm of reports and documents and experiencing the reality of their strategy and decisions.

Becky Carroll recently posted a blog about looking through the eyes of others.

“We need to get to know our customers, their wants and needs, their frustrations with us, and their raves about us. You need to see your company through the eyes of your customers.”

It shouldn’t just be the senior managers of supermarkets that do this. There should be no reason why the whole project team should not gain some sort of exposure to the people whose lives will be touched by the product they are building.

Creating personas and scenarios that everybody is familiar with is a start, but it is no substitute to seeing what really happens. It may not be feasible to let everyone on the team get out onto the shop floor, but how about videoing the users at work; a five minute video of traders on the trading floor, customers at the checkout, call centre reps on the phone. When new team members join a project don’t just give them a verbal briefing or a bunch of documentation to read, let them see what’s going on.

Why is this important? Because we carry the baggage of our experience, and that is not necessarily the best or most appropriate way to approach things. We may think we are doing something cool with the technology, but is it appropriate to our users? As an ergonomist my first impression when seeing traders with four screens in front of them is one of shock. Its information overload and a poor way to work. But in the context of use, watching traders in their environment, you understand why so many screens are important. Through observation I was able to change my perceptions to reflect reality rather than my preconceived opinions.
If marketers need to “see your company through the eyes of your customers”, IT professionals need to “see your product through the eyes of your users”.

It’s not good enough to blame the computer. Blame the lack of tests

  • Friday, 2 March, 2007
  • By:

It’s education lottery time. Parents are receiving letters bearing good or bad news from schools telling them if their little lovelies have got places in their chosen schools or not. Choice being the big thing – although there isn’t really such a thing as choice, it’s more a preference. Parents have have three choices, ranked one two or three. Good schools have strict admission criteria, and will usually only accept “first choice” children. Don’t get your child into your first choice school and you are at the mercy of the local education authority – no good school will accept parents who rate their schools as second or third choices. It’s not an ideal system, but at least all the letters go out on the same day so you get to know where your child has been allocated a place.

Sadly we fall into the unfortunate category of parents whose first choice has not been honoured. Our first choice school has rejected us on the grounds of distance from the school. Their classroom quota has been reached and we didn’t fill it. That is not good for us! So will we be exceptionally lucky and our daughter get a place in our second or even third preferred schools? We don’t know. And Surrey Country Council can’t tell us.

We’ve got a week of anxious waiting before they send their letters out. They’ve got a problem with their “systems.” Well that is the message I get told when I rang them up. “We can’t tell you anything more because we don’t even know” I was told.
Frankly it is not good enough to blame the computer. If something so critical happens in the private sector, SLAs dictate a course of action; this is a severity one problem that will be fixed within hours. Not weeks. But this is good enough in the public sector where faceless bureaucrats can hide behind the computer, cosy outsourcing deals with little accountability mean that no-one really needs to take responsibility. Take responsibility for the pain and distress this is causing me and my family!
So I got their press office number from the website and rang the Head of Communications. She knew nothing of any problems with letters going out, but promised to have someone call me back to let me know what the problem was.

A little while later I got a call back and was told that there was indeed a problem with the computer, specifically in resolving offers, and in particular resolving offers where children have other siblings already in the school. I was also told that they’d earlier had problems in importing data into their systems.

Now the deadline for getting completed applications in is the end of October. That was four months ago. Four months to scan several thousand forms and process the data, and get it right. That is not such a hard task is it? OK, so the process changed for this round of admissions so changes would have been required to the systems, but even more reason to make sure you get it right. It begs the question, was there a test strategy in place? Did anybody do any testing? I believe that the system has been outsourced to Capita. Has anybody at Capita heard of test driven development? It strikes me that this sort of project is ripe for an agile approach to delivery; a business critical system that cannot fail, simple business rules… I wonder if my MP is going to listen to this story…

When do you need to design a UI?

  • Friday, 23 February, 2007
  • By:

Via Ian Cartwright  an interview with “Lean software gurus” Mary and Tom Poppendieck.  All is going well until  Mary says this:

When do you really need to design a user interface? Oftentimes it drives the whole design, but in fact you don’t really need it until you’re about to do your first alpha test. Before that you can be designing the business layer and you can actually put testing in below the user interface and you can be designing all of the other business logic; you can get that done with any kind of interface and in fact you ca drive testing with a automated interface, and then just before you go to alpha testing you decide what you want for your user interface. Then you take it off and at that point in time you figure it out. But up until that point in time you don’t need that.

This jars with my experience of building compelling customer experiences. There is a good reason why the user interface should drive the whole design because that is how the software is manifest.  To the people whose lives are to be touched by the software, the users, the consumers, the interface is the software.  To leave the UI till last presents a  huge risk of building software that is functionally rich but has a UI modelled around the features; the underlying data and logic rather than how the user wants to work.

Starting with the UI is an excellent way of capturing and communicating requirements.  And bakes in usability into the design.  You want this feature and that feature?  Great.  But will they be coherent and usable to the user?  Drawing out a UI  on paper – paper prototyping- is far more efficient that making assumptions about requirements on a list.  Afterall, isn’t this what the manufacturing industry that the Poppendiecks take thier inspiration from?  Don’t the car manufacturers start with CAD and move onto clay models?  Ergonomists have a hand in the design of car interiors, using anthropometrics to build in comfort and work out lines of sight.  The engineers don’t build the engine and the bodywork and then make decisions about how the car will look.  These things are designed from the start.  And so should it be with software.

When do you really need to design a user interface? It should be the first thing that you do.

The Total Experience

  • Thursday, 15 February, 2007
  • By:

The customer experience doesn’t start on the home page and finish on the payment confirmation page. A compelling customer experience comprises of a number of factors with the different factors residing in, and owned by different parts of the business. This can result in parts of the experience being excellent, others being shocking, such as at the Early Learning Centre. Projects that are driven forward by “IT” rarely see the bigger picture; the project manager’s primary concern is with delivery. And this means producing a product that covers all the use cases or stories that were specified in the plan. Agile development practices often reinforce this; an agile team is (rightly) focussed upon delivering technical excellence according to the “customer’s” requirements. The trouble with this is that project success in the on-line world goes beyond just delivering working software. Success is all about the total experience.

I’m sure there are a hundred and one different frameworks for “e” success. The following works pretty well for me.

The Total Experience Model. Copyright Marc McNeill!

Compelling proposition
Any on-line offering starts with its proposition; what it is offering to the market place. Do we know who the consumers are (segment), how many of them are (market size) and their propensity to buy? What is going to attract them to the site, and what is the glue that will draw them back.

Findability
Well if no one can find your compelling proposition it’s never going to make you money. Do you have a strategy in place for ensuring consumers can find your proposition? This starts with search engine optimisation, but will extend to affiliate programs and making a noise about you (Product team blogging?). And then when they are at your site is navigation intuitive? Is relevant and wanted content findable?
Personality
What is the product aesthetic, what does it look like? Is it branded? Does it exhibit production values that reinforce the brand? How does the overall experience make me feel – how does it emotionally engage me?

Content
Content is king. But all too often it is a bit of an afterthought. It’s not just syndicated content, or articles that subject matter experts might write, it is all the copy, the words that appear on the site. Do they support the proposition, or are they just placeholders that the developers wrote and never got updated? Related to content, and maybe it should have a bubble unto itself is community. I think that increasingly, successful eCommerce offerings will include an element of community. Fulfilling the promise of the ClueTrain manifesto from several years back?

Technical Excellence
Working for a company that undoubtedly employs some of the finest developers in the market place, this is something I see a lot of. But it means nothing if the other elements are not realised. Technical excellence includes those “non functional requirements” that development projects talk about; reliability, performance, scalability etc etc.

Usability
Learnable, speaks the user language, memorable, all those old chestnuts. Probably the maxim is “don’t make me think”. Aligned to usability is accessibility; we don’t want to exclude potential consumers through sloppy implementation.

Operational excellence
So the on-line experience may be compelling, but what happens then. Is the fulfilment channel fulfilling? Is there a promise to deliver goods and is the promised delivered upon? What about support channels? Do they support or do they just pay lip service to the concept? Does the web experience go beyond the web and cross other channels? Can consumers start a journey on the website and seamlessly conclude the experience in store? My blogs on Early Learning Centre, Norwich Union and a seamless experience all touch on operational excellence.

Test – measure – refine
Underpinning these factors is the need to constantly test what we do. We can all learn from Test Driven Development (TDD); write the test first and only have the confidence to proceed when it passes. How do we know it has passed? Well we need to measure it; we can only know success if we can quantify it. Based upon the feedback we refine; test – measure – refine, a concept core to agile software development practices.

A lot of words and a picture that belie a simple concept. When working in the web world, always think about the total experience. Break out of your silo (be it technical development or marketing strategy) and think holistically. What will the end to end experience be for your consumers? A technically excellent website is not success. A polished, well branded look and feel is not success. Success is compelling total experience.

What if it began with UAT? (Agile and interaction design are compatible!)

  • Thursday, 1 February, 2007
  • By:

There’s an argument brewing that pitches the agile community against the interaction design community. (You get a feel for this here via here ). Personally I don’t get it. The two approaches are a natural fit. You just need a bit of pragmatism and an ability to say “it depends”.

The interaction designers argue for ethnographic research, lots of user research, and only when we have a thorough understanding of the users, their goals and the context of their usage should we start thinking about writing code. The agile developers will say the only thing that is worthwhile is “working software”. Get something out there, quickly, and see what the users think. The agile approach mean that the direction of the software can be changed at the drop of a hat… If you are working in an investment bank, with a small user base who want this approach may be valid. But if you are building a large public facing web site, diving straight into code with little consideration of the users (e.g. their demographics, itentions, motivations etc.) would seem to be somewhat misguided. It need not be like this. At ThoughtWorks we start many engagements with a “QuickStart”. We’ll work with the client to produce a vision of where they want to get to. We’ll listen to end users, sit with them, watch them. Then use models; financial, process and visual to gain concensus and understanding of what the project is aiming to achieve. We do this quickly, focussing upon the outcomes the client are looking for the project deliver.

The visual models are straight out of the interaction designers tool kit: wireframes. Pen and ink sketches of screens, maybe on paper, maybe in PowerPoint or Visio. Alongside this we’ll watch the users, spend time with them and experience how the software will impact their lives. This doesn’t take much time. We don’t look to produce formal documentation – output is scribbled on cards or on flipchart paper stuck on the walls. In two to four weeks we’ve got a good understanding of the as-is situation, and produced a vision of where we want to get to. The benefits of this? The users get a feel for what might be in the application, we can write better stories (requirements) that are more explicit on what is needed and the developers have something more concrete to estimate against. Finally, when it comes to release planning we can visualise what a cut down version of the application might look like (and thus begin to manage expectations that they are not going to get everything in one big bang, and that things will probably change during the journey). This is not big up front design. It is quick and dirty. It is interaction design (e.g. personas, ethnography, low fidelity prototyping, user testing etc) and agile (e.g. rapid, iterative, incremental, tangible… hey! it’s test driven development without code).

Ah! Test driven development? So on my current project we showcased the wireframes and a comment came back from one of the users (someone who will actually use the application, not one of the “business representatives driving requirements).

“What you guys are doing is great,” he said. “UAT at the beginning”.

I rather like this, but with a caveat. All to often the first time the users see an application is when it comes to user acceptance testing- UAT. UAT has always struck me as a bit weird because it is rarely about “acceptance” (even weirder how it is so well embedded in the IT development lifecycle whilst usability testing rarely gets a look in). It is more about testing for bugs that the developers may have missed. It’s not whether I, as a user “accept” that the product is any good. It is probably the first time I’ve seen it. Maybe I’ve got a test script to run through, I can play with the application, but it is so late in the lifecycle that if I don’t “accept” that it is any good, nothing is going to change.

Agile proponents will argue that with small, regular drops, users are able to raise concerns earlier in the software lifecycle. Regular showcases at the end of each iteration will bring to light issues around “acceptability” and acceptance of the software. But these showcases are usually with the “super user”, the “customer” who is feeding the team requirements. Rarely is it the little person who will actually use their application. And then, even in agile, you’ll often have UAT. It will come at the end of a number of iterations, before the first “release”. But already the direction of the application is set. There is less to accept (and therefore it is easier for the direction of the development to change – one of the benefits of agile) but there is still scope for users to dislike and reject what is being released. And that is why doing UAT at the beginning, user acceptability testing, rapidly, user the interaction designers toolkit is such a good thing. You’re getting the users involved. Your testing and refining the vision. And probably getting usability in there by stealth.

Here’s a paper I wrote about this a while ago: Agile and Interaction design paper

Are you being told the truth?

  • Thursday, 25 January, 2007
  • By:

I’ve spent the last two weeks listening to users, understanding their requirements, drawing boxes and arrows, swim lanes and all that good stuff to show process flows. But is what they say the whole truth?

When we are doing analysis we are building our own mental model of the work, and potential solutions to problems we are hearing. But unless we can see what is going on, how grounded in reality will our solutions be? Anyone who has sat in on focus groups and observed consumer reality will know that what people say and what they do are often at odds with each other.

Finally this morning I had access to the users in their “real” environment. The user sat at his desk in front of his monitors and I sat slightly behind and aside him, watching over his shoulder what he did. Half an hour’s observation brought the boxes and arrows to life. More importantly, it highlighted how long he spent on each task, and the need for efficiency in the interface we are developing.

In a workshop he can ask for stuff, but when you see him working it is clear that that stuff would just clutter and get in the way of him accomplishing his goals.

Most striking is what is left out of the process discussions. Sometimes we forget about those things that are so obvious, so mundane. We assume that they just happen. Only by observing can you get a real feel for the requirements (and also how they should be prioritised).

So go on, take a half an hour break from your development activities and go and watch the users working “in the field”. You never know, you might just learn something.

Don’t say UCD is incompatible with agile

  • Wednesday, 13 December, 2006
  • By:

Consultancy is great, you get to see lots of different problems that different organisations and people have. You get to apply the learning’s built up through experience to help solve problems, and sometimes help organisations realise opportunities that they may not have realised possible.

I was recently working with a new client and sat through a presentation by an agile coach from a different consultancy on what agile is. It was great to hear a different slant on the agile proposition and how it delivers business benefit early and regularly. The presenter really honed in on human behaviour. She was suggesting that despite our best efforts and beliefs otherwise, human behaviour is fundamentally unpredictable. The best plans in the world are held hostage by human behaviour…

At the end of her presentation there were a number of great questions from folk more happy in the waterfall space. People who have seen agile and it’s like before – RAD, DSDM etc etc, “yeah, yeah, heard it all before. Agile’s just another passing fad. Then one of the HCI guys asked the question: “in what you have said, it sounds like you would have little time for doing low-fidelity or paper prototypes; a fundamental tool in the interaction designers arsenal of techniques to ensure usability (and acceptability) in design”.

To give her credit, the presenter explained that agile practices are by nature pragmatic and there may be instances where such prototypes may be valid, but in principle she suggested that they should be eschewed.

Something bothers me here. We are quite happy to “spike” technical problems, but possibly the most important part of any software implementation, the user interface, we are happy to let emerge according to the developers’ preference? For it to be refined following feedback from each showcase? What if we call the lo-fi prototype, the wireframes a “spike”. Does that make it acceptable to the agile zealots? What if rather than writing code, testing and refining it, we draw storyboards, test and refine them? Get the UI right quickly and cheaply before a line of (costly) code needs to be developed. It helps you to have a shared vision of how the application will be manifest to the customer. It helps you to show what they will be getting in an iteration, what the goal is for a release.

To say that user-centred design is incompatible with agile (which was certainly the impression the presenter left the UI team I was working with) is nonsense. Which reminds me. I’m supposed to be writing a paper to this effect.

Human Computer Experience

  • Sunday, 10 December, 2006
  • By:

HCI.  Human Computer Interaction.  Whilst I’m an HCI practitioner, it’s an acronym I feel uncomfortable with.  It is a discipline grounded in task-based activities with its roots in organisational computing.  Now that computers are ‘ubiquitous,’ task based analyses of the way that people interact with technology are insufficient. HCI needs to borrow from anthropology, graphic design, sociology, visual arts, to more beyond the “task” to the “experience”.  Human Computer Experience (HCE) anyone?

7 of 11
34567891011