Constructing the HauteLook Mobile Experience

8/2/2019 Constructing the HauteLook Mobile Experience

1/23

Constructing TheHauteLook

Mobile Experience


2/23

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 referto Mobile as inclusive of tablets)

Build native applications for iPhone, iPad and Android

Who am I? Kevin Diamond

2


3/23

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

Who is HauteLook

3


4/23

Small

Slow

Hard

Confusing Fragmented

But its also

Growing

Powerful

CAN be a big sales generator for your business

Mobile Is

4


5/23

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

HauteLook Mobile Is

5


6/23

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

Key Points

6


7/23

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

Measuring Before

7

Windows

Mac

iOS

Android

Other


8/23

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

iPhone vs. iPad

8


9/23

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

In-house vs. Outsource

9


10/23

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

Outsourced First

10


11/23

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

house 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 almostentirely replaced

Odd proprietary or third party libraries reused for odd purposes

No clear understanding of transactional application models

Poor error handling

Now Were In-house

11


12/23

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

Building Native Apps is Hard

12


13/23

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 communicationinternally and externally

What versions of what devices will you support? (iOS 4+, Android

2.0+, Touch-based Smartphones, etc)

Supporting Native Apps is Harder

13


14/23

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.

So what about Android?

14


15/23

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

Measuring Constantly

15

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


16/23

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

Measuring More

16

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


17/23

We measure analytics on every event We measure the performance of the app

Use Google Analytics for all of this

Measuring Even More

17


18/23

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

App Store Reviews

18


19/23

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

Notifications

19


20/23

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 onthe desktop

What now? Mobile First!

20


21/23

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

Whats next?

21


22/23

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

The Recap

22


23/23

Thanks for taking the time with me today If you have questions, please email me

[email protected]

Suggested reading:

Head First Mobile Web

byLyza Gardner & Jason Grigbsy

Thank you!

23

Constructing the HauteLook Mobile Experience

Documents

Transcript of Constructing the HauteLook Mobile Experience