Top designer from a search engine giant left saying,
“When a company is filled with engineers, it turns to engineering to solve problems. Reduce each decision to a simple logic problem. Remove all subjectivity and just look at the data. Data in your favor? Ok, launch it. Data shows negative effects? Back to the drawing board. And that data eventually becomes a crutch for every decision, paralyzing the company and preventing it from making any daring design decisions.
Yes, it's true that our team couldn't decide between two blues, so they're testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. I can't operate in an environment like that. I've grown tired of debating such miniscule design decisions. There are more exciting design problems in this world to tackle.”
I have different perspective on this subject. One of the prime objective/use case of designing is to provide elegant and easy to understand view of information(i.e. data). Isn't data, the prime factor to drive UI design ? Internet and WWW is all about sharing of data in different forms. Yes, if data doesn't looks good or is not applauding to customers, one must go and reinvent the wheel.
Being an engineer and not a designer, I would not care that much about shades, dimensions and style of a component. From business point of view, it matters a lot and it does make a difference. Example, read story : 'How Changing a Button Increased a Site's Annual Revenues by $300 Million'.
This is my - an outsider's relative opinion on the subject and with all respect to that top designer.
Saturday, March 21, 2009
Wednesday, February 18, 2009
Framework dilemma
I had written generic framework for performing group, addition and sorting operations in code on fields of record set. One of my colleague was working on task where in this framework could be reused. After going through on how to use it, he mumbled "how complex". Err. I was bit surprised , as tried my best to keep it simple and neat.
Consumers perspective might be totally different than developers perspective in most of the cases.
1. A1 = (T1 - T2) / ( T1 + T2)
T1 = Time required for task without framework/library/third party code
T2 = Time required for task with framework/library/third party code
2. A2 = F1 / F2
F1 = Features consumed for task
F2 = Total features provided by library
3. A3 = All additional overheads in terms of memory,CPU consumption, rework required if any. It should be weighted between 0 - 1.0, totally depends how much critical these factors are for the application.
V(%) = A1 + A2 - A3 * 100
V = Final value of Framework/library/code for consumer
If V > 30%, go ahead use it.
Consumers perspective might be totally different than developers perspective in most of the cases.
- He/She do not have clear understanding of efforts that will require in using straight forward approach rather than using any framework and possibility of that code getting repeated.
- Framework cannot be made more simpler and cleaner: Kick your ass, Some things can only be done in dirty ways !
- Crucial - It was developed in a limited time frame. Its very important to realize that the tool(not a GOD) is not going to fix each and every worlds problem, but it is extremely handy in instrumenting its intended functionality, was developed in a limited timely frame.
- No love for frameworks: Often developers hate to use/consume code written by co-workers/buddies. Even if you follow general organization coding standards, practices, there are differences in the way people code and meant it.
1. A1 = (T1 - T2) / ( T1 + T2)
T1 = Time required for task without framework/library/third party code
T2 = Time required for task with framework/library/third party code
2. A2 = F1 / F2
F1 = Features consumed for task
F2 = Total features provided by library
3. A3 = All additional overheads in terms of memory,CPU consumption, rework required if any. It should be weighted between 0 - 1.0, totally depends how much critical these factors are for the application.
V(%) = A1 + A2 - A3 * 100
V = Final value of Framework/library/code for consumer
If V > 30%, go ahead use it.
Tuesday, February 10, 2009
Letter from a laid-off manager - an eye opener
I got a forward from my friend, whose x-manager was laid off in his company. What ever he has written, is applicable in recession scenario as well as in general.
He wrote,
How will you react ?
He wrote,
"My forced vacation did not last long. I have joined X company today. I have got just the kind of work that I was searching for, besides the office is located only 2 kms away from my home. This will keep my bicycle rolling more. The lay-off turned out to be a blessing in disguise :)
Some lessons learnt from this episode:
Some lessons learnt from this episode:
- Don't ever think that you are un-touchable in times of recession. That adds to the gravity of the impact.
- Don't wait for your turn to come. If you think you are not enjoying the work, or you have different opinions on how/where the company is going, then it is time for you to move on.
- Don't panic. This is a global phenomenon, you are not the only one to get laid-off. Don't go in the self-doubt phase.
- Keep your personal foot-print on the company resources (email, harddisk) very small.
- Utilize this time well. Read some books to refresh your knowledge, do something that you enjoy the most."
Subscribe to:
Posts (Atom)
