
I find it particularly enjoyable to read entrepreneur and startup stories. Of course, mainly stories with good outcomes get circulated but I enjoy a quality about them that is reminiscent of any classic hero story formula. The great thing is that you as a reader might have real-world connection to aspects of the story either through similar experiences or because you know their product or industry.
For example, I think a big part of what would make reading the Google story interesting is the fact that it's something you use and know about and you could become aware of how it came to be. Then again, I'm an absolute documentary nut and I don't read much fiction.
I stumbled across this book while browsing the web, Founders At Work: Stories of Startups' Early Days. The quotes are pretty interesting and I enjoy that the page numbers are cited, giving a sense of how the book might be paced and the range of variety.
I think I'll pick up a copy at some point and I hope that it will differ from other startup story books by presenting an interesting cross-section of startup lore as opposed to one profile that is drawn out for longer than necessary.
Saturday, April 14, 2007
Entrepreneur Stories Are the Best
Posted by
Eric
at
6:31 PM
0
comments
Labels: books, entrepreneurs, Founders At Work: Stories of Startups' Early Days, startups
Friday, March 16, 2007
Unfinished Reading
I am reading a bunch of books that are at various stages of being finished.
Starting to read a book usually has one of, or a combination of the following reasons:
- It's damned interesting
- It could be useful for schoolwork
- It could be useful or is necessary for work
- Someone gave me the impression that I should read it
Usually, the problem with finishing them before starting the next one is some combination of the following reasons:
- Periodicals get in the way. They're interesting and bite-sized and damn do I have a lot of them!
- One of the four above reasons become heavily weighted due to prioritizing needs and requires a change in reading material
- Material isn't suitable for short reading sessions - it's too dense or not as meaningful in little pieces
- Book is a PDF or e-book tucked away on my computer somewhere and outta sight, outta mind
- Not using bookmarks and/or reading late at night mean re-reading sections again and again
- I'm pretty sure I read more slowly than most people :-(
I can't wait 'till spring break…
Posted by
Eric
at
1:46 PM
1 comments
Labels: books
Sunday, March 04, 2007
Unlikely Cognitive Enhancers
According to neurological and psychological research referenced in Don Norman's Emotional Design, objects that make us happier are, in practice, easier to use (all other things equal). The explanation is that when we are happy, we are more creative and patient. Being creative and patient leads to reduced terminal errors and improved perception of usability. Fascinating, considering the usable aspect of the object need not be the only design variable contributing toward overall usability.
Thus, one is led to consider this: if we are happier, we're more creative and patient and things around us are easier to use and understand. Besides being motivation for living happily, I wonder if this also implies that mood enhancers are also forms of cognitive enhancers. I've seen recent news reporting that some very fascinating ability enhancing drugs which include reducing the needed amount of sleep and increasing cognitive abilities. A "smart pill," if you will.
I wonder how direct or indirectly these smart pills enhance cognitive abilities. Do they directly act on physiological, chemical, and electrical needs for cognition or do they do it more indirectly, for example, through mood enhancement? I love that no matter how you cut it, the human is a complex animal with a very "messy" cognitive system.
Posted by
Eric
at
9:01 PM
0
comments
Labels: books, cognition, Don Norman, Emotional Design
Thursday, March 01, 2007
Disaster by Committee
I already know Information Dashboard Design by Stephen Few is going to be a decent read because by page five, I'm greeted with this remark:
Customers are expert in knowing what they need to accomplish, but not in knowing how software ought to be designed to support their needs. Allowing customers to design software through feature requests is the worst form of disaster by committee (Few, 2006).
It's been a while since I first unsuccessfully tried articulating why plain old customer feedback and feature requests don't guarantee great products. What makes a human factors specialist's interpretation of user needs more useful than the user's own voice?
I've seen more specific (but less elegant) arguments than Few's. One of my favorite answers relies on the fact that most users you'd encounter have no idea about what your company can and can't produce - they're not qualified to define product specifications.
I think what we learn from users is more useful for defining product requirements. What are the goals of the users? What do they need to accomplish these goals? What kinds of tasks do they perform to achieve their goals? Human factors specialists should elicit and then organize the answers to these questions, helping to define the actual product specifications.
A common area of contention is, "Why do we need so much interaction with the users?" This is a valid question considering we might have: "obvious" design needs, feature requests, and clear customer feedback.
In response, I would say that a keen observer watching users can not only get user information with much higher fidelity but also with much greater validity. I suppose it's worth mentioning that users report incomplete and/or misleading information - watching users actually using the product gives you the whole picture and that picture is more contextually situated.
Posted by
Eric
at
11:57 PM
2
comments
Labels: books, Information Dashboard Design, user-studies