Ryhan Hassan
-
Harper's Blog: Doug Android
He was contempt with the setup he had, an music collection, a web browser app store to browse on his iPod and a communication device. Yes a bit more education and he may not have to only carry his android rather than two devices just for apps + media and be able to browse the internet on his phone: but does he really want to jump the gun and start paying data fees and submerge himself in tech, just for that?
Sometimes when debating whats best for consumers on a über nerdy level in our minority power user bubble we forget what consumers are doing and what they really need.
It may have a lot to do with the user interface. An iPod gives him a better multimedia experience (richer games, sleeker music player, smoother browser)… so much better in fact, that he doesn’t consider putting up with the lag on his phone.
If he didn’t realize that he could install apps… well, that might be a problem. A smartphone UI ought to be conducive to app-discovery: it should be plainly obvious that with a tap or two, he can search for an application to do whatever task he wants, install it with another tap, and then begin to use it within a matter of seconds. I fear LG may have thrown their own UI on top of stock Android, burying the App Market within several layers of menus.
Yes - it’s absolutely important to consider what consumers actually need - and we must design the device with this mentality.
(Source: maximharper)
-
Revealing the Unpolished.
While I love user feedback, I hate interference during the development process. It’s almost impossible for others to contribute ideas to unfinished products that don’t break from the core ideas surrounding the application. That’s why I’ve become hesitant to reveal work that is far from completion. First impressions count - when users see something I built, I want them to use it the way it was meant to be used, in a glorious, polished state. Invariably, when I show a preview to someone, they leave with a broken experience.
Developers and designers are highly encouraged to talk to users during development - but that doesn’t mean developers should ask users for feature lists. I’ve found that very few people know what they actually want - rather, they talk about a variety of related features specific to their needs. Someone else needs to be the one to step back and see the general class of problems the user is dealing with.
Fortunately, I usually _am_ the user. I build applications that deal with my problems, and are inherently tailored to my needs and lifestyle. I would much rather build something that perfectly fits me, than scramble to appease a few other people. Sure, based on user feedback, I might tweak a feature here or there, but don’t expect me to chuck in your 3 million features and a social network. My goal isn’t to build something to win over the world - I simply want to build a useful tool for myself that hopefully a few other people can benefit from. I gain little by doing large betas and asking for feedback from hundreds of users.
While my philosophy falls within the realm of “Genius Design”, I really detest the term - it makes passion for an application sound pompous. It’s not that “I always know better”, but rather “this app isn’t ready for you - yet”.
-
Light Switch Duplicity
Take a look at a light switch. Odds are, it looks something like this.
Your typical switch is meant to switch between two states, and reflect which state it’s in. When the switch is “down”, it’s “off”. When the switch is “up”, it’s on. There’s probably even text that indicates this.
Unfortunately, this standard is frequently broken when multiple switches are used to control the same light. Since switches can’t stay in sync, the state of the switch doesn’t always reflect the state of the appliance it controls. This duplicity prevents users from relying on the state of the switch as a hint as to what it controls.
For example, when users leave a room, it is fairly common to decide to turn “everything off”. When switches fail to map “up” to “on”, the user must try and flip each and every switch individually to turn everything off. If all switches were to correctly reflect the state of the lights they control, turning everything off is pretty trivial - just take one arm and flip every switch into the “down” position.
Aside from having switches mechanically flip to stay in sync with each other, this problem could be solved through an led-backlit button. Pressing the button would toggle between the “on” and “off” states, which would be reflected by an led.
Furthermore, an led-backlit button has the additional benefit of being easier to find in the dark, when finding a light switch is particularly difficult.
Page 1 of 22
