Methodology

The scourge of Document Driven Design

Documents, or rather words are the scourge of product design. Because words can never convey the true meaning or emotion of what is really required. All to often, software development projects are driven by the documentation – agile projects can be equally guilty of this- driven by words on paper (or card) that convey what the requirement is. Issue #1. Developers don’t read!

Except for a few exceptions, software is all about a user interacting with a system in order to accomplish a goal. Trying to describe that premise in terms of features and functionality is fundamentally flawed as it will be nested in the language of technical implementation, not in the user interaction. “Find” becomes “search”, “buy” becomes “shopping cart”, “check” becomes “validation” and so on. Issue #2. The desired outcomes become lost in a smog of technical jargon.

Solution: Picture Driven Design. Up front. Yeah! I’m all for up front design! A picture tells a thousand words. It has the power to remove ambiguities, clarify the vision, showing what the journey to realise outcomes look like. Start with a day in the life of… scribble out the flow, the user journey. Nothing complicated, boxes and arrows. Then scribble out what the user interface might look like. Done. That’s your up front design. That’s your documentation. That’s your scope. What you do next is up to you, write loads of documents that describe it and produce the software in a waterfall way if you want. I’d prefer you were more lean and adopted agile practices, but whatever you do, start with the picture. I’m convinced it will save much pain later on.

What the customer wants

I’m a strong proponent of engaging the customer in all stages of the design process. But sometimes you need to be careful with what they say and not always believe their first answer.

Ask the customer “what do you want” and the chances are you will get an answer that is rooted in their experiences and expectations. Not what they really want.

I want an intranet portal“.

No, you don’t. You want a place where your employees can share files and documents.

I want a google search appliance“.

No you don’t. You want to be able to find documents quickly and efficiently.

Worse is when vendors try and force products onto the customer…

You want an integrated BI toolset“.

No they don’t. What they really want is to be able to pull some specific data from a legacy application into an excel spreadsheet and insert a graph into a word document.

OK, so it is easy to say that, but how to follow though? How do you actually get the customer to create a vision of what they really want? Well I’d start by not asking them that question. Get them to articulate what their goals are. Then try to understand in what context they will try to accomplish those goals? Think in terms of customer journeys and value outcomes over features. Think about the what, not the how. Start with the “to-be” vision rather than dwelling in the “as-is” quagmire, indeed use a system obituary to kill the as-is thinking. Use visual tools to model your ideas. And don’t get bogged down in detail.

I’ll write more about this in the future…

Cutting waste: dump PowerPoint and invest in a camera

So you’ve run a workshop and generated ideas. There’s a list of points on the flipchart and diagrams on the whiteboard. What now? Write it all up in Word or commit the drawings to PowerPoint?

Stop! Ask yourself why you are doing this? Is it just to record the ideas, to socialise back to the group involved in the workshop? Creating PowerPoint slides is not always an inconsiderable effort. It takes time. That effort is waste.

Think of the purpose of what you are doing. Then take photographs of the flipcharts and whiteboard diagrams, paste them into PowerPoint, and think of how much time and effort you have just saved.

Was it just a simple database query?

So the sensitive personal details of 25m people has been lost and there is a huge political furore over it. Whose fault is it? As far as I can see, (and this is my personal opinion,) blame must lie with IT, specifically the IT contractor and either the contract they work with or the perception of that contract.

The National Audit Office asked HM Customs and Excise for child benefit in “desensitized form”. Sensitive details were specifically asked to be removed, ostensibly to make the file size smaller. This would require a bespoke query to be run. It was deemed too costly so it was assumed that a full extract of the data would do. The fact that this was then burned to a CD, posted unregistered mail and lost is not the point (that is stupidity). What is the point is the IT contract prohibits the business (in this case the governmental offices) to do their job properly.

What sort of contract demands extra payment for a simple database query for “NI numbers, child benefit numbers and children’s names in order to select a risk-based sample of cases to audit as part of anti-fraud work“?

Surely this is an extra request that an experienced database analyst could easily run in the course of a day? If not you must ask why not – is it because the database is badly designed with nested tables and stored procedures and stuff that would make a decent DBA go eugchhh (I’ve seen that happen). If this is the case, the IT contractor has done a bad job; if an electrician worked in your house and left a mess of an electrical installation, would you keep employing them, even if they were cheap?

Maybe however it would not have incurred a cost and this was just the perception; “we must not… run additional scans/filters that may incur a cost to the department”. If this was case it suggests a breakdown in the relationship between the business and IT, with tendency towards the confrontational and transactional rather than co-operation and partnership.

Organisations that outsource their IT often fail to realise what the true costs are. Anything outside the terms of the contract is a change request. It is not unusual for the request itself to incur a cost (someone has to write the documentation, specifiy the design, estimate the effort) before a line of code is written. (At one organisation I worked with that had outsourced their IT function, I was told that to add some basic client-side field validation to a single field on an application form on their website was likely to cost in the region of £60k). The business starts to believe that everything costs and IT becomes a hindrance and a vicious cycle commences.

How could things have worked differently? Let’s say the HMRC IT department was run on more lean/ agile lines. With agile it embraces change. The request comes in (let’s assume such requests are not regular occurances) and in the morning stand-up the BA describes the request and asks the developers for its feasibility in a word. Someone says “yes, I ran a simiar querry last month, it’ll take me ten minutes”. (In reality double or treble that estimate), but it will not have an imact on the developers ability to get thier prioritised work completed. Alternatively the developers say “given the database structure we have inherited that’s a lot of effort” or the project manager says “another request?! pritoritise it like the others!” and it is prioritised in the weekly iteration planning meeting (pushing something else out) and then it gets done.

My hope is that when the inevitable investigation takes place, they don’t just look at the policies and procedures, but also at the underlying structure of the way that IT is managed.

Consistency when things are poor

Call it a pattern, a heuristic or a rule of thumb. A fundamental one of those to ensuring usability is consistency. This may be external consistency – for something behaves in the software in a similar way elsewhere. A good example might be the ‘x’ button in the top right hand side of an open window. It is universally a call to action to close the window. If the designer created a button labelled “C”, and placed it on the left hand side this would result in confusion. It is not consistent with the users’ expectations from using other applications. The second type of consistency is internal – do things behave in a consistent manner throughout the application? This may be both in behaviours (e.g. buttons with the same titles perform the same action), and in look and feel – a website has a visual identity and coherence, assuring a continuity of experience.

There may be examples of where internal consistency is not possible. For example a brochureware site that uses a third party for fulfilment or payment. Paypal is a good example of this – the user is taken out of the shopping experience and into a paypal experience. This can be successful if there is clear signposting and use of the paypal imagery on the shopping site to assure the user.

So what happens when you have a large, legacy website that you acknowledge to be pretty poor in the usability front and want to introduce new functionality, or want to rebuild it. If you play the consistency card too strongly you may continue to be consistent with the old design and behaviours. This begs the question, is it better to introduce something that is internally inconsistent, but fundamentally better? This becomes even more an issue when you look to rebuilding your site in an incremental fashion.

As an information architect I can help you design your site architecture – the look and feel, navigation structure, user journeys etc., but this will probably be in its entirety. To build this new site will take time, and assumes a “big bang” whereby a completely new site will be (re)launched. Yet there are probably business imperatives to fix specific areas. If we build in an incremental fashion, and take the agile approach of focussing upon delivering business value, we are not going to have a fully redesigned site to go live with. We are probably going to have (for a short while at least), some parts of the site that are new and some that are old.

Going back to my original question, we can either build this to be consistent with the old site, or do something tangentially better. If we do the later it will probably be significantly inconsistent from other parts of the site, or the original parts of the site. It is in this scenario that I am inclined to throw away the consistency pattern. You may have internal inconsistency if you have a clear roadmap to throwing the old and the new functionality / design is proven to be usable, accessible and intuitive. With this the case, the interaction behaviour and visual identity of the new functionality must become the benchmark to which future functionality is consistent with. And you must clearly signpost to the user what is going on; customers will generally be forgiving if they understand that the changes are in their interests.

What is your business

Should “the business” care about IT? Should an investment bank trader know anything about XML, or a marketer know anything about SQL? Probably not. Even less so should they be talking to their IT colleagues of their requirements in these terms. The business should speak to IT in a language of value driven requirements rather than implementation detail. What is the outcome you need or want, not how you think IT should deliver or implement it.

Yet in many organisations (especially where IT has historically had a track record of failure), the business has taken a greater interest in IT delivery. They start talking the language of the techie. When this starts to happen business operations no longer see the clarity of their business. They see systems. In an investment bank setting: the trade is booked in Zeus, settlements are handled by Minotaur, payments by Socrates. Corporate actions are handled in Hades. Depending upon the geographic region, client management might be handled by Tomsys, Dicksys or Harrysys. You ask a business person what do they do and they talk in terms of systems. Getting down to the underlying requirements of what they actually want to do is hard. Innovation and creative thinking are hard because they always return to what the limitations of the current systems are. They focus upon the requirement for a Reconciliation System rather than asking why there needs to be any reconciliation in the first place.

So here’s a suggestion. Act dumb. Forget everything you know about the way you do things and go back to first principles. How would things be if we were starting from scratch? How would you describe your business intent (not the what you do now, rather what outcomes you really want to achieve) in simple terms to a complete novice. I doubt the word “system” would come into the description.

Make something consumers love

Bubblegum generation presents a compelling model for Apple’s iPhone strategy:

1) Pick an industry which sucks (ie, imposes significant nuisance costs/menu costs/externalities on consumers)
2) Redress the imbalance by making something consumers love
3) …Which disrupts the long-standing industry equilibrium, and shifts market power
4) Use said market power to redesign (a hyperefficient) value chain

Don’t think that organisations in industries that suck don’t aspire to “do an iPod”. Go to any proposition development or product strategy workshop and it won’t be long before someone is mentioning Apple products. Yet all too often they fail to do anything truly revolutionary; they end up doing something different rather than “Redress(ing) the imbalance by making something consumers love”.

Do customers want something that is different or something that is just better?

Interestingly, little functionally in the iPhone is new. Like every other phone on the market it makes phone calls, sends messages, receives emails, takes photos and allows users to listen to music. Nothing different or new there… other than being better than every other phone on the market.

What Steve Jobs espouses is the experience of the phone. He says “So, we’re going to reinvent the phone. Now, we’re going to start with a revolutionary user interface… Now, what’s the killer app? The killer app is making calls! It’s amazing, it’s amazing how hard it is to make calls on most phones.”

He’s not looked to do anything radically different, rather do it radically better.

So how do you bring revolution to your product set? Rather than trying to be different, why not try to better. Make something that consumers love?

Take a leaf from the Apple book and focus upon the experience. Design and attention to detail are critical. Moving beyond purely functional and satisfying products to crafting experiences that engage the emotions. In agile product development it is often easy to focus upon delivering functionality that is perceived to deliver business benefit, yet end up with a mediocre product that has little resemblance to the original idea it was meant to become. Incremental delivery is a key feature of agile; it means you get stuff out there early and often. The challenge is to identify what that stuff is. To make something that consumers love using the agile approach, in addition to great developers and focussed project management, you need three people;

1. A passionate sponsor who has a dream and a vision and can articulate that to the team, banishing mediocrity from the outset
2. A business analyst who will help the team slice the functionality according to consumer needs and desires; that take the consumer of the journey they want to travel, not a predefined route that constrained to picking those features that eventually will deliver greatest value.
3. A customer experience architect, interaction designer or graphically minded usability dude who can champion the product aesthetic and usability.

Get them on your side and maybe you might be taking the first step on developing a better gizmo that your consumers will love, and sleep outside your retail outlet for hours to buy one.

Are you building a potato or a Sensation?

The humble potato is not worth a lot. The farm gate price for a 150g spud is negligible. How do you add value? How do you turn a worthless Maris Piper into a valuable commodity?

Potato

Potato crisps (chips) are a great example of a low value product being turned into high value one.

Walkers salt and vinegar crisps

But that’s the easy part. The real value add is further transforming the product without fundamentally changing it. Innovation through packaging and marketing, making a basic product appear more desirable. Appealing to higher sensations beyond just satisfaction; differentiating the same basic product into an up-scaled, up-market luxury item. The same item that customers will happily pay more for.

The retail price for a 50g bag of Walkers Salt and Vinegar crisps at my local One Stop is 35p. The price of the Sensations bag is 47p. (For reference the retail price of a 50g potato – is 5p). Now I’m no crisp expert, but I’d guess that the incremental cost for adding a couple of new ingredients to the flavour is marginal. There’s some sunk cost in product development- creating the new flavours and developing the new brand, but this is little effort compared to the benefits that will be accrued.

Walkers Oven Roasted potato crisps

But that is not the end of the story. Focussing upon the experience of the Sensations product, Walkers see an opportunity to change the packaging – to increase the bag size. Now their basic Sensations product is a whopping 150g bag that retails at £1.35.

Walkers Lime and thai spices crisps

Sometimes it is easy to focus upon just delivering the basic package, to just satisfy the customer. Is there anything you can do on your project to transform delivering the hygiene of customer satisfaction, to selling a compelling value-added experience?

System Obituary

Talking about workshop icebreakers with Prashant and here’s an idea: participants write their own tombstone or obituary. “Here lies Jack. A life spent comparing numbers on an excel spreadsheet”…. You could even use Tombstone Generator to bring them to life:

Tombstone

Hmmmm, maybe not the strongest icebreaker (indeed it could kill your workshop before you’ve even started… If you don’t consider cultural sensitivities you could receive some rather blank looks, if your audience doesn’t have a dry sense of humour or doesn’t “get it” you’ll be in trouble…)

So maybe it won’t work so well with people, but how about systems? If you are looking to understand the current system landscape, why not ask the participants in your workshop to list out all the systems they can think of and ask them to write the inscriptions that would appear on the tombstone.

For example…

+

Customer System RIP
1997-2007

Dearly beloved wife of Position System and bastard child of Excel spreadsheet (1991-date).

Threw tantrums and refused to give the right answers when it really mattered
Grew bloated in size due to unwanted change requests
Lost self worth due to non-business value changes
(Died in the loving hands of Indian Outsourcing Company)

She will not be missed

+

Here Lies Position Reconciliation Spreadsheet
1991-2007

Father of Every Conceivable Problem

A real handful to manage but usually got there in the end
Local resident of Sarah’s Desktop, he never got out much
Prone to occasional lapses of judgement that were rumoured to cost the bank millions

He has gone to a better place (recycle bin)

And why restrict this to the current state. It could be a useful exercise in understanding what benefits a new system could be remembered for…

+

Here lies New System
2007-2017

Saviour of the Back Office

Banished reconciliation breaks to history
Defeated the multi-headed Legacy Dragon, bringing peace and harmony to the Ops team
A single voice of truth
Beautiful to look at, easy to get on with, she gave such joy to customers and added such value to the business

Without her Ops can no longer function

Software Dams and recipient participation

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.

2 of 2
12