Paul Boag wrote this blog post on Smashing Magazine which forced me to write a counter post.
As a UX professional who has worked on some the world’s leading web apps for clients such as: Tesco, Lloyds Banking Group, Legal & General, EON Energy, National Lottery, Bupa, Boots, Directgov and Argos, I feel obliged to offer my 2p on this subject matter.
I will dissect some of Paul’s statements from his post which I have issues with.
I seem to mostly or heavily disagree with most of the things which Paul wrote here, hence this is likely to be a long post. Apologies in advance.
I’m not intending to disrepute or lessen Paul’s profile with this post. I’m rather hoping to create a meaningful discussion on the topic, with hopefully some good additional replies from people in the know.
Disclaimer: I respect Paul as a family man, web consultant, accessibility evangelist, an eloquent speaker and a very entertaining podcast presenter. However, not necessarily as a ‘web apps expert’ though. 
So here we go.
Paul says: ‘A better web application for your business’
From the very start this article has confused me. Paul talks about ‘my business’, which I am likely to be very familiar with. The rest of the article follows on to talk about things which do not really make sense against this title.
Paul says: ‘Are you fed up with hearing about yet another Silicon Valley Web application built with fairy dust and funded by magic pixies?’
This is like one of those generic old school advertising lines? Something like: ‘Need a new hoover? Argos has 30% on all hoovers this weekend!’ If you don’t need a hoover, you should not listen basically.
Why would anyone be fed up with someone else starting a new business or building a web app? We all have a choice to use or not use things which we want to use or like. Options are a good thing.
Not sure who this article was aimed at. Paul kind of broke the first rule of writing a good article. Who’s your audience here Paul?
Paul says: ‘I have identified three secrets that seem to make things go a lot smoother:
Focus on user tasks and not features,
Don’t try to solve everything and
Ask the right questions early on.’
Paul, there is nothing really ‘yours’ about these ‘secrets’ you have ‘identified’. Also, these three generic statements don’t necessarily help with anything as they are too … generic.
Asking oneself the right questions requires quite a lot of insight, wisdom, experience and attention from the designers. Most designers don’t have those as they are usually not close enough to the business.
Paul says: ‘Focus On User Tasks, Not Features’
Focus on users’ tasks is kind of what most people do anyway, but many web apps have arguably become really big because of their … features.
Often a time I have come across teams of business users saying things like: ‘We would have opted to procure App A, but App B was the only one that had the crucial feature we needed, hence we went bought it.’
Many times real business web apps have many user tasks which need completing on the regular basis.
Think of GMail, Google Calendar, Basecamp, Facebook, Amazon, etc. They are fully featured and comprehensive tools. Even Twitter, seamingly simple one has a lot of complex, subtle whiz-bang which makes it work the way it does.
Many of the ‘simple’ features require very heavy and clever back end processing to work properly, so they can be simple from the UI perspective, but complex to implement (which means time, money and know-how required).
This is why Facebook, Google and Twitter all took 4-5 years to development to gain global visibility.
Paul says: ‘Take a step back’
I have found that observing the way users carry out tasks currently can often lead to some skewed results.
Users within businesses are often required to ‘hack around’ an existing process and work around existing apps which are badly designed.
Observing them leads to engineering bad practices into the new web app solution. Also it tends not to be innovative.
When Google released GMail, it completely confused me at first, but a week later I was loving it and today swear by it. It’s completely the opposite of what ‘observing the users’ would achieve.
GMail, however, is very much hated by some people who are die-hard Outlook users, hence GMail rolled in some Outlook like views too, adding additional features to keep everyone happy.
Sometimes we are required to design brand new things for business too, so there is no existing process to observe in the first place.
Speaking to people who are interacting with the application on daily basis is usually impossible due to time and availability constraints in most businesses I have worked at.
Paul says: ‘Make user testing part of the development process’
Sure thing.
How would you do this in an environment where there are 12M users for your web app?
Users are also scattered all around the country and the world often, making wide enough insights virtually impossible.
Paul says: ‘Don’t Try To Solve Everything’
Even the most useless businesses prioritise and have project managers which usually (in my experience) try and narrow down the scope of an app, as opposed to doing the opposite.
Furthermore, in my experience, businesses are limited by their technological capability to do many things, hence I find myself battling to get features in as opposed to take them out of scope.
Therefore, in my experience, this is almost a completely obsolete statement.
Paul says: ‘Sometimes Technology Is Not the Answer’
Fair enough. There are many management issues in many UK companies. I studied management at a Master’s degree and understand that most managers in UK are self-taught people who try and get by from day to day.
However, there are very good reasons why (larger) corporations require workflow features for example.
They are exactly the ‘business problem’ which Paul opened the article with.
And they are pretty hard to solve because of all of the reasons I outlined already.
Paul says: ‘Make It Expandable’
Here Paul recognises that things are complex – good!
However, I would not be so sure that a ‘plug-in’ architecture is exactly the solution to the problem.
Having worked on WordPress installs with around 20-25 plug-ins installed on them (for a relatively small business) I have realised the short comings of such web app internal architecture.
God forbid having to do this with a much larger business.
The solution which we had devised for entire Tesco.com architecture had nothing to do with plug-in architecture, but all to do with good old object orientation.
Paul says (in ‘Ask the right questions early on’): ‘Make sure you have all the facts before beginning.’
Hah! This is a straight case of classic double think.
How can you have all the facts to start with and have a need to ask additional questions?
This is exactly one of the big problems with software engineering and design.
Often a time even the most experienced professionals do not know the exact answers to almost any of the questions asked.
This is why research, analysis and investigation is required and why people get paid so much money to know how to do this properly.
Knowing which questions to ask is half of the game and the winning solution.
Which questions was Apple asking when designing iPad?
Many times the answer to the question of ‘Will this application get internal approval?’ depends on things like: budget, top level stakeholder, company’s current share price, internal politics or competition and may not be anything to do with application design at all.
Points 1-4 Paul makes in the ‘Ask the Right Questions Early On’ are arguably the most superficial and least worrying issues to deal with in a typical web app.
They can have impact on the cost and choice of staff going forward and are important from that point of view, but don’t usually complicate matters too much.
Exception may be the authentication topic, which is currently causing even the mighty Google a whole load of problems in making it universal. But what Google are looking to do is to unify dozens of web apps built by different teams under one universal login, which they are hoping can be a universal login for the entire planet. A completely different scope of the problem to deal with!
Paul says: ‘Learn From Your Mistakes’
Oh thanks! That’s a new one there Paul. Even birds on trees sing this old song in many aspects of life (e.g. think about the UK Government currently talking about learning lessons from police not protecting the UK people for example).
Your mistake here was that you should have never published this article as it makes you look average, just like you should have never attempted to create a web app like GetSignoff.com as it failed for the same reasons you outline in your article.
The issue is that sometimes there are no 2nd chance to correct your mistakes, so there might be little point in learning from them.
What now? Do I write an article about it?! 