That dreadful peice of software Lotus Notes prompts for a password change at regular intervals. It does not permit you to use the same password used before. A similar situation occurs with opening Microsoft XP. Whilst this may be considered to be more secure from a technology point of view, it betrays human behaviour. Generally we humans adopt the most parsimonious strategy for getting on with life. We go for simplicity. I’ve tried to be clever with my password strategy, but I’ve just run out of unique passwords that I can remember. This morning I was struck down with password amnesia. Ten minutes spent trying to remember my passwords. So I can do one of two things. Write the passwords down. Hardly secure. Or adopt a common strategy of selecting a word and adding a digit to it. and incrementally increasing the digit at every password change. This will undoubtedly compromise the goals of complex passwords regularly changed, but how much easier is it to have “Password1” this week and “Password2” the next. (That’s not my passwords BTW. Obviously.)
Downloaded the beta version of Office 2007 – I’d been assured you can run it alongside Office 2003. First impressions are good – PowerPoint gets infinitely better, you can make presentations that don’t look a thing like PowerPoint. They gone back to basics with Word; the whole styles and formatting thing was just getting stupid. Now it is intention driven and pretty simple to use. If you are going to replace the whole UI of probably the worlds most used software application you need to make sure you do it right. I think they have succeeded. Excel looks pretty good as well, but didn’t spend much time with it because…
IT KNACKERED OUTLOOK!!
So I no can no longer access outlook. Something to do with .dll files. A visit to some of the forums (or is it fora?) does not reveal a solution. So I am left with no other option but to uninstall both the beta and my existing version of Office. A return to Lotus Notes for my mail (grrrrrr) and a sour taste in my mouth. ho hum.
I’ve seen a couple of projects recently where the team have invested in usability testing of wireframe mock-ups of application processes. I’m beginning to wonder whether this is effort well spent.
Don’t get me wrong. I am a firm advocate of usability testing and incorporating it as early as possible into the design process. I’ve set up a few usability labs in my time, facilitated hundreds of usability sessions… I even once had the pleasure (is that the right word) of watching users struggling with boo.com. There is always much to learn from seeing users actually using what you are building. But I now ask the question at what point can you learn the most. If you’ve designed with usability in mind, where is the value in testing the basics of something that instinctively you know as a usability professional to be “right?”
Let me qualify this. The development of an on-line application processes / tools / wizards is now a well trodden path. Any interaction designer worth his or her salt will have experience of building one and will instinctively know what works and what doesn’t work.
In the first instance the interaction designer will create wireframes that illustrate the process; a visualisation of the pages representing the flow that has initially been created.
In creating the wireframes the Interaction Designer should be making reference to personas, will have been collaborating with other team members, validating their assumptions, and will probably be doing informal guerrilla testing around the office to confirm ideas that are puzzling them.
If the interaction designer is any good there will be few, if any issues with the wireframe flow that the users walk through. In a usability test the user is more likely to pick up on labels (and if it is not lorem-ipsumed up any copy that the interaction designer will have written – It is unlikely at this stage that the copywriter will have been involved).
That is a lot of cost and effort to validate the work of a professional.
The wireframes in usability test will generally be based upon a set scenario through a “happy path”. What the wireframes are unlikely to uncover are issues where the user wanders from the “happy path”. Producing reams of wireframes in Visio or PowerPoint and then linking them all up to simulate the finished product is painful and not particularly productive or useful, especially if there is a lot of interactive “web 2.0” stuff going on. To really simulate that you are going to have to build a prototype for real.
Here is something that the devs at ThoughtWorks are pretty good at. Using high productivity platforms such as Django or Ruby on Rails they can pull together a fully featured product that can be usability tested in earnest. It is not a dumb “smoke and mirrors” html prototype; it can have database and “intelligence” behind it. The benefits of this are clear. The business can try and break the process; we can get the business rules right. The developers are able to see how the vision actually functions. Again, they less likely to uncover corner cases that have been missed if a first pass of build has been done already.
Once we have this new avenues of testing are opened to us we can move away from the need to test in a clinical lab environment. Providing a user with a URL to the application form, and using collaborative software such as Skype and Net Meeting we can perform usability testing with greater ecological validity – the user can use the application form on their own PC at home.
What am I? Professionally that is. The question arose when we recently registered the birth of our daughter Olivia (when asked what the baby is to be called Lindsey got in first. I didn’t get a chance to say what I was going to name her; Orphelia Cordelia…).
On the birth certificate is “father’s occupation”. Gasp! What is it? Imagine in generations to come and my great, great, great, great granddaughter is doing a family tree and she is looking up the records and she finds me on the birth certificate and looks at my occupation and an instant impression will be made.
Strictly speaking I work for ThoughtWorks as a Business analyst. But I don’t often see myself as such (the BA role is all too often viewed as just a person who captures requirements with little scope for creative or strategic thinking. I’m happy to say in TW we do a lot more than just business analysis…) Anyway, not wanting to be eternally pigeon-holed as a BA – I want great, great, great, great granddaughter to think good things about what I did, not “uh, he wrote specification documents” I looked for a new title.
On our marraige certificate my occupation was a “management consultant”, but I don’t fancy being one of those any more.
I could call myself a “Company Director” – a legacy of my contracting days; I’ve not closed the company down yet. But that isn’t really my occupation; primarily I’m a ThoughtWorker. Hmmmm. That’s a bit pretentious – Occupation: ThoughtWorker.
OK, so what do I do. Well there’s interaction design.
Occupation: “Interaction Designer”. Nah, would progeny know what this means? (In her time interactions will be hard-wired to the senses so such a role will be redundant).
“Customer experience architect”. She’d probably laugh.
“Usability dude?” she’d probably consider me to have been an anal type who complained a lot and found fault in other peoples work.
“IT Consultant” nah, I spend just as much time with “business types” as IT types. I’m even doing marketing qualifications don’t you know.
“Solution architect” What sort of solution?
“Facilitator?” Facilitating what? Nope, not important enough.
“Innovation… ummmm, something?”
So I’m clutching at straws and the birth certificate needs completing and so I shrug my shoulders.
Occupation? I sigh. “Business Analyst”.
“So great, great, great, great grandfather was a business analyst. Hmmm, I suppose he analysed businesses…”
Creating a lo-fi prototype or wireframes in PowerPoint can be a time consuming pain. Lining things up, getting the widgets to look “just right” is not time well spent. Lo-fi is supposed to be just that, “low- fidelity”. Trouble is, once the client have seen something that looks rather polished they have high expectations, even expect the lo-fi to resemble what they might expect in production. This is clearly not a good state to be in, but sadly often happens. So here’s an example of a basic wireframe all nicely lined up…
Anyway, inspired by http://napkinlaf.sourceforge.net/ and remembering the essence of lo-fi being “paper prototyping”, I downloaded a hand written font and used the line tool in powerpoint to knock out some lo-fi that is precisely that. It takes no time at all (needs a steady hand with the line tool I’ll admit), conveys everything that the more formal lo-fi gives but reminds the audience that it is a “sketch” of the screen, not design or anything like that. (And actually I think it looks a lot better than some of the screen mock-ups I’ve churned out in the past!)
There is an argument that goes like this. Give two development teams the same problem. Get one team to use a waterfall model, the other an Agile model and see what you get. Chances are that the agile team’s code will be more elegant and cleaner than the waterfall team but their UI design will fall short of the Waterfall team’s.
Truly incremental development of code, adding features as they are required (according to business value) is just not suited to developing a consistent and intuitive interface. Without a model to specify what the interface consistencies will be the developers will build the interface according to the requirements of the current feature, not necessarily how it contributes to the overall experience of the application. This is often compounded by listening to the wrong “customer”. All too often the people who buy software are confused with the people who use it. Buying decisions aren’t using decisions. (Anyone who has used Lotus Notes primarily as a mail client will testify to this: you are a captive users. If you as an end user could choose you would probably use something different, but you didn’t buy Notes and were probably never invited into the discussion about it’s purchase).
Big up-front design?
If “change” is a dirty word in Waterfall approaches then “Big-up-front-design” is a dirty phrase in the agile vocabulary. Anything that smacks of design and specification documentation before a line of code has been written is guaranteed to get the backs up of agile zealots. Yet it is clear that in an absence of any roadmap for a UI, the interface could go anywhere, and for a component as critical as the interface between the user and the functionality this can have disastrous consequences. Any feature is only as good as the users’ ability to use the feature. The underlying code the developer has written may gain the admiration of her colleagues, but if it takes the user twice as long to use the new feature because of a poor UI then any business value promised in the application has been destroyed. On a project iteration level, the lack of any detailed UI design can cause a number of issues ranging from inability to get customer sign off on stories through to rework (not refactor) as the UI metaphor starts to evolve.
In practice it doesn’t have to be like this. You don’t have to do “big up-front design” to get the UI right, rather just do enough to produce a model that drives the project forward (what original XP called “metaphor”); an understanding of what we’re all striving for, so we can make emergent design decisions that match that metaphor. The question therefore is what is “enough”? As always it depends.
The user interface is rarely specified as a requirement. It is just assumed it will have one. A starting point to getting the UI right is by capturing it as an emotional requirement. How are users to engage with the application, how do we want them to feel about it. By doing this we can quickly ascertain whether we are looking at a “world class, best in breed, competitor beating application;” an “application that will help transform the productivity of our employees [happy workers = productive workers]”; or “just a maintenance application that the tech guys use”. Business value can be placed upon each of these requirements and should be prioritised against feature requirements, both in terms of benefit (builds the brand, faster transaction times, fewer mistakes etc) and in terms of cost (interaction designer and graphic artist input on project team).
The GUI model
Once we are agreed that the UI is important to the success of the project, we can produce models for the look and feel of the UI.
The model isn’t the UI design for the application per se, but rather the vision and the basic structure of the UI for the application to fit into. It provides some guidance for developers and BAs as they begin to analyse and implement stories – some basic structure the application can fit into so we don’t have to struggle to invent so much UI stuff for each story. And, so the finished application feels a bit coherent. The model may have two halves, firstly the vision that illustrates the feel of the application; how the user will flow through processes, an information architecture illustrating where pages will fit. Secondly the model may be prescriptive; how the will the user know what to do, how will widgets work. The primary artefact of this model might be ‘wireframe’ sketches of pages – a low fidelity prototype that walks through key user journeys. Alongside this may be basic interaction patterns, for example how a search mechanism will work, how forms are to be laid out. Just enough to ensure consistency in the feel of the application and prevent avoidable re-work at a later date.
Alongside the feel model is the look model. The developers need not care too much about this, provided their html is cleanly marked up. The feel will be created by the graphic artist and interaction designer, and implemented in the style sheet. Obviously if the goal of the application is to be a customer facing “world class” website, more attention will be required on the look than if the application is a development support tool.
The important thing with these two models is that they are sociable, communicable and flexible. The whole project must be aware of them; when new people are brought onto the project, the starting point of the communication should be the wireframe sketches. “This is the vision of the project… currently we are working on these parts… you see that tab – that is release two…” They may also change. We originally thought we’d have a ‘wizard’ to complete the process, but after showing the wireframes to users they wanted it all to go on the same page. But it is better to have something to hold the UI together than assuming that it will evolve through incremental development.
(These thoughts are not entirely my own – much of it is distilled from a ThoughtWorks email thread on UI design, agile methods, and BUFD… or BUFUID as someone commented).
New project? Got a business customer who is passionately into Agile but has never done it for real? Lucky you. But beware! Do they know what it really means? Do they blindly recite all the benefits of Agile with no experience of its reality? Do they think that it is a stick that will finally beat IT into delivering value to them? Agile is good, but as with any process there will always be pain. It is not a panacea for everything that is wrong with traditional software development. It takes time for an IT organisation to transform. Just make sure the business customer know this. Things are unlikely to change overnight. Make sure that expectations are set from the outset, schedule time for retrospectives (with safety controls) to ensure everyone is happy and make sure that channels of communication remain open. But as an agile practitioner you’d do that anyway.
Agile is all about “delivering business value”. Core to this mantra is prioritising features, getting the highest value stuff in first. But proceed with caution. I was talking to Dan North about this yesterday. It’s not *all* about business value.
Where is the business value in “log in”? It’s not driving revenue or reducing costs. You can’t place any monetary value on it. How about the emotional requirements that will create a buzz amoungst your consumers? Don’t have the compliance guys in the prioritisation workshop and no-one in the business is going to put auditing in their “must haves”. Yet these are show-stoppers.
A couple of thoughts. Firstly, think in terms of doing your prioritisation around themes – Jeff Patton [pdf] has written some great stuff on this. And rather than business value, how about “Stakeholder value”. This will map to key business drivers:
customers – increase revenue
employees – reduce costs
auditors – compliance
By giving each business driver an owner or a persona you can ensure that no one audience can hijack the MoSCoWs.
Whilst amazon.co.uk languishes in yesteryear, it’s transatlantic cousin amazon.com has gone all web 2.0. They’ve also introduced some new features, the ability for customers to associate and share their photos with products they have bought. For example for an ipod nano people have uploaded images that graphically illustrate how small the nano really is. Cool stuff. But I have a question. Where is the business value in this feature?
Agile is all about delivering business value. Business value can be crudely decomposed into four reasons why we do things:
- To reduce cost
- To increase revenue
- Because of reguatory or compliance pressures
- For altruistic reasons (such as giving something back to the community / imrpove emloyee morale etc)
Features that do not address these business objectives (and more often than not just the first two objectives) will be deemed low priority (if ever considered in the first place) and typically fall by the wayside. Which makes me wonder how Amazon get away with it. What is this business case for “Customer Images”? What business metric will they look to that will demonstrate the features success in driving revenue? I’m sure some obscure derrived metric could be arrived at – but I would guess that the key driver for this functionality is an extension of the brand. There is no monetry reason for the feature, it is just a right cultural fit with the overall product. It is about developing an emotional engagement with the customer that is beyond the purely functional (browse – buy).
As agile practitioners we capture stories. During the process we will also capture “non-functional” stories. (some would add “technical” stories to these). I’d argue we need to add a new category of story – the emotional requirement – how do we want our users to feel about our product? Such stories will enable us to build software that goes beyond the strictly functional and begin to engage. They will help us temper the cold business objectives that focus upon getting things done, with the softer intangible / aesthetic quality of the applicaiton that will keep the user coming back again and again. Come to think about it, there’s the business case for “Customer Images”. Building a better relationship with our customers to increase customer purchasing and reduce customer attrition. Now why don’t other businesses think like that.
So I’m collaborating on a document. Usually this means starting with a word document, saving it as “version 0.1” and forwarding it via email to the collaborator. They do their revisions that come back in multicolours with the option to save or reject and it all gets confusing. What actually happens is multiple versions get saved to the hard drive and it is a really inefficient way of working. My Microsoft friend assures me that Sharepoint elminates the version control aspect of this, but this still means checking the document in and out to do revisions. I’ve tried to use Gforge as a repository and tortoise CVS, but it all gets complicated with plink and putty and I just give up. So what a revalation Writely is. I can collaborate real time on the same document. It has all the commonly used word processing functionality that Word has (keeping styles simple rather than the bloat the MS have added to Word. And at the end we can publish the document to the web, give it an RSS feed or just export it as a Word document. Awesome.