My new phone
Someone on another site asked about the Hero vs the iPhone, here is the review I gave:
I just got the Sprint HTC Hero on Sunday and its good and bad. From a usability perspective iPhone wins through its limited simplicity. Mastering the iPhone didn’t take long because Apple tends to limit access to functionality to improve the user experience. The Hero by contrast has a ton of features that I feel like it will take me months to master if I ever do. Plus since its not entirely screen based there are things that feel hidden because you have to use the buttons to access them. Weirder still is the fact that some things you have to tap and hold to get yet another menu for options. So figuring out the trick isn’t entirely elegant.
Other little things like the wifi connection is a little wonky and if you set a lock passcode you have to unlock the phone before you can put it on silent or turn it off. Seems like an oversight to me.
Another thing that seems to have come up is battery life. I’m not sure what the reason is but my battery died at 3pm yesterday after a full night’s charge. Today I turned off the wifi, bluetooth, and gps and here at 3:21 I have 3/4 battery left so that may have been the cause. Whatever it is the thing seems to be a battery hog.
Those things said I would say based on the phones I tried looking for an iPhone (read: AT&T) replacement the Hero is a close second to the iPhone. Sense is for the most part pretty well thought out. The multiple home screens with the HTC widgets and options to customize are great. Having the ability to create several “scenes” or home page configurations is another great feature. You can set up your screens how you like for work, save it, then set it up for the weekend, save it, and call them back whenever you want. Probably my favorite feature.
If you use your Google account heavily like I do you’ll also like the Google integration to populate your contacts and to access the Google widgets you can get in the market. Plus you can sign into Facebook from your contacts and link the contacts with your friend’s accounts to populate some information.
The camera from what I’ve seen is better than the iPhone’s camera, and the speaker is loud as hell but switching to speakerphone isn’t obvious since I haven’t found it yet. But you do get visual voicemail and the speaker button is right on that screen for VM.
As for the app store (Market), you’ll find yourself wishing you could find an app for this or that the way you could with the iPhone and there seems to be less free options out there but in hindsight the free options were always just previews on the iPhone app market. What I’ve found is that I’m not as much a slave to the apps as I was on the iPhone. I don’t feel the need to constantly take out my phone and fiddle with it since I don’t have all the mindless diversion apps like I did on my iPhone. So its a mixed blessing.
But the thing that really makes it a must have for me is the fact that I’m paying the same amount I was paying for my iPhone by myself for a family plan on Sprint that covers me and my girlfriend with 1500 minutes, unlimited data and messaging, and a navigator built in. By contrast I had 450 minutes, no messaging, and no navigator with my iPhone. Plus the network is better in the Bay Area.
My advice is run, don’t walk, to the Sprint store to pick it up and get rid of AT&T. And if you want to list me as a referral I’d take that too 
.
Thoughts on enterprise software development
The current division of labor in regards to understanding user requirements coupled with our aggressive focus on validating existing patterns within the framework of the product planning process is increasing the likelihood of developing stagnant software that does not adequately address the customer’s needs. It would be worthwhile to adjust the roles of our User Experience and Product Management teams so that they are working together to put together user stories and market analysis for a given product prior to development. This way they will spend design time creating innovative solutions around established patterns and user requirements in a way that increases the probability of designing the right solution to the right problem This is key to avoiding team arguments and ineffective user testing that can be mitigated by the right research up front.
Problem Statement
The current process of application design and user validation may be doing more harm than good. In this process the Product Manager assesses the market and meets with customers to get a sense of what the product must do to be competitive and salable. This information is then communicated to development managers who in turn communicate this information to the design practitioners. The information is combined with technical requirements and limitations to design said software. From this process we get the validation scores and requirements based on existing process templates. Throughout the process of software development the UX team is tasked with regular and frequent user validation studies. These studies target the software’s functions as they pertain to the development goals and requirements.
Herein lies the problem. The development goals are derived from the use cases and user stories defined by the Product Manager. These definitions tend towards vague and based more on market research regarding where a product should exist, not so much how it should work. When use cases are defined specifically from customer feedback they are oft times too specific and run the risk of solving a single customer’s requirements that may or may not reflect the potential market. Also, user tasks are rarely generalized across a suite of products for similar customers when defined up front, if they are defined up front. Many times we get user stories and use cases towards the middle of development.
Based on the information we receive, invariably we will end up defining development goals we know we can test and pass regardless of the actual product. Then when testing we design our tests, and to some extent our software, to the purpose of fulfilling those development goals. This ensures that we make the safe decision in our design choices. Safe choices tend to deviate as little as possible from the established design of the product or at least what has come before.
Furthermore, the practice of aggressive validation can make it appear to development teams that a delivered design is at best an educated guess that we need users to validate before standing behind it as opposed to a valid solution by an educated professional. The test process also becomes a trump card to be used by a developer, whether alone or in a group, when they challenge a design decision. Regardless of how standard a design is, or how ridiculous the challenge can be, a demand to test with users can rarely be denied and can be a waste of time and money for everyone involved.
Proposed Solution
To begin to address this situation we must first look at the backgrounds of the people involved. Product Managers tend to be business focused with a technical background. Interaction designers tend to have backgrounds in user research and design principles. For this reason it would seem that an appropriately staffed UX team would have more expertise to gather the feedback from existing and future customers as identified by management or sales. In this new organization, the UX, PM, and Development Management teams would share the responsibility of creating user stories, use cases, and product requirements. The UX teams would meet with end users and stakeholders at participating customers to create a complete profile of our customer base and the types of tasks they are working to accomplish which they would combine with the state and future of interaction design based on solid usability principles. The PM teams would keep their finger on the pulse of the market and the direction of the business including initiatives, marketing, and sales information. Development management would represent the technical side of development and drive the direction of the product from a technical standpoint.
The design research would allow much of the UI direction to be identified before development even starts so that it can be adequately accounted for in the planning cycle. User testing of prototypes and usability models should be done independent of a product cycle. This research can then benefit all products and we spend less time applying design solutions to already poorly designed user interfaces.
From the UX side of things, this research would help define commonalities among our users and help drive consistency goals. A push towards consistency will help drive reuse in design and as a result ease the user interface design of most of our products by establishing a documented set of patterns to be used by all products. That being the case, this also decreases the need and value of aggressive user validation. We will know the designs work as a culmination of our design research. This does not, however, presuppose that all design work will be front-loaded and implemented like a waterfall process. The intent of this is to get a complete picture of the types of users we will be designing for and the tasks they are likely to complete. It will also help drive the preliminary work done to establish the basis for UI development. This information gained before the design process will help mitigate the debate and delay inherent in gathering the information during the design process. The current practice of UX and Development teams working together towards a common design solution should continue.
Since we’ll have the ability to answer a lot of usability questions at the time of design, we’ll be able to scale back the aggressiveness of the user validation testing and free up time to do more design and implementation work. This will also improve the quality of tests since the information gathering will be done with wireframes and mockups and the actual testing is more likely to be done with live code so the feedback will be more appropriate. In this spirit, we would be able to reduce the number of test sessions to 2 or 3 to establish a baseline, respond to issues, then get feedback on the fixes which would likely satisfy development goals.
The weakest link
A little over two years ago I paid off a student loan and as a way to reward myself I switched from Verizon to AT&T and got myself an iPhone. Granted, I’m what my friends call an Apple fanboy. I have iMacs, Macbooks, and an Apple TV. I like their stuff and have no qualms paying the Apple premium for well designed status computing so this wasn’t exactly a surprise that I would buy an iPhone on an impulse.
Even beyond the Apple brand, as an interaction designer I’m a big fan of the user interface. At first use it is an elegant and easy to use device which, I believe, earns its reputation as the standard by which smartphones should be judged. No other phone at the time had demonstrated such a departure for phone interface technology and had set the bar so high.
But even as Icarus’ beautiful wings brought him too close to the sun resulting in his demise, the perceived bar set by the hype surrounding the iPhone quickly gave way to reveal its flaws. Despite the immediate discussion on the web surrounding its missing features, it seemed like whenever there was an update to the software or functionality of the device, it was accompanied by the thought of “why didn’t they think of this before?” Things like copy/paste, MMS, GPS, and the new applications management in iTunes 9. Apple makes excuses that usually amount to their assertion that they want to get something perfect before they release it but if I had to guess it had more to do with management processes than code quality. Nevertheless, its a solid device that has done a world of good to bring good usability to the masses in a big way.
But I digress, this post is really about the weakest link, the cautionary tale that I wish Apple would have thought about beforehand. I’m talking about AT&T. As the story goes Apple approached Verizon first who balked at the profit demands Apple was requesting. They then went to AT&T and the rest is history. The problem is that most of the complaints about the device could be forgiven if the AT&T service was not so horrible. Every time Safari crashes, every time you had to use viewmymessage.com, or you dropped a call, regardless of whose fault it was, the device in your hand was the object of your anger.
As a result it seems to me that Apple has really tethered itself to an albatross. AT&T has service that seems to go for quantity over quality. Granted, I can use my phone all over the world, but what good is that when I can’t use it in my own neighborhood. Sure I can download a billion apps . . . if I’m connected to wifi. Its taken 3 years to provide services available on almost every other phone in their arsenal.
Frankly, I’m fed up. I pay an ungodly amount each month for the service so I’m jumping ship to Sprint for the HTC Hero which has an impressive UI in video that I plan to do an in depth review of in a future post. Plus the rate plan is significantly cheaper for more services.
The point I’m getting to is that I think Apple has given themselves a burden to overcome by sticking with AT&T. The network can’t keep up with technology coming from Apple and as a result Apple has to pretend like its all by design when its obviously no their problem. I think Apple (fortunately) and AT&T (unfortunately) will do fine. But I think that this is, and has been, an opportunity for Google with their Android framework. I’m not sure what their plan is but it seems similarly odd that they so far have tethered themselves to T-Mobile (in the US).
I would imagine that the public shortcomings of AT&T and the iPhone would be an obvious target for Google to make a huge push to improve and drive adoption of Android. Luckily we should have a new handful of Android phones coming in the next few months on Sprint and Verizon so we should get a sense of how deep the AT&T backlash can go. I know several people besides myself that are planning on jumping ship from the iPhone when their AT&T plans are up. So I suppose when the smartphone field starts to open up we’ll see what happens.
So here we are again.
Welcome to ninjasavant.com. I’m getting things set up around here but I’ll start using this blog to chronicle my various thoughts on interaction design, social issues, or whatever else comes to mind. Thanks for stopping by.
rob.