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

• If you can. so hire appropriately. 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. but know insourcing it later is hard. go Mobile First 6 .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 was what we needed first 8 . and our website looked great on it • So really.iPhone vs. 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 you will pay a premium because it’s the HOT new thing • Outsourcers will almost always reuse code for many applications. iPhone native app and a generic mobile website • We found the pool of outsource agencies for mobile development are mixed (at best). 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.In-house vs.

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 .

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

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

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

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 don’t download and use apps nearly as much • Lesson learned. 14 . We build native only for iOS and then a generic Mobile Web for everyone else.So what about Android? • • • • “Everyone” was building Android apps So.

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 .

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. 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.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. provided a much better user experience overall • If you can build something that performs well on mobile.

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

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

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