if you want to fail at creating good software:
- Do not understand the end user
- Trust developers to make good design decisions
- Hope for a silver bullet design
- Build for everyone
- Launch and forget
- Do not define success
- Avoid all conflicts
- Believe you shouldn’t have to sell your ideas
- Plan for perfection
- Value process over the product
If you are looking to fail, do not understand the end user. Everybody wants to understand the end user but where we see failures is, how do you turn this Idea/Methodology into Action. Nearly 70% of all IT Projects fail due to a lack of user acceptance. So the New Golden Rule for Software Development is Hyper Focus on the End User. Every other rule that you discuss will be subservient, and every other failure ultimately comes back to ignoring this rule.
If you are looking to fail, trust developers to make good design decisions. Its not just developers, its anybody who is not connected with end users. Developers are focused on the deadlines, and not what the end client goal. Developers are encouraged to make really bad design decisions. So trust in your designers. Your users DO NOT CARE if the application was Silverlight, AJAX, Flash, .NET … Don’t let politics and silos get in the way of great software. Educate your design team on the technical challenges you face and they will work with you and not against you. A good designer will help you understand the end user translate their needs into something actionable and when in doubt, ask your users.
If you are looking to fail, hope for a silver bullet design. A good agency want come in with the big (genius) idea. Sometimes the big idea is important and some projects require out of the box thinking. And sometimes, small changes are big such as $300 Million Button.
So trust in your users. Add the word “EMPATHY” into your job description, and put it into action by talking to your users. Be willing to throw out ideas based on user feedback and be careful not take your user’s feedback to literally. Do not focus on your portfolio, if the user “notices” the UI, you’ve failed.
If you are looking to fail, build for everyone. If you build for everybody, you wind up building for nobody. Why you should not use the iPhone as an example for design is simply you mostly likely are not lucky enuf to have the budget and time for innovation that apple does. It is easier to think people like icons or faceless symbols. You will result in thousands of features that try to accommodate every need. So focus your efforts. Add the word “EMPATHY” into your job description, and put it into action by talking to your users and define a maximum of 3 personas for a project, and then hyper focus on them.
If you are looking to fail, you launch and forget, and you focus on next shining object. Most software, when releasing version 1, its only half way done, and there is a lot of learning to do. So measure for improvement. Account future releases up front. Integrate customer a feedback mechanism in the software. User testing during development AND post launch. Monitor your success metrics.
If you are looking to fail, do not define success. Defining success can be challenging. Its just that stakeholders don’t know that they shouldn’t define success, its that they don’t know how. To define success, we do not discuss features or requirements. So we discuss benefits for instance;
Qualitative
Customers has the perception of a fast transaction.
Customers would recommend the software to a friend.
Experience must be brand consistent and trustworthy.
Quantitative
Reduce the time it takes to track a shipment by 20%.
Increase the leads by 50%.
Decrease the customer service calls by half.
There is a conflict between you and your customers. So you need to find the right balance between Business Value vs End User Value.
If you are looking to fail, avoid all conflicts. Conflict is good, there is no progress without conflict and harder the conflict, the more glorious the triumph. Everybody agreeing with each other means that somebody is not voicing their opinion and if you are not hearing it, play Devil’s advocate.
If you are looking to fail, believe you shouldn’t have to sell your ideas. To sell your ideas, understand the personalities involved on the project, and answer their objections and concerns before they bring them to you. List to your customers and ensure that your opinions align with theirs – then speak using your customer’s words (“this is what we heard our customers tell us…”. Be humbly passionate about your ideas and then Oversell – craft a pitch that will set the bar.
If you are looking to fail, plan for perfection.
| | |
“The first Matrix I designed was quite naturally perfect, it was a work of art - flawless, sublime. A triumph equaled only by its monumental failure…” – The Matrix Reloaded.
We see that in lot of companies, they look for the perfect project plan or for the perfect estimate that understands everything perfect. No matter how well you set up the perfection, it never works out, and if you look at the “cone of uncertainty”, you will see why waterfall and fix bidding projects rarely work out.
If you are looking to fail, value process over the product. This can also title as if you are looking to fail, take no risk. So the process diagrams are dime and dozen. It means nothing if you deliver a crappy product on time. Wouldn’t it be great if we could schedule good ideas? But people don’t think like this, you cannot solve all the problems in the project plan. Attempting to apply a strict process will not save you from this undeniable truth “software projects are predictably unpredictable”. People solve problems in unexpected ways, this is where good ideas come from…
Stolen from Anthony Franco’s presentation, MIX09-C06F - Ten Ways to Ensure RIA Failure. You can find the references from here;
Wordpress.com, Anthony’s blog
http://anthonyfranco.wordpress.com/
Wordpress.com, The 8 Criteria for Usable Software
http://anthonyfranco.wordpress.com/2009/02/14/the-8-criteria-for-usable-software/
UX Strategy, Why Design Matters
http://ux-strategy.com/2008/06/25/why-design-matters/
Apple.com, Guides
http://developer.apple.com/mac/library/navigation/index.html#topic=Guides§ion=Resource+Types