Вы находитесь на странице: 1из 23

Constructing The HauteLook Mobile Experience

Who am I? Kevin Diamond

CTO of HauteLook Oversee all custom applications built in-house and out Major focus on customer experience based applications Utilize Agile SCRUM and Lean Kanban SDLC Build web apps for Desktop, Mobile and Tablet (from here out I will refer to Mobile as inclusive of tablets) Build native applications for iPhone, iPad and Android

Who is HauteLook

Private sale, members-only limited-time sale events Premium fashion and lifestyle brands at exclusive prices of 50-75% off Over 20 new sale events begin each morning at 8am PST Over 8 million active members Acquired by Nordstrom in 2011 Increased sales by over 60% in 2011 and on pace to do the same in 2012

Mobile Is

Small Slow Hard Confusing Fragmented

But its also Growing Powerful CAN be a big sales generator for your business

HauteLook Mobile Is
iPhone (Oct 2010), iPad and Android (Sep 2011) apps now available, with experience tailored to each device Over 700,000 app downloads Mobile now represents up to 25% of weekday logins and 35% on weekends Mobile now represents up to 20% of weekday revenue and close to 30% on weekends Sometimes our core member prefers using her phone to shop HauteLook, even when near a computer

Key Points

Measure everything before and after Outsource first if unsure of market, but know insourcing it later is hard, costly, time consuming Speed and performance are crucial for customers to use your device UI is a must for getting the smaller platform right Building for mobile is a lot harder than building for desktop, so hire appropriately. Testing is MUCH harder. If you can, go Mobile First

Measuring Before
First thing we measured is what operating systems our members use HauteLook decided to build for iOS native app and a generic Mobile website first Why? Because thats where our members were

Mac iOS Android Other

iPhone vs. iPad

iOS is inclusive of both iPhone and iPad But, Very different use behavior iPhone usage is primarily on-the-go Which is great for us since our sale events begin at 8am iPad usage is primarily on the sofa or over the weekends iPad provides a much larger screen space, and our website looked great on it So really, iPhone was what we needed first

In-house vs. Outsource

We now had decided what apps we were going to build, iPhone native app and a generic mobile website We found the pool of outsource agencies for mobile development are mixed (at best), and you will pay a premium because its the HOT new thing Outsourcers will almost always reuse code for many applications, so rarely the best approach for your specific app Even with outsourcing much of the work was still on us:
We had to fully manage the project to stay on schedule/budget We had to do much of the testing We had to build all of the webservices/APIs for the thing to work

Outsourced First

We chose to outsource our first version because we had no expertise in-house We had a great experience with the outsourcer building our mobile web app A far less than desirable experience with the iPhone build (Based on our vendor, not the platform in general) We built in-house our v1 API which was used by both


Now Were In-house

We saw great success with our initial launch Determined mobile was Strategic for our business So we decided to hire the RIGHT people and bring development inhouse after the initial release We also decided this was the time to build for iPad as well There is still a big learning curve
Performance issues are hard to know/handle/find So much can go wrong from a dropped connection

We had to hire Dev, QA and UI people who knew mobile development But, we found the v1 of the code done outside was going to be almost entirely replaced
Odd proprietary or third party libraries reused for odd purposes No clear understanding of transactional application models Poor error handling

Building Native Apps is Hard

Memory Management, Small Processors, Dropped Connections, Speed Constraints, were all new problems Understanding standards of the device platform and how to appropriately use those requires a good UI/UX person Simplicity is key for a successful experience, almost opposite from the desktop web Need APIs that bring all major functionality to the new platform, so double the building for all new functionality


Supporting Native Apps is Harder

The rest of your team needs to become dedicated to maintaining your APIs and their up-time (hard if nothing else uses them) Testing must be extreme, takes weeks not minutes to get new releases out to all customers, so bugs are very costly Beta test internally with employees to find bugs the average person might see, but your developers will miss Beta testing internally is not easy to get the app on to peoples devices, often have to use tools like TestFlight If development isnt in-sync, new features will come to desktop web first, and later to your app which requires a lot more communication internally and externally What versions of what devices will you support? (iOS 4+, Android 2.0+, Touch-based Smartphones, etc)


So what about Android?

Everyone was building Android apps So, we decided we would build an Android app Pretty much a mistake (for us) Market share of our members who had Android MUCH lower than iOS, but still higher than anything else Found the $/Login similar between members BUT they dont download and use apps nearly as much Lesson learned. We build native only for iOS and then a generic Mobile Web for everyone else.


Measuring Constantly
We defined success as growing usage by members
Both logins and sales as absolute and as a percentage

Measuring marginal increase in sales due to mobile apps is hard and rarely accurate We figured an increase would come as we transitioned traffic

So first we measured both logins and percent of sales on mobile

Q3/2010 Q4/2010 Q1/2011 Q2/2011 Q3/2011 Q4/2011


Measuring More
Next we needed to know if Mobile was really working So we compared the conversion on mobile vs. desktiop But we quickly learned some people START a purchase on mobile, but complete it on the desktop We assume these count towards mobile since without it the process would never have started

Q3/2010 Q4/2010 Q1/2011 Q2/2011 Q3/2011 Q4/2011


Measuring Even More

We measure analytics on every event We measure the performance of the app Use Google Analytics for all of this


App Store Reviews

Very public reporting of all issues people have with the app Also people will evaluate your business
Business Practices Business Model

No way to contact or respond to complaints, even if its with a fix No way to identify the user to look internally at what problem they might have had



Push messages are to mobile as email is to the desktop But device tokens expire quickly (think constantly changing email addresses) Lots of moving parts to get them to work right Much harder to send in bulk Overall more finicky and harder to manage Very limited in size of message


What now? Mobile First!

All features we build are built into our versioned APIs All applications (desktop web to admin tools to iOS) must use the APIs only, meaning our APIs must always work We combined codebases for all web (desktop and mobile) which requires much less maintenance and just independent view layers If you can solve a display problem on mobile, you can solve it anywhere, provided a much better user experience overall If you can build something that performs well on mobile, it will scream on the desktop


Whats next?

Improving iPad Browser experience with touch-specific features of our desktop web Building a touch-specific HTML5 mobile web experience Going to try wrapping the above HTML5 in a native app via PhoneGap (wish us luck!) to get into Windows, Blackberry App stores


The Recap

Measure everything before and after Outsource first if unsure of market, but know insourcing it later is hard, costly, time consuming Speed and performance are crucial for customers to use your device UI is a must for getting the smaller platform right Building for mobile is a lot harder than building for desktop, so hire appropriately. Testing is MUCH harder. If you can, go Mobile First


Thank you!

Thanks for taking the time with me today If you have questions, please email me kevin@hautelook.com Suggested reading: Head First Mobile Web by Lyza Gardner & Jason Grigbsy