Episode Transcript

Karen:

Hi! This is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Karen McGrane.

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week I’m really excited to have Stephen Turbek and Brian Hurley from Fidelity join us. Hi guys, how are you?

Steve:

Great.

Brian:

Great thank you, great to be here.

Ethan:

So I’m really excited to talk to you guys about what you’ve been doing over at Fidelity. But I also want to talk a little bit about our sponsor Campaign Monitor. Because if anyone needs an email newsletter you should definitely check them out. Because they’ve basically told us that they have this new email builder called Canvas. It sounds pretty exciting because it’s actually based on designing styles rather than just fixed templates. So in other words, that means designers can really focus on the content driving the design, rather than being constrained in these inflexible boxes. They’ve got this really well executed drag and drop functionality they’re really proud of. For me at least, Campaign Monitor has been publishing great resources and tips for designing email newsletters for the better part of a decade. So we’re really proud to have them involved in the show.

Karen:

Steve, Brian, why don’t you introduce yourselves and tell us a little bit about what you’re working on?

Steve:

I’m Steve Turbek working at Fidelity. I lead the User Experience Design Group, which provides design services across the various different lines of business and in this case with Fidelity.com and our native apps as well.

Brian:

I’m Brian Hurley. I’m the business owner of our Fidelity.com platform experience. I’m responsible for delivering integrated customer experience across our digital platform, in concert with many other business partners across the organization.

Steve:

I just want to note that we’re here kind of as proxies for a much, much larger team who have been working on this project. They wrote all their notes down of what they want us to convey. We’re here to communicate those over. Otherwise we’d have an enormous conference room with probably forty people in it.

Brian:

Indeed.

Karen:

Takes a lot to make a responsive design happen.

Steve:

A village, some people say.

Brian:

Indeed.

Karen:

Could you guys just tell us a little bit about what you’ve been working on?

Steve:

Absolutely, so we’re taking one of the most highly trafficked financial websites and trying to make it accessible in a whole bunch of different form factors while making the continuous improvements that we’re always making.

Karen:

So does that involve responsive design?

Steve:

Responsive design is a big part of this plan, absolutely.

Karen:

So what else does it involve? I like the word “accessible.”

Brian:

Well, it’s trying to help make a shift from the current experience that is product- and feature-oriented more towards a customer-centric or user-centric design. So we give them a more integrated experience based on the way customers want to actually come to us and use the site on a daily, weekly, basis to better manage their financial lives.

Steve:

So I’d say we were kind of changing what it does, how it does it, and who it does it for pretty much all at the same time.

Brian:

Yeah.

From a business case standpoint it was pretty easy to say we should try and come up with something that could address all of this and at least converge the dot mobi experience with the dot com experience. At the least we could get two of our platforms converging. So in a lot of ways it was pretty easy to make a business case standpoint to get support that we needed.

Karen:

Wow! So talk to me a little bit about how you sold this into the organization? Like your executives, your stakeholders, how did you convince them that this needed to happen and that responsive design was the way to go?

Brian:

Well, at the time we were at a point considering redesigning our dot mobi experience, redesigning our dot com experience, and continuing our iteration on our mobile apps, mobile native apps, and we knew that device form factors are continuing to expand. How many native apps did we want to have to continue to build up in our arsenal to keep up with that device proliferation? And at the same time, the fact is, most of our mobile users are multi-platform users. We don’t have a lot of native app only users right now. There may be more in the future, but we had all this, that from a business case standpoint it was pretty easy to say we should try and come up with something that could address all of this and at least converge the dot mobi experience with the dot com experience. At the least we could get two of our platforms converging while addressing that kind of device proliferation at the same time. So in a lot of ways it was pretty easy to make a business case standpoint to get support that we needed.

Steve:

I would add that Fidelity is a pretty forward looking technology company so this is something that everyone’s aware of in itself was not a particularly hard sell.

Karen, to your point about accessibility, we’d love to come back to that. Or I’ll just talk about it right now. So Fidelity actually has a long commitment to accessibility to make its services available to people who use screen readers, and this kind of commitment adds an additional level of complexity to it, but one that we’ve embraced. We can talk more about that, but it is something that’s very important to us.

The biggest problem I think a lot of people struggle with, with accessibility is when they try to slap it on at the end. But we have people that is their job to make sure that our design process points the products in the direction of being accessible, so we don’t make mistakes early on.

Ethan:

I would love to hear a little bit more about that. How do accessibility and responsive design overlap in your universe?

Steve:

I guess it’s more of a how, rather than a what or a when. I would say that if you’re going to do it, you’re going to be doing it the entire length of the project. The biggest problem I think a lot of people struggle with, with accessibility is when they try to slap it on at the end. But we have people that is their job to make sure that our design process points the products in the direction of being accessible, so we don’t make mistakes early on, and this allows it to be a lot easier when you’re adding additional features. You can follow the standards and the way we do things so that accessibility is kind of built in.

Ethan:

That’s great. So I’d be a little interested to hear about, you mentioned timelines a little bit there, but in terms of thinking about the scope of responsive Fidelity.com redesign how did you guys even begin to scope something like that? How did it measure up against more traditional platform-specific experiences?

Brian:

That’s kind of an interesting question because candidly much of it was unknown and how long, how hard, making some of our core capabilities responsive? We didn’t know. But that didn’t dissuade us. We had some base assumptions and a budget allocation but we went at it in an iterative process so we kind of combined with a, what’s our minimal viable product that we need to have to show up in the marketplace? To have an experience that we could stand being that we think would add more value to the customers that they would embrace? Because you know, we’re going to introduce a big change to that customer base. And so we were pretty clear about what that minimum was. We were shooting for a lot more, and we just continued to iterate on it and it’s just been a progressive release we’ve been working through introducing capabilities into a beta environment to validate what we’re deploying was what customers were expecting or wanting and incorporating feedback into future iterations. So one of the key premises that we had was that we weren’t going to be beholden to a specific date to go live. So because we didn’t know enough about what it was going to take to do that. We were committed to delivering the right experience. So that’s what we’ve been marching towards is delivering that right experience. Interestingly enough duration-wise we’re probably three months longer than we might have expected. Cost-wise probably maybe ten percent, twenty percent higher than we thought we would be but not as far as off as many might have thought we could have been when we got started on this.

We decided to essentially start from scratch so we didn’t try to adapt the site live.

Steve:

And Brian touched on one note there that is essential. We had a number of lucky breaks and some good calls and I’d say one of them was when we were designing the project, not the design of it, but how we were going to approach it, we took a couple of key decisions and I’m really glad we did. First one is that we decided to essentially start from scratch so we didn’t try to adapt the site live. And just as a note for the people keeping score at home, it’s a pretty big site with a lot of users. 2.5 million daily users or something significant like that. But these are also our customers, so they have a very intimate relationship with the products that we offer, and there’s also a very prominent 1-800 phone number that if they don’t like something they can call it. And that’s different than a lot of your, maybe little start-up companies who don’t offer phone support, it’s free, and so customers don’t tend to complain. This is a different kind of relationship and one we take very seriously.

One of the first steps therefore was to keep the existing site as-is and then build essentially a beta site, that people could opt-in to, try out for awhile, opt back out into the old site. That was significant additional work to make that function work, however it is something that prevented this project from failing a number of times. Because we can always, as Brian said, have the confidence to say “Hey, we’ve got this new feature, it’s going to take us a couple of releases to launch it and at the first release it may not be better than the existing one.” If you were doing it live on the site that would be a really, really bad situation, but this enabled us to do multiple iterations, get lots and lots of user feedback—pretty much continuously at this point—where we’re testing out the new features with different audiences so that we can actually learn before it goes fully live.

Brian:

And I would just add that in particular, responsive design of some of our core experience is pretty challenging to do. We’ve had to make some big calls of literally going back to square one and core parts of the design because we didn’t like it enough, customers didn’t like it enough. This iterative approach and this beta model has allowed us to do that. I think going into such a significant change both in terms of the experience as well as the way the whole introduce the responsive at the same time, we were very fortunate that we did go down this route of having a beta environment.

Steve:

We took some inspiration from Gmail and Yahoo mail when they did their relaunches. We studied how they did their rollouts and we modeled it on those. It allowed people to get familiar with it and give feedback, which is very important to us and we absolutely read all of this feedback that we got and used that to kind of affect our design cycle and also give them a chance to get familiar with it. So again when people come to someone’s website it’s not about you the product owner, it’s about them and they’re trying to get something done. It’s great that you’re changing the design but if it causes them to get lost they’re just not going to be happy about that.

Like any large site there’s a very small fraction of the pages that get the most traffic, and it’s very, very true with us as well that there is kind of a core set of, essentially ten pages—they’re not really pages but ten views—and they get just a phenomenal amount of traffic. What we realized is we had to win on those and make those great in all of the different platforms.

Karen:

I remember talking with you guys or working with you guys a couple of years ago as you were implementing CMS re-platforming to SDL Tridion and you just rolled out an entirely new component-based design system. Did that… so when you talk about starting from scratch, did you rethink all of that as well or did the content management system and the design system provide a foundation that allowed you to implement this responsive design?

Steve:

Actually, so that is on the roadmap, but that isn’t actually where we started. So one of our processes again is to really focus on the user and what they’re interested in. Of course like any large site there’s a very small fraction of the pages that get the most traffic, and it’s very, very true with us as well that there is kind of a core set of, essentially ten pages—they’re not really pages but ten views—and they get just a phenomenal amount of traffic. What we realized is we had to win on those and make those great in all of the different platforms, before we got to, for example, the online reference and other additional functionality that’s also important to complete the picture. But we really needed to make sure that those high volume pages won first.

Brian:

But what’s interesting is, we are also now attacking… the fact that we had moved to a new CMS, our content was already edited, simplified, consolidated into a more consistent editorial voice, more consistent construct, and we’re going through now and applying responsive design to those templates and components in parallel to the core applications that we’re also redesigning responsively for the ongoing experience. So it’s actually, we kind of did a two-stage process for the content in the content management system. Had we known this a little bit ahead of time we might have done it at the same time. It’s actually been a pretty easy shift because we did all the heavy lifting of streamlining, simplifying and getting more consistency across those templates and components about a year and a half ago.

Steve:

It’s almost like we read a book about designing content for mobile.

Ethan:

That’s fantastic. That book is actually a bit of a page turner, so, yeah.

Karen:

WYSIWYG dies at the end.

Ethan:

God Karen, spoilers, geez. So as you guys were talking about delivering the right experience in, I guess kind of a multi-platform property, responsive property, so do discussions about different needs and different contexts ever come up, in terms of mobile versus desktop? Are those seen as separate audiences that have distinct requirements or…? I’d be interested to hear a little bit about how you talk about those terms internally.

Steve:

Well, I guess just one thing, and I’d love to hear Brian’s take on this, but we prefer not to opine on this. So we have, as if you look at your metrics, you have a lot of data. So as Brian mentioned we went and looked and saw who’s coming to us on which platforms, by the customer who is logging in on a native app and also… We found that it’s not incredibly bifurcated. What we see is a lot of people using multiple devices doing perhaps slightly different things. I think that what’s interesting when you look at this from a platform is that there’s going to be a long tail of any usage. What we did not see is that there was a consistent long tail of only feature A, B, or C across all of them. So there wasn’t an easy answer there.

We’re kind of moving from that stage of mobile as a startup new channel and getting a lot more aligned with it as, it’s part of the ecosystem that our customers use. And we shouldn’t make them choose whether it’s native app or a browser-based. And so we’re kind of trying to think about it as this continuum of the experience regardless of what platform they choose to use.

Brian:

But at the same time, while we’re taking on a responsive design for our browser experience, we still see this as very complimentary to our native apps and we work very closely with my counterpart who is in charge of the native apps to think about the cross-platform experience and make sure that where it’s most important we have the appropriate level of consistency to reduce the amount of relearning and reorientation on the customer base. We’re kind of moving from that stage of mobile as a startup new channel and getting a lot more aligned with it as, it’s part of the ecosystem that our customers use. And we shouldn’t make them choose whether it’s native app or a browser-based. And so we’re kind of trying to think about it as this continuum of the experience regardless of what platform they choose to use.

Steve:

And I would note that we launched a number of things responsively, both in this project and also in other parts of the site. And one of the things we’ve been very pleasantly surprised by is people’s willingness to engage in some very fundamentally complex financial transactions on all these form factors. So we’ve launched a number of things that have got transferring assets between accounts, not something you, typically, would think that somebody would do on the bus, and yet we’re seeing very high usage, much higher than expected on phones, for example. So I kind of feel like the customers are way ahead of us on this one. I think in probably a year or two this is gonna seem silly, like you just have to do it in all the cases.

And one of the things we’ve been very pleasantly surprised by is people’s willingness to engage in some very fundamentally complex financial transactions on all these form factors.

Karen:

How did you make decisions about what to prioritize on which screens, or what to keep and what to get rid of? I think one of the most common things that we hear is this idea of, “Well that’s not possible to do on a phone.” And, of course, it is possible to do on a phone and people want to do it on a phone. But it involves making different choices about how you lay things out and prioritize them. How did you go through that process?

Brian:

Well part is, we have a really good base to start with because we have an existing site, right? And there is a fair amount of interest from our business partners. While we kind of are overseeing that digital experience, we have a lot of partners across the company that are highly interested in what gets put where and how. And so we have a good base to start with, but we also recognize we, a lot, have different types of users. I don’t think there was any magic here. It was pretty much user volume, user intent, and business value that kind of helped us prioritize what it is we wanted to put and prioritize the experience.

Again, we are doing it in a responsive browser and for us Fidelity.com is the encyclopedia of capabilities, digital capabilities, for Fidelity. And we weren’t going to start trying to kind of shed pieces of that at this point. We wanted to make sure we provided the appropriate access to all those capabilities. But, which ones were highlighted and brought up to the fore of the experience were definitely based on lots and lots of customer research, ethnographic research, on-going user research, and then kind of layering in that business value of many of the hidden gems, as Steve likes to call them, that we currently have in our experience that are just really hard to find but can be really valuable to the user.

Steve:

I would note that it’s our overall design strategy has been to find these elements that people like a lot once they know that they’re there. But if they don’t appear on those top ten pages they might as well not exist at all. So that’s what we were saying before about redesigning the site itself. Yes, we’re making it responsive but we’re also changing what it does. And the core conceptual change is, as opposed to having to link down to deeper parts of the site to find all of these great features, is we’re bringing small previews of them up to the pages when the person logs in.

The good news is we have a terrific measurement system today to understand what customers are most interested in using. And then we complement that through the on-going user research of the designs we have. So we felt pretty confident in the decisions we’re making as what collapses, what gets hidden, what needs to be accessed during some cases.

Brian:

And I think there is some consideration to what happens as you adjust to form factors, you know, what’s most important, most relevant. And the good news is we have a terrific measurement system today to understand what customers are most interested in using. And then we complement that through the on-going user research of the designs we have. So we felt pretty confident in the decisions we’re making as what collapses, what gets hidden, what needs to be accessed during some cases. Some capabilities do disappear completely. Like downloading all of your financial information to your smartphone is probably not a capability we need to have on that form factor. But other than that we wanted to make sure we thought through the accessibility to capabilities throughout the entire experience.

Steve:

Yeah. There’s one story that we came across, paying the dog-walker. And it was a situation where you might think, “Oh I just, you know, if I’m going to pay a bill I’ll just have, on a mobile device, I’ll just have the pay-the-bill feature.” But, who’s gonna add a payee on their phone? But it turns out that if you are going to have some… if you just changed dog-walkers and you went on a trip. All of a sudden you’re highly motivated to find a way to pay that dog-walker right away. Even if it’s an airport wifi and you’re pinching and zooming. We found that people went and did those things. So again, we really start with more of a question of, let’s treat them equally and find out where the gaps are, rather than just assuming that people won’t do stuff and then convince the other direction.

Brian:

I think the one piece that I would add, though, that was a change for us, addressing some of the design conventions that our users are well, wed to, they’re ingrained in their everyday behavior. And a lot of our partners are very concerned that we would be diverting to a new set of interaction conventions that our customers are going to have to get used to. They really wanted us to hold on to the vestiges of some of the existing design to make sure that customers could find their way. But they didn’t really fit. Many of these conventions didn’t really fit in a new touch-friendly responsive design environment. So that was probably one of the harder, some of the harder decisions we’ve had to deal with in terms of what stays and what goes away.

Steve:

Absolutely. So you know, little things. We deal with some fairly complex stuff. Using a mouse to roll over an item to get the detail, that works very well on a desktop, and you just have to come up with a new way. Luckily, that’s why we have a design team, so.

Brian:

Right.

We’ve run into many cases, particularly with responsive, that you need to be developing stuff at the same time that you’re designing it. Number one, just to make sure that it renders well. That’s always been a best practice. But what we’ve found is that when you have to support as wide an audience as we do, you have to take all of the constraints into account very early.

Ethan:

So, in thinking about your design team a little bit, I’d be interested to hear about their process. Has that changed as they’ve started doing more responsive work? Are they still thinking primarily in Photoshop and moving on from there? How, if at all, has that evolved?

Steve:

Yep. So it’s completely different. The main thing is that we’ve changed the design team to be pretty much having someone who is going to do user research, on every team we have someone that does that. And someone who is working out some of the business flows, you know, a traditional information architect kind of role. A visual design lead. But a core part of the team, actually continuing to grow, part of the team is a front-end developer, what we call a user experience developer. And this would be someone who can then go building more than just prototypes, but building actual code that’s going to go to production, and be that bridge between design and development. Because we’ve run into many cases, particularly with responsive, that you need to be developing stuff at the same time that you’re designing it. Number one, just to make sure that it renders well. That’s always been a best practice. But what we’ve found is that when you have to support as wide an audience as we do, you have to take all of the constraints into account very early.

Now, Brian mentioned earlier about a large piece of work we did that was very important to us that we wanted to get right. And we had spent all this time designing it and developing it and it worked great. Everyone was happy, you know, yay big win! And then as we went on to the performance testing we found that at the midrange Android devices, they just couldn’t handle the rendering. Scrolling was terrible, which just really didn’t meet our quality standards. We had to dial that all the way back and actually come up with a different set of compromises between what we want to do and what the devices can do. And so the closer, the faster that loop happens, the faster the projects go.

Brian:

And from a business standpoint, it’s been invaluable to have that capability. Working with my team, partnering with Steve’s team, to see this happening in near-real time, understanding what’s happening when you do adjust form factors on the fly, and it’s helping us in terms of speed and in terms of quality and terms of overall cost to the project. And just having a lot more confidence in the end products while it’s being made rather than waiting for the magic machine to spit it out the back-end.

Steve:

Mm-hm. I would say just as a note, Brian and I are here as figureheads. Karen, as you know, we did try to actually get the entire team in here but there’s a practical limit to podcasts, so. But we really are the figureheads here because this team—and I include dev, I include QA, business partners, actually we have a fantastic legal team who can really get around some of these nuances. Perhaps we should come back to that. That might be interesting for your audience. But it takes a lot of trust because you are making stuff up as you go and there are all of these situations that will rear their head later in the process. And you can’t just sit there and blame the other person because it is all one team. So what I think is interesting is the change of perspective that we’ve seen.

That there’s a designer. And as you’ve said, “Oh, do they work in Photoshop?” That was the traditional definition of a designer, is the person who used Photoshop, just like a mechanic was a person who fixed cars. But now it’s actually that our designers are the person who’s responsible for the design. And that may be using, well, Fireworks in our case, but it may in fact be just sitting next to our developer and getting in there and getting into code. But it’s that overlapping and blending of skills that I think is essential to making these projects work.

Karen:

Can you talk a little bit about the content process? So, did you make changes to the content, text or explanatory information or giant tables, how that content was presented? And how did that process work with the design prototyping?

Brian:

Most of our work within these top ten views or pages that we’re really addressing were, it didn’t need that much addressing in terms of finessing the language. I think there’s some new components that we’re introducing, that we’re trying to fundamentally change the tone and tenor of how we talk to our customers. Moving from what I call the objective third person voice to something that’s a little bit more engaging, a little bit more conversational, maybe not truly two-way conversational but getting a little bit closer to that. A lot of the information we share is very well-governed by rules and regulations and legal context. So we’re pretty clear about what we can and can’t say in terms of column headers and the like. But, it was approached as a design system within the space that we were working on to make sure that all the types of labels and the language and icons and informational pieces hung together. It may not fully hang together with the rest of the site right now but we’re addressing that over time as well.

Steve:

I would just add again that user research is critical. So, we think of user research as kind of like the heartbeat of a project. We establish a testing schedule every two weeks. And you know something or another session is coming up and either it’s an online high-volume study, five hundred people or whatever it is,or we’ll get people in for qualitative studies into the lab. But it’s going to happen every two weeks, so you’re always thinking in the back of your head, “Oh what questions do we have? Let’s queue it up for that test.” And after you keep doing that you will answer a lot of these questions.

Brian:

I think that we have an advantage, we have great central content strategy team here. So we already have kind of a central voice that is part of every project that we do. We’ve probably been leading a transformation a little bit, in that editorial voice and tone in our current program that we’re working on. But having that central content team has been invaluable in making sure that we can have this all hold together.

Ethan:

Steve, you mentioned your legal team earlier. I’d be interested, you know, as you guys are on this regular release schedule and as you’re sort of doing reviews internally, how does that process work in a responsive context?

Steve:

Well, I think we kind of lucked out. We’ve got a great legal team here. And whose name I’m not going mention, otherwise someone will try to hire him away. No, because actually just to be clear, we are a financial services company and we’re highly regulated in ways that may surprise some people. So there are a lot of rules. For example, if you show a chart, the footnotes to that chart cannot be more than X inches away. Well, that is strange. And also if the page is being re-laid out, based on the size of the device, what’s the rule there? And so we actually had to address this as a design problem in and of itself. And we’re lucky enough that our partner has been actually working with the regulatory agency to propose changes in order to make the responsive experience a good one, frankly. And also, one that, well, actually is understandable by our customers.

Brian:

We’re literally helping the regulatory body rewrite their rules around disclosure, how disclosures are able to be rendered in context versus in footnotes and how much needs to be shown. Because they—this one regulatory body in particular—have recognized that there’s enough movement in the industry that they need to change their standards and, again, as Steve alluded to, our legal team has been incredible in stepping up and helping lead that charge. The only unfortunate part is probably helping our competitors as well at the same time.

Steve:

To some of your other points. In some ways I would say the project we’re dealing with, our customers view it as much as an application as they do a content site and nutritional reading section. A good challenge for us is actually in dealing more with the way we’re redesigning the site rather than responsive specifically, is we are really trying to bridge that gap a lot more. There are some sites—they have a public site and it’s all in a content management system, and a logged-in site and it’s all a completely separate code base. We’re really trying to address that, such that when you’re doing a transaction if there’s interesting articles about it or something, that we can actually weave that into the overall experience.

What you need to do, I think this is the essential thing, is you really need to honestly look at this feedback, learn from it, continue to take in the feedback and not get defensive about it. But then really just keep on going, keep on iterating.

Karen:

So, how do you measure the success of this responsive redesign? How do you evaluate whether it worked or not? How do you compare it to the old desktop site, or the app, or any other products that you might own?

Steve:

That’s an interesting question. I’d say first, develop a thick skin. We’re very, very focused on user research. When we do something, we have it all wired up with metrics, and we see what people are doing in aggregate, not specific people. Then we also ask for feedback. And we get lots of feedback. Remember, we started with the beta site, which was worse—or I say not as good as—worse than the existing site. For people who really just want to go and do stuff, they’re not coming here to pat you on the back and say great job. So you’re going to get a lot more negative feedback. And we use all the tools, getting people’s ratings, looking at things like NPS [net promoter score], and a number of other things. And again, you have to remember what you’re comparing it to. Of course, in comparison to other relevant competitors, and your existing sites. And then what you need to do, I think this is the essential thing, is you really need to honestly look at this feedback, learn from it, continue to take in the feedback and not get defensive about it. But then really just keep on going, keep on iterating. Because we started in a place where it was responsive, but it certainly didn’t have all the functionality that people wanted. We heard lots and lots of feedback of “You guys should go and build that.” And of course we knew that was coming up next. You have to understand that they don’t know that. I think it’s really important to keep in mind just how different our customers are than we are. In some ways, it’s really kind of wonderful and as long as you have the self-confidence to continually engage with them, they will lead you to the right place.

Brian:

The magnitude of change we’re introducing goes well beyond responsive design. I forget where it was I read it, I think it was in McKinsey, a little snippet that came out not too long ago. This is something I’ve shared with business partners across the company. In this type of change you’re trying to drive through you need to have facts, faith, and fortitude. Facts, we’re consistently listening to customers before we build something, as we put it out there into beta, learn from it, reiterate. Ultimately though, we do have to have faith in our design strategy because we’re trying to move the company forward here. A lot of the shift is moving from a product-feature-centric environment to an experience-centric environment. We have to have faith that the design and approach that we’re taking will work, because it’s unlikely you’re going to get 10 out of 10 ratings from all of your users who have gotten so ingrained in their experience over the past fifteen years. That’s where the fortitude comes in, that we have to be willing to stick with it.

One thing that we haven’t really touched on here, is that we also have a very supportive executive management team that is willing to see the opportunity that we’re trying to take advantage of here and is willing to stand behind us as we’re going through this change because that is also where the fortitude comes from. And on top of that, in terms of having to measure, we do have business metrics we have to achieve as well. We are a for-profit organization so we’re keenly attuned to things like trading and volumes, and new accounts opened, and ease of doing business, and the core capabilities, the core reasons that customers come to our site and our experience day in and day out.

Steve:

Yeah. Yeah, sometimes I’ll read some articles about a startup or some company that is doing a little project and it just sounds great. If all your money is coming from venture capital, and you just have to go and gain customers, that sounds really fantastic, I’d have to say.

Ethan:

Well, that sounds fantastic and I know, personally, I can’t wait to see how this all turns out. For now, Steve and Brian, thank you so much for taking a few minutes to chat with us today. This has been really, really great.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast.

Ethan:

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We’re also planning to offer these workshops to the public, so please go to responsivewebdesign.com and let us know that you’re interested.

Karen:

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Ethan:

Thanks again to our sponsor, Campaign Monitor, and we’ll be back next week.