You know that feeling when you know someone very well and you buy them a present? You know they will love it and you are excited at the very thought of their delight? Part of you is a little scared though. A few butterflies in the stomach. What if I have misread? What if they don’t like it?
I listened to someone speak recently who said that one thing he had learnt in his IT career was that the first time you do anything it will be wrong.
I disagree.
Rolling out a new database for a website, for example, can be done right first time. Be clear on what the old one does, write some tests, test the tests, make a rollback plan, test that. Make the new database. Research, plan, build, test, execute. The occasional hardware failure or act of god notwithstanding, everything is likely to work very smoothly and you can sit back and have a celebratory mojito.
I like mojitos.
Certainty isn’t always possible. Let’s aim for confidence.
1. Understand your users. No, don’t simply survey them, understand their underlying needs, behaviours; embrace that information, it will be the difference between functional and delightful. Think about how you ask the questions and make sure you understand the answer.
2. Understand the underlying objectives of the product, service, project you are setting out to design. These might be your objectives, your employers, your clients. Make sure you are clear on these factors.
3. Understand the competitor landscape: what might your users have learnt from them? What can you learn from them? What is food for ideas and what is noise?
4. Understand existing design principles, patterns and rules. Experiment, invent, play but remember that these are part of your toolbox.
5. Understand your need for testing. Test an idea. Test a sketch. Test a prototype. Test again. Be humbled again and again by all the assumptions you have made without realising. Be clear on what you are testing and why. Designing the test is a key part of the process.
6. Understand the limitations of the technologies you are working with. By all means push the limits. Reality checks are enormously important because poor execution of even the most brilliant design will undermine the user experience of it. You need to make sure your understanding matches that of the people who will be putting it together.
7. Understand the need to throw bad ideas away. They are fun. You should play. Test them. Understand why they are wrong and ditch them. Ideas are cheap.
8. Understand what is good about a design. Understand why. Add to it, improve on it, add it to your toolbox, move on. Good ideas are as cheap as bad ones.
Test, repeat, improve.
Perfection is elusive. Have a mojito, sometimes it helps.
“Understand your users. No, don’t survey them, ” – How is one going to understand their users without any data on their habits?
If you are replacing a current database with a new one, doesn’t that imply that the first time wasn’t right? 🙂
I think his statement was more on the point of the fact that ‘right’ in the computing industry is a moving target. It’s not usually hard to get things right, if you take the time to do it, and only concentrate on one target. But by the time you get it right for that target, many new targets may be available, and it’s no longer where the market is heading.
@Aaron I am sorry for the lack of clarity. Of course one needs data in order to understand user behaviour. I think a ‘just’ in that sentence might help. Will review and update – thanks for pointing it out.
@rodney Possibly. But it might just mean a hardware change or a move to new infrastructure. My point is that there are technical tasks that one can define and execute and that point was there to help me make the next one. Maybe it is an unnecessary distraction 🙂
I think what you are referring to is covered in the second part of my post. ‘Test. Repeat. Improve.’ covers all of the points. Not only does the market and underlying technology move at a pace but so does the baseline for user behaviour. Much user insight has a shelf-life in the same way that technology does.
We all face the same problems and that is why there is a need for data. User, stakeholder (whether it is a commercial entity, your boss or your own self-indulgence), market and technology.
Of course ‘right’ is a moving target – hence the suggestion for the occasional mojito regardless – but while working on any given project it should be possible to create a shared understanding of the current target, no? There is a difference between ‘let’s get a something out and we can change it’ and ‘let’s get a something out that does this, for these people, that will be built like this and take advantage of these market trends/forces because we/I/they want to achieve this’. Otherwise, how do you know if changes are needed and what changes to make?
I just got off a long flight and am sure my comment could be shorter 🙂