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


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 3 .Who is HauteLook • • • • • • Private sale.

Mobile Is… • • • • • Small Slow Hard Confusing Fragmented But it’s also… • Growing • Powerful • CAN be a big sales generator for your business 4 .

with experience tailored to each device • Over 700. iPad and Android (Sep 2011) apps now available.HauteLook Mobile Is… • iPhone (Oct 2010). even when near a computer 5 .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.

• If you can. Testing is MUCH harder. but know insourcing it later is hard. 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. go Mobile First 6 . so hire appropriately.Key Points • Measure everything before and after • Outsource first if unsure of market. costly.

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 that’s where our members were Windows Mac iOS Android Other 7 .

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. iPad • • • • • • iOS is inclusive of both iPhone and iPad But. and our website looked great on it • So really.iPhone vs. iPhone was what we needed first 8 .

In-house vs. and you will pay a premium because it’s 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 9 . 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).

not the platform in general) • We built in-house our v1 API which was used by both 10 .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.

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 11 .Now We’re 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.

Small Processors. 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. Dropped Connections. so double the building for all new functionality 12 .Building Native Apps is Hard • Memory Management. almost opposite from the desktop web • Need APIs that bring all major functionality to the new platform. Speed Constraints.

new features will come to desktop web first. etc) 13 . Android 2. and later to your app which requires a lot more communication internally and externally • What versions of what devices will you support? (iOS 4+. takes weeks not minutes to get new releases out to all customers. but your developers will miss • Beta testing internally is not easy to get the app on to people’s devices.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. often have to use tools like TestFlight • If development isn’t in-sync.0+. so bugs are very costly • Beta test internally with employees to find bugs the average person might see. Touch-based Smartphones.

So what about Android? • • • • “Everyone” was building Android apps So. 14 . but still higher than anything else • Found the $/Login similar between members • BUT they don’t download and use apps nearly as much • Lesson learned. 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. 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 15 .

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 16 .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.

Measuring Even More • We measure analytics on every event • We measure the performance of the app • Use Google Analytics for all of this 17 .

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 it’s with a fix • No way to identify the user to look internally at what problem they might have had 18 .

Notifications • 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 19 .

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. provided a much better user experience overall • If you can build something that performs well on mobile. it will scream on the desktop 20 . you can solve it anywhere.

Blackberry App stores 21 .What’s 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.

so hire appropriately.The Recap • Measure everything before and after • Outsource first if unsure of market. 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. costly. • If you can. Testing is MUCH harder. but know insourcing it later is hard. go Mobile First 22 .

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