Here is a good presentation on how you could potentially improve your own APIs…
Documentation!!! At one company I worked at (a long time ago), before the product went into beta testing they would take a person from marketing or outside sales from a totally different product line and sit them down with the documentation and the product with the instruction to “have at it”. Then they were timed to see how long it took for frustration to !@#$ them off enough to make them give up. The record at the time was 47 minutes.
Cold testing was a part of the beta program and once the majority of “un-savvy” users could install and use the product from scratch, the product was frozen and released. We had a 6-9 month release schedule but very few usability complaints.
Workflow!!! (Same company.) We found that unless we built the workflow based on the target users’ input on how they would use the product, we would invariably get complaints that the interface was awkward, confusing, misleading, and a slew of other words I won’t repeat. Logical workflow in their minds generally didn’t jive with that of the engineers’ minds.
In my own coding, I find that I need to frequently revise what I created once I started trying to use it.
Alwyn, that is a good presentation and should be required viewing for all development and marketing groups.
One practice I encountered, which made for a VERY nice experience building the app, was to write the user manual first.
Literally they went through everything about how things were supposed to flow on paper to create the user manual then handed completed sections to the dev team to make it work like that.
Not a technical spec, but a user spec. Their concern was it had to work like this so make it happen.
Project was very successful and very well received by the users as they were highly involved from the outset and got lots of input to make sure the system worked how they wanted it to.
A good user experience is important for the success of any product. People don’t buy products… they buy satisfaction… and that applies to any kind of product or service in any industry.
The examples you gave above about being hands on with the users sounds like a great ways to ensure the vision of engineers meet the expectations of users.
I do enjoy winging development (like most developers do I suppose). It is fun to just dive into creative freedom and build something awesome while avoiding the tedious efforts of writing documentation. The problem comes in when the product enters the maintenance cycle, and there is little documentation to go around to make it easier. Without good documentation it is also more difficult to scale the product.
The presentation above made met think a lot about the importance of having good documentation for your users AND other developers that might want to engage with your works.
Writing the user manual before the code also sounds like a good way to plan ahead… like they say… failing to plan… is planning to fail.
Don’t you just love cliches…
Wrote an app where we wrote the user manual first AS WELL AS a document listing exactly what the app could do and what it could NOT do. Both were very well received by clients.
Tony, this was very important. The worst mistake that we, as developers, can make is to fail to meet the customers’ expectations - or to meet the wrong ones. By telling the customers up front what the application can and cannot do, you set their expectations correctly. If they know the app cannot do something, they may want you to add it to the wish list, but they won’t be too upset when it doesn’t do what they weren’t expecting it to do (did that sentence make sense?) Well done, Tony.