12 December 2013

Feedbacks for developers & UX designers

This post should particularly interest developers and UX designers wishing to work in the design of public interactive systems. It discusses some lessons learned during the last 5 years on the specificities of the job.


The first attempt will be rarely the good one
Creation of a public interactive system is a complicated task and the first imagined solution is rarely the good one. You will have no choice but to accept this fact and to adapt your methods to produce a quality result.


Accept criticism
The best method I have found to date is to submit an idea to criticism by successive concentric circles.

Self-Criticism
First, always take a critical look at your idea. Can you identify its strengths and weaknesses ?

The expert view
As it is always difficult to make a critical judgment on his own work, submit your idea to your team mates. It will complete your first analysis.

The public eye
Submit the idea to a group of beta testers to get a more representative view of end users. The more you'll be able to place your testers in situation, the more you can expect to get rich insights. In the early phases, use storytelling, paper prototypes, cardboards... Anything that can help place the tester in situation.

Criticize criticism
Your testers are not the experts. Listen to all opinions, but do not consider any advice as worth taking. Analyze it, understand what it means and what it involves for your system.

Establish relationships of trust within your team
Criticism should never be seen as offensive but as a part of the creative process and a source of enrichment. Establish trust relationships with other team members will help to accept criticism.

Be agile
Adopt an agile method not because it is the hype but because it is essential for your business. As the first solution is rarely the best one, you will have to submit your ideas to criticism. Prefer short cycles and many iterations to converge more quickly and at lower cost to a better solution.

Why the developer is always the worst tester of her own work ?
Developer, you will always be the worst tester for the functionality that you develop and it is not a matter of skills. For the purposes of development and unit testing, the developer repeats dozens (hundreds) of times an interaction. The action quickly becomes mechanical and the developer is less likely to take a critical view of what he puts in place. A good habit: have your developments tested by another developer and test his developments.

Learn to trust your intuition
It is important for the developer to learn to listen to her intuition during his initial tests, before the effect of the repetition hides the "defects" of what she has created. If you think that an interaction could be improved, note it. You can validate this point later in the crossing with the advices of your peers.

Stay Humble
Whatever the number of interactive applications you've already designed, keep a fresh look at your work and stay humble. Experience accumulates but each project is unique with its own challenges. Make every project a little more successful than the previous one.

Be Proud
The design of public interactive systems is a difficult task. Be proud of the work you have done.

In the next post, I'll talk about some lessons learned in terms of UX design.

No comments:

Post a Comment