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

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

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

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

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 .

iPhone vs. iPhone was what we needed first 8 . 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.

Outsource • We now had decided what apps we were going to build.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 . iPhone native app and a generic mobile website • We found the pool of outsource agencies for mobile development are mixed (at best).

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

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 . QA and UI people who knew mobile development • But.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.

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

etc) 13 . new features will come to desktop web first. 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 people’s devices. takes weeks not minutes to get new releases out to all customers. and later to your app which requires a lot more communication internally and externally • What versions of what devices will you support? (iOS 4+. often have to use tools like TestFlight • If development isn’t in-sync.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. Touch-based Smartphones.0+. Android 2.

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. 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 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 . desktiop • But we quickly learned some people START a purchase on mobile.Measuring More • Next we needed to know if Mobile was really working • So we compared the conversion on mobile vs.

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

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

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 .

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

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.

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

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 . please email me kevin@hautelook.