00:00:16.480
hi i am rebecca miller webster i am a ruby and javascript developer and i'm
00:00:22.320
currently a lead developer at how about we and i'm savannah wolf i'm a ux and
00:00:27.359
visual designer and i'm the head of design at hawaii so we're here to talk to you about incremental design which is
00:00:33.520
a process we've been using at how about we to pretty successfully make design changes and have development and design
00:00:39.600
work together yeah but before we talk about what incremental design is we're actually
00:00:45.120
going to talk about some of the ways that everyone here probably makes design changes
00:00:50.160
so when you're thinking of design changes you're probably thinking in like a pretty large scale and you're probably going to go down the
00:00:57.039
road of a major redesign and what this means for design and development is that you're really taking
00:01:02.719
like a month or two months or six months of time and you're dedicating your resources to creating this brand new
00:01:08.799
experience which is like awesome in theory right yeah but it usually doesn't work
00:01:15.280
out to be maybe the smooth process that you're hoping for as a designer my experiences with big redesigns are that
00:01:22.240
i dedicate my time and effort gathering requirements making sure that the user experience is great and the visuals are
00:01:28.479
beautiful and then i just pass it off because i need to move on to other projects and i
00:01:33.600
don't always know where it ends because developers need a substantial amount of time to work on the design and as a
00:01:40.159
developer you get this psd and either you're frustrated because it didn't take technical considerations
00:01:47.280
into the design or limitations or you go off and you do it and you feel like your total css javascript rockstar
00:01:54.479
and then it gets to design and they're like what the is this this isn't what i designed right
00:02:00.320
so that's bad and that's what we want to avoid okay so maybe you break it down a little
00:02:06.240
bit more maybe you have a page by page redesign and you're like supporting this
00:02:11.280
old design um you're creating a new one just on certain pages maybe certain features and it creates this like really
00:02:17.680
weird experience for your users and as a designer i like don't really know what to design do i design a new
00:02:23.840
feature in our old styles and our new styles do i create this like weird hybrid um and it's kind of confusing and
00:02:30.720
it's bad for users and we just like basically want to avoid it and it can be just as confusing for developers like it
00:02:36.400
tends to lead to a lot of technical debt you're supporting multiple style sheets multiple layouts you have to like
00:02:42.000
remember if you're killing something if you can kill these styles or not um so it's just kind of annoying you
00:02:48.160
mentally have to like know that that's there you have to test and maintain it
00:02:53.840
it's just doesn't lead to happiness for anyone it's weird so our solution is
00:02:59.840
incremental design so um as developers um and particularly the
00:03:07.680
ruby community over the past like five ten years we've talked a lot about software development best practices and
00:03:13.760
how to make software in a way that's maintainable and successful and really all of those things agile tdd sprints
00:03:20.720
boil down to making the smallest possible change and doing it in a maintainable testable way
00:03:27.120
and then deploying it and just doing that over and over and over again and basically incremental design is about
00:03:32.480
taking those same practices and philosophy to making design changes so really simply it's making tiny
00:03:39.280
deployable design changes and just doing that over and over and over again and kind of the overall theme of what
00:03:47.360
that creates is a communication between or a conversation between design and development um so that means that we're
00:03:54.239
talking more and we're on the same page and we're discussing these changes or challenges as we go and we're really
00:04:00.640
making the design um more beautiful and more like the experience more awesome and we're also making less friction in
00:04:07.840
our teams so just to give you a little context we work at how about we which was founded
00:04:13.840
in 2010 as a dating site that was focused less on like whether you like to
00:04:19.199
go on long walks on the beach or like how much you drink or whatever and more on proposing really awesome dates and
00:04:24.240
finding other people to go on those dates with you and then last year we launched how about we for couples which is a subscription
00:04:30.800
site that's a curated collection of really awesome dates for couples to go on and sustain their relationship
00:04:36.639
and what you're actually looking at here is our unified landing page and it actually embodies our third
00:04:42.639
product which is the how about we brand our design team is relatively new we're
00:04:47.680
less than a year old um and basically our focus on top of these two products
00:04:53.680
is creating this like universal design language for how about we and kind of evolving and enhancing the brand
00:05:01.680
so this is actually our dating site and this is an old design that was created by an agency and we're currently working
00:05:07.759
on redesigning the entire experience and we started that redesign process through our mobile apps
00:05:13.360
we've recently redesigned our ipad and iphone and working on an android redesign
00:05:18.639
and also now the full web redesign and how we're driving out that design is
00:05:24.320
through our couple's product so we've created this beautiful experience for our couple site
00:05:29.520
we really test and evolve the design on this product and we're using this language evolving into our unified brand
00:05:36.400
and then translating it to our dating product
00:05:41.919
so in addition to like the normal startup challenges of like aggressive timelines and changing models and
00:05:47.600
pivoting and all that stuff we have this extra challenge of having these two products that are in totally different places in their life cycle so the dating
00:05:54.880
site is established it's international we need to make sure that we're not disrupting their experience that it
00:06:00.880
keeps like rolling on and making us money and all that good stuff and then on the other side the couple's site is
00:06:07.039
like six months old we've changed the model like four times it's currently only in new york although it's launching
00:06:12.880
in san francisco in a couple weeks so sf people should sign up because it's awesome
00:06:18.160
so we needed a process that really worked for both sides of this equation
00:06:23.199
and then in addition as savannah mentioned with the brand there's like a renewed focus in the company on having
00:06:28.560
beautiful design and having that be part of everything that happens and then on top of that we make almost
00:06:34.080
all of our feature decisions based on split testing and metrics um so that's sort of like an additional level that
00:06:40.160
needs to be taken into consideration and if you want to learn more about that you should go see brian woods tomorrow
00:06:45.520
because he's giving a talk on this all right so let's talk about an example
00:06:50.800
so this is our couples product and this is actually a date details page so each date that we create on our service has
00:06:57.919
this really beautiful experience that is really photo and experience heavy to
00:07:04.080
help users understand really what they're getting for their money this date in particular is a yoga
00:07:10.080
instructor comes to your home teaches you a yoga lesson maybe brings wine like who doesn't love wine and yoga
00:07:17.039
but basically what we wanted to do we initially launched it as a members only service
00:07:22.800
and we wanted to open up buying dates to anyone so anytime we kind of come across
00:07:28.240
this we want to test an idea in our existing design so as you may be able to
00:07:33.520
see a little bit there's actually two prices on the side and it worked out well
00:07:39.199
people liked the dual pricing it was great for non-members to experience the site and also great for members to see
00:07:46.240
what a discount and what an advantage they got for membership okay so once we know that something's
00:07:51.360
great and then we want to dedicate some real design to it we go into the design process and here
00:07:57.440
you can see this is like our end goal design one thing you'll notice is this dual
00:08:03.039
pricing on the side that is like a much more featured pricing structure really outlines
00:08:09.199
the comparison of membership and non-membership and then creates these universal
00:08:14.400
pieces of the design like pricing like a sub nav that we can use throughout the site and really when we're designing
00:08:20.560
we're thinking like v3 because we really break down this design to what is necessary and what should be a priority
00:08:27.039
and from there we pass it off to development and they kind of work on what the next piece of this part is
00:08:33.200
so you may have looked at that and been like i could totally bust that out in half a day and i'm sure that you could but we're
00:08:40.080
not going to do that we didn't do that we really wanted to break things down in the smallest possible components that we
00:08:45.360
could so the most obvious thing looking at this is just to move the rail from the right to the left
00:08:51.200
which feels really stupid and is in some ways but it actually completely broke the experience on tablet and mobile
00:08:57.120
um and it was actually really great that we got to have that conversation about what we
00:09:02.560
wanted to do about it like almost immediately as opposed to having it once people had sort of like emotionally
00:09:08.160
invested in putting all this effort into it and then even if we had done this later because we're
00:09:14.000
deploying everything in such small stages we could have just reverted that one tiny part of this design instead of reverting
00:09:20.480
the entire design in general so in this particular case we decided to move forward with some small
00:09:26.399
tweaks because we had already prioritized a mobile-only version of this page anyway
00:09:31.920
but if we hadn't we we really could have made the best decision for the product instead of like getting people's
00:09:37.680
emotions involved so the next thing we did is change the pricing so part of incremental design is really
00:09:43.760
about having these reusable components of design that can sort of float throughout the site and can be reused
00:09:49.200
everywhere so this pricing is actually used on the home page the table of contents billing
00:09:55.519
people subscribing and paying us so it was really important that we do it in a super isolated way and that the user
00:10:00.959
have a really consistent experience around our pricing so the next thing we did was just move
00:10:07.519
the nav to the top and so this set a precedent of like where our sub navs were going to be in general in the site
00:10:14.720
and you also may or may not notice that the bottom half of the rail is a lighter gray which i know just hurts savannah's
00:10:21.040
heart but she let us do it anyway i will um i think a big part of this is like
00:10:26.720
some of the pieces from a design perspective like doesn't don't always look perfect and that is painful but
00:10:33.120
like realistically will your users notice and like this i think was maybe live for a day um so
00:10:40.720
you really have to think about like what's best for your product versus like oh well i'm a designer and this is beautiful or like oh this is exactly how
00:10:47.920
i want it because it's not really about you um so we kind of moved on and we let
00:10:53.440
this happen and the next step was obviously to fix the things that were kind of like painting our hearts
00:10:59.440
so we updated that and we also added an internal navigation okay so if you remember this was like
00:11:05.680
our visual ideal um and this is where we ended that
00:11:10.880
project and that's okay from a design perspective having these conversations and like really understanding like
00:11:16.800
product decisions and prioritization we knew that like one we don't need to reskin these social
00:11:22.399
buttons because we're like not really pushing social right now or like we can come back to this design if we get to a
00:11:28.800
point where we want to make these fine-tuning things but we have bigger fish to fry so we're going to go ahead
00:11:33.920
with that but basically what this process is is like this feedback review loop
00:11:40.800
and anytime design starts a project we start involving development immediately so we
00:11:47.760
get a design request we start gathering requirements we think about what we need
00:11:52.800
to accomplish and then as soon as we have like wireframes or options we bring in development and we ask kind of two
00:11:59.040
questions one being is this possible and because we work with awesome developers
00:12:04.079
the answer is usually yes but i think the smarter more important question is is this possible in the
00:12:10.560
timeline that you're actually going to have and the answer to that is often no but there are little tweaky things that
00:12:17.360
we can do to our design to make it functional immediately so one thing is we'll maybe have many
00:12:23.440
options that we can talk about and figure out what would be the easiest thing to do and on top of that it's just like
00:12:29.519
relying on developer knowledge to really get um the most effective end product and we're happy with that because then
00:12:35.920
we know that our designs are actually going to become live and then we pass it off and so once we get it if possible we
00:12:42.639
actually build the feature with our existing styles with without changing anything or very little and then we
00:12:49.519
go over to the designer and say what do you think of this what's the priority what should we change maybe it's fine maybe it's not
00:12:55.760
and often we kind of cut out some work by just doing that and it also sort of makes sure that everything is consistent
00:13:02.880
and then regardless of whether we use existing styles or not we always check in with design before
00:13:08.399
we commit our code and do a pull request and deploy and unlike a major redesign where you have this like 75 minute
00:13:14.959
conversation and get like 85 million tweaks on the page these are literally like five minutes or less and it's
00:13:20.320
usually like can you just move that over 10 pixels or whatever um and so they're usually pretty straightforward and the
00:13:26.079
more that we do this process the shorter those reviews become because everybody's kind of on the same page and you're
00:13:31.600
building trust yeah okay so what are some like weird unique
00:13:37.040
things that we do in our design process um we actually are a little bit ideal at
00:13:42.560
how about we i think because we had a young design team that was created after the
00:13:48.079
product was already out there but i think aligning yourself with development is kind of a huge deal and as a designer
00:13:54.560
i've never like even if i know about the agile process or i know that you work on sprints like i'm not fully aware of all
00:14:00.880
the like little pieces of that so actually what we do at how about we is we use sprints reviews and retros in our
00:14:07.680
design process so as a design team we work on one week sprints and the developers actually work on
00:14:14.639
two-week sprints but the idea of having sprints and like understanding how to organize your work in that way
00:14:20.880
really helps understand how development happens we even do estimation so
00:14:26.720
we might have 10 projects a week and we assign them like their importance so it's not exactly the same but it's like
00:14:33.760
in the same system so we're understanding a little bit more how you can prioritize your work and having
00:14:39.199
these one-week sprints really allows you to bring in these reviews think about like when you can include people at the right
00:14:45.839
time and not stressing yourself and kind of maximizing on what's best for
00:14:51.040
your creative process and then finally i mean we talked about reviews but retros are a big thing for us too kind
00:14:57.680
of like talking about this process because we don't want to make it feel like a chore like it should just feel like a conversation and it shouldn't be
00:15:04.560
like oh i have to check in with development right now or else they're going to hate me forever um it's just
00:15:10.240
like a very like ongoing thing but if there is something that we can improve we do like to improve it
00:15:16.639
absolutely okay so from a development perspective there are a couple things that we've added to our development
00:15:22.959
process to make this a little easier and a little smoother and the first thing is that we got really strict about our
00:15:28.639
styles if we get a design we often do a lot of pushback like designers really have to
00:15:33.759
think about adding new colors because we're going to fight with them if they want to do it and
00:15:39.680
all of that is just to make sure that you're adding styles because you really need them and that things are kind of
00:15:45.279
global and consistent throughout the site and that everybody's on the same page and the way that we really make that happen is that we have style guides
00:15:52.800
so we have an html style guide that is available to design and development it uses our real style sheets it exists in
00:15:59.279
our app so it's up to date with everything that's happening in our app
00:16:04.560
which is nice for everybody to see it has our colors our fonts our grids everything i mean you guys probably have
00:16:10.480
experienced the psd style guide and if you have then you know that it's like never up to date and no one has
00:16:17.360
time to keep it up to date and if something changes like it just it stays wrong so that's just bad especially for
00:16:25.120
designers because we're like oh well it's not in the style guide anyways so um but yeah i think it's a great tool to
00:16:31.680
have because it is living breathing and right and then we also have a code style
00:16:37.680
guide which is actually on our github account if you want to see it but it just goes over our agreed upon practices
00:16:43.600
for staff sas and our views and all of this is really just about making sure that everybody starts out on
00:16:49.600
the same page like they're all evolving and living breathing things but everyone starts from the same page and if you
00:16:54.720
want to change it like we have a conversation about it so that everybody is always like in the same place
00:17:00.800
the other thing that we did is that we moved to semantic markup and this actually made a huge difference
00:17:08.160
on a variety of levels the first one i just think looking at this it's a lot clearer just going into your view understanding
00:17:14.559
what's happening here you're not you don't have like the mental clutter of having all the design classes everywhere
00:17:22.240
it also makes enforcing global styles much easier because if you make a change
00:17:27.679
you don't have to go into every file that's referencing that class and change it and probably miss something
00:17:33.679
instead like you just change it in your sas and you're done so
00:17:39.440
obviously one of the main things that we use to make this happen is you have to generate your css we use sas you could
00:17:45.520
use less it doesn't really matter in addition to like the niceties of all of this i think one of the big things
00:17:51.679
about this is that you can start to look at your css as code and think about the same questions
00:17:57.360
that you ask about your ruby code like is this maintainable is this clear does this make sense can i reuse this
00:18:02.880
component somewhere all of those questions you can start asking because you can use some of the basic constructs
00:18:08.720
of an actual programming language so we use variables pretty extensively
00:18:14.799
and one thing to notice about this is that the name of the variables is about their meaning and not their value
00:18:20.559
so we started off with like font size 22 and then we needed to change it to 23.
00:18:26.080
so then you either have to go into everywhere that's referencing font size 22 which was a class and change it to 23
00:18:33.520
which again has like you're probably going to miss something and screw something up
00:18:38.640
or we change 22 to mean 23 which is bad for obvious reasons so instead we move
00:18:43.679
to a system like this which has been really great the designers totally know what all of our sizes are and we
00:18:50.160
actually changed our sizes again and were able to change them through the system and it was
00:18:55.520
almost painless yeah we actually um we initially had converted our own phones
00:19:00.640
to web fonts and that was pretty terrible with rendering so we did an upgrade on two of our fonts to be actual
00:19:07.600
web design phones and that just changed your entire baseline of your font so it was crazy i mean like every single piece
00:19:14.960
of font on our type on our site needed to be adjusted
00:19:20.000
and i think the other nice thing about this is having like a very small number of fonts that you can use for both of
00:19:25.039
your typefaces or however many you have because you shouldn't have 15 just because you have different type
00:19:31.520
that's just bad and weird and hard to remember what to use for what font and the other thing is um you don't just
00:19:38.640
have to have global variables so we use variables a lot that are scoped within classes for things like nav height so
00:19:44.880
something that is like 51 pixels first of all you're putting it near the top you're giving it meaning for someone who
00:19:50.240
comes back and looks at it but it also means if you change that everything that's offset by that that has a margin
00:19:55.679
based on that is immediately fixed so the next sort of kodish component is
00:20:02.400
that we use mixins really extensively and we prefer them in general over extends
00:20:07.679
and part of this is like this is a function which means that we can make changes to this and we can
00:20:14.960
inject this as sort of a composable object and like thinking about composition
00:20:21.440
anywhere in our css that we want so this is a separator that we use basically everywhere we use it on our modals we
00:20:26.880
use it on almost every page and this makes it really easy just to have that style consistent and we can
00:20:32.480
just include it in whatever class that we need to include it in okay so going back to our couple's site
00:20:39.919
um these are some of our dates there's like a beer and mussels date there's a gaming night a whiskey tasting this
00:20:46.080
really cute peanut butter date that comes with a heart-shaped peanut butter sandwich for you and your partner
00:20:52.720
and these have our dual pricing that savannah mentioned earlier but as you can see it's a little bit more complex
00:20:57.840
than that we have some members only dates members get one free date a month and
00:21:03.440
also if you booked it you see the price that you paid dates can be sold out they can be expired you can obviously be a
00:21:10.080
subscriber or not but also your partner could be a subscriber which means we treat you like a subscriber except when
00:21:16.000
it comes to your credit card because not everybody is you know at the place where they're sharing credit cards
00:21:21.679
but um the point is we wanted to reuse this component and there was just a lot of complexity on it we started with a view
00:21:28.559
that looks something like this there's ternary operators to determine classes there's a lot of if statements and you
00:21:34.240
just come into this and you're like what the is going on i have no idea um and so part of this is really about
00:21:39.679
getting your logic out of your views so we started with this 41 lines of code and we got it down to five
00:21:47.039
and i think just in terms of clarity like you understand what's happening i'm in the pricing control there's a pricing definition there are details there's a
00:21:53.840
status it just kind of makes sense and we obviously use helpers and decorators
00:21:58.880
pretty extensively we lean more towards decorators but you could do the same things with helpers
00:22:05.440
and one of the first things that we started doing was generating classes and this started because like members
00:22:10.880
only something was floated or like if it was sold out it was booked or whatever i mean it was gray
00:22:17.360
and um so we we wanted to just generate that and be able to test that logic and do it
00:22:24.080
in a really conscientious maintainable clear way but we also did things like there were
00:22:29.440
places where there was a free class that was only on the copy and we actually moved it up to sort of the top level
00:22:35.120
pricing div and part of what this started to feel more and more like is thinking of that
00:22:40.799
dom object as an actual object with state that those classes are about the state of that date and the permutations
00:22:48.240
and how it interacts with the user and all of those things and then you can take that same idea and speak to
00:22:53.760
designers and they understand because the state is booked and the user is not subscribed and what does it look like in that state and then we can let the css
00:23:01.360
do its thing and cascade down that dom object and more and more this gave us a lot of
00:23:07.760
flexibility to make changes without changing our markup especially for design where we want to
00:23:13.120
like emphasize certain things or change things as we like learn more about our product and what our users need so it's
00:23:20.159
a really great global way that we can understand design and we don't have to design every state all of the time
00:23:26.640
because we really don't have time for that and all of the markup is consistent across all of the states it's really
00:23:32.480
about the css which changes the visual indicators so you can also use this technique and we do
00:23:38.720
successfully for copy as well as any html attributes at least in hamel you can just pass it a hash we use that a
00:23:45.120
lot for forms for analytics tracking for things like popping a sign in modal
00:23:50.400
and all of that is great but really what you're doing is creating really encapsulated isolated components that you can test by themselves so when you
00:23:57.919
do a view test you're basically at least in our spec you're getting a string of html and you're doing a bunch
00:24:03.679
of regex on it it's not a particularly like isolated or precision way to test
00:24:08.880
the logic in your code and now we're testing it very in a very limited scope in the
00:24:14.720
correct scope with context that we know and understand sort of like the basic
00:24:20.240
why you do tdd and how to do it well um the other thing that we do is encapsulate things into partials which
00:24:27.120
is obvious we all use partials they're great um and i think it's really obvious to encapsulate things when things repeat
00:24:32.960
consistent consistently or there's like a lot of complexity around it but if you think of our price it's
00:24:38.559
actually kind of simple right like there's a title and there's the price and that's it but we have this complexity around it
00:24:45.679
like do we display it twice if it's if it's the dual pricing if it's members only or booked we only display it once
00:24:51.760
if it's free we don't display it at all so what we did is we moved that very simple definition list markup
00:24:59.120
into a partial and then we move the logic around when to render it into our decorator method
00:25:05.200
and i think this is something to think about like where is there repetition that maybe isn't quite so obvious or is
00:25:11.360
happening a variable number of times or the thing that's repeating is really simple but it actually like makes your code
00:25:17.840
harder to understand and harder to maintain and less clear and all of this is really
00:25:23.679
about sort of an unattainable goal that i've been thinking about which is can you move all your design changes
00:25:28.960
just into css can your markup be about your model and your content and displaying that and then having the
00:25:34.960
design and the visual indicators and making things pretty which is obviously really important but
00:25:40.000
can it happen just in css because that's really what css is good at right
00:25:46.559
yeah and i think that if you're constantly changing your brand or like learning from your design decisions you
00:25:52.640
do want something that's global and that can be easily changed and updated and
00:25:58.559
made better um so you may have had a reaction to this
00:26:03.600
and it may have thought it was awesome or the worst thing in the whole world and we sort of had both of those
00:26:09.200
reactions from some of our teammates and i think most of the challenges are kind of emotional there's something like
00:26:15.279
that feels really antithetical to the way that we're taught how to do our jobs about this
00:26:21.200
and the one that i think affects developers more than designers is this is stupid it's stupid to move something
00:26:26.400
from the right to the left um and it kind of is but like on the other hand how awesome is it that
00:26:32.320
you have a story that's like so stupid and trivial that you can do it right now and then you just keep doing that and you've deployed like 12 different things
00:26:39.520
in one day and also we saw how it actually totally was a huge deal and ruined the
00:26:44.960
experience and that allowed us to you know stop right then make a decision about what we were going to do about
00:26:50.960
that problem because we all know that browsers are difficult
00:26:56.640
and also it meant that you know we could just revert that very small change
00:27:02.320
so it's stupid but it's good stupid and of course design is like this is a
00:27:08.400
little bit ugly like i don't understand like i know you're really smart and i know you're good at your job and why
00:27:13.520
can't you just fix this in like five seconds for me and i think it's about understanding that you don't want to
00:27:18.960
block a deploy and even though it's ugly for like five minutes in the grand scheme of things is it worth it to like
00:27:25.679
make a fuss over this and wouldn't you rather make your product consistently better versus like
00:27:31.760
dragging your feet on a font size or a color or something weird like that and really really like major redesigns
00:27:39.279
usually end up pretty ugly like you're pretty dejected afterwards in some cases
00:27:44.559
maybe you're not but i think that the design often feels a little bit broken because you have to
00:27:50.799
make quick changes or you have to like make compromise um so in the end if you can just feel more
00:27:57.279
a part of that process and you can like understand it a little bit better then it's worth the ugliness for five minutes
00:28:04.240
right and i think that a really good thing to think about is like in our magical heads major
00:28:11.200
redesigns and these other techniques turn out perfect but like in reality they don't turn out perfect i've never
00:28:16.399
experienced them turn out perfect and so part of this process is about kind of accepting that reality and going
00:28:22.640
with it instead of working against it and really like getting everybody on the same team and so i think at like a fundamental
00:28:29.360
level what we're talking about is creating a conversation between designers and developers and making it so
00:28:34.799
it's designers and developers and not designers versus developers and creating this environment of
00:28:40.720
collaboration and the realization that you're all really working towards the same goal which is creating a really awesome product and making a really
00:28:47.760
awesome business and i think kind of the secondary part of this which is just as important if
00:28:54.000
not more important is that you're creating a conversation between you and your users if you're constantly pushing
00:28:59.440
out new changes and new features and updating design we do a lot of user testing so taking
00:29:05.520
the feedback that we get from those sessions and like improving our products then the money that our users pay every
00:29:12.640
month towards us is actually for a reason and they're not sitting there paying for something for six months that
00:29:18.000
never changes or never gets better and they're really like oh hey like these things
00:29:23.600
are improving and they're not improving like all at once on me so i like don't know how to use the site that i come to
00:29:29.200
every day but they're like a smooth transition into a better um more improved experience
00:29:35.600
and i think facebook might be the best example of why it's bad to make huge changes on your users
00:29:42.320
and since we're subscription based like we can't have our users creating facebook groups about how much they hate our site right so
00:29:48.960
it's really about giving them this extra level of value and this really visible amount of value
00:29:54.799
especially when they're paying you monthly okay so now we would like to have a conversation with you
00:30:00.720
about this process and making design changes so you can get in touch with us on the internet
00:30:06.000
or grab us afterwards or we're happy to take any questions
00:30:24.720
um we've actually done both so we've a b tested small changes um
00:30:31.120
it tends to depend where they are and the reasons for the design so we've had design and future changes that
00:30:37.360
are more like organizational like we need to do this because there's a scaling issue or because customer service is getting this huge influx of
00:30:44.080
issue all right thank you very much
00:31:27.039
you