Episode Transcript

Karen:

Hi, this is a responsive web design podcast, where we interview the people who make responsive design happen. I’m your host, Karen McGrane.

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week, I am just so excited. We have Einar Gústafsson and Tinna Gunnarsdóttir from Meniga. Welcome everybody. Thank you for being here.

Einar:

Thank you.

Tinna:

Thank you. It’s nice to be here.

Karen:

I’d love it if you could both introduce yourselves, tell us a little bit about what you do. Einar, maybe you could get us started.

Einar:

Sure. I’m the vice president of product management. Basically, what the company does is we provide a white label personal finance management solution that we sell to banks directly. I guess you could say that we’re a bit like Mint.com, which you might know. We’re focused selling directly to banks mostly in Europe. Currently our solution has been implemented by approximately twenty banks in sixteen different countries. We serve countries from Denmark, Sweden, and Norway to Spain, Germany, South Africa, Australia, etc. Even Dubai. So, currently something like twenty-five million people are actually able to access and use our solution, although it’s usually branded as a personal finance management section of a bank, or it’s the engine that is powering the bank behind the scenes.

Tinna:

I work as a software engineer at Meniga. My current role is the technical architect with regards to front end development. I work in one of the core teams that we have here in Meniga, and we sort of set the guidelines for how the front end is developed, such as what technologies and what guiding standards that we follow.

Many of our customers prefer having a fully responsive solution, so this is something that we essentially had to also provide.

Karen:

What were the conversations like around your decision to go responsive? Was it ever a question that that would be the right way to implement this fairly complex web transactional application?

Einar:

Actually, it was. Initially we decided to focus on just building a mobile application and the focus was merely on having the desktop solution as something that would work all the way down to tablet size. We had been building the web-based mobile version for quite some time, and even though it was fine, we always felt a problem with HTML working properly as an app, especially for something that is highly visual, a solution we felt that should be very responsive in a way.

So, we actually just made the decision to build a native app and essentially scrap the mobile-only version, and rather focus on building a fully responsive solution. We had made some adaptations prior, because essentially a part of our services is we work for our clients and we implement for them the front end adaptations that they would like to do. Many of our customers prefer having a fully responsive solution, so this is something that we essentially had to also provide. Of course, we just wanted to make sure that it would be something that would at least provide an experience that would be close enough to being a fully native solution.

The native app is a smaller solution, but it does provide a slightly different functionality.

Ethan:

As you moved away from thinking about designing a separate mobile application and into adopting something more device-agnostic, how did Meniga think about the needs of the mobile user and the needs of the desktop user? Were these two audiences that, more or less, had separate goals and separate tasks? Or did everyone, more or less, just need to access the same information?

Einar:

I guess you could say that by building a pure native solution, we have a slightly different focus. The native app is a smaller solution, but it does provide a slightly different functionality. It’s more a question of people being able to get a very fast glimpse of their finances, understanding how much money they have, how much money they can still spend, and where their money has been going over the past few days.

While the desktop version is essentially the responsive one, because they do provide the same functionality, the focus there is slightly different. It’s not only asking those same questions but as well being able to plan ahead. So, for example, setting up a budget for the next months.

Rather than trying to adapt the desktop version down to the mobile, we really started by thinking, “What will it look like on the mobile device?”

Karen:

Given that you already had some experience with doing native app developments for this platform, when you were thinking about scoping the new responsive project, how did you approach that? Did you have to plan for more time or more budget than you did with your native development, or did you have to prioritize the functionality that you were going to deliver differently?

Einar:

We were actually in the process of rebuilding the front end completely. The solution had been growing quite fast over the past few years. Essentially, we started as a startup in 2009, we got our first customer in 2010. So when me and Tinna joined, we were approximately employees number four and five, and right now we have 100 people and with all of these different customers all over the world. So, the solution has been growing quite rapidly. We felt the need to really rethink how the whole front end was structured. Tinna and I essentially started working on redefining how the front end architecture should be. In the process of that, we decided that since we were doing that, we should really do the responsive redesign at the same time.

But we did start from the other end. Rather than trying to adapt the desktop version down to the mobile, we really started by thinking, “What will it look like on the mobile device?” and then seeing what the possibilities were. In essence, you could say that even though we had a desktop/tablet platform, we really started with a mobile-first approach.

We started with how it would look on the mobile and we added to it slowly so that it would respond fluidly and logically to bigger devices. That approach is what changed the most for us.

Ethan:

Tinna, I’d love to hear about your development process in thinking about building this responsive interface for Meniga. How has that changed as you’ve worked not just on this platform, but if you’ve worked on other cross-device responsive projects, how have you started thinking about building responsive interfaces?

Tinna:

The biggest change for us is that our clients in the beginning were only thinking about the desktop. So, our approach was always desktop-first and then we were trying to see how it would fit into the mobile. And now when we did all of the restructuring, like Einar said, we took everything apart and put everything back together using small components, and we started with how it would look on the mobile and we added to it slowly so that it would respond fluidly and logically to bigger devices. That approach is what changed the most for us.

And also just trying to get the design team and the product team on the same page—that what was the biggest issue for us in the beginning because the designs that we had for every new component were always desktop-first, and if there was a tight deadline to get this product or component released, then trying to get the mobile design was always a big issue. But now the thinking has changed, so we’re able to get a better product in the first releases, I would say.

We usually start this with pen and paper—but then the designs evolve mostly through tools like Sketch to do a quick mockup, we might even use Balsamiq. But we usually use InVision to tie things together and to collect feedback.

Ethan:

Could you tell me a little bit more about that collaboration with the design team? What application and tools do you find that they’re using internally, or has that more or less remained the same? Are they still creating mockups, or are they doing more design work in the browser? I’d love to hear more about the day to day.

Tinna:

I think Einar should know more about the tools because we work in different locations, so I’m not sitting next to the designers. But they use the standard Photoshop and Illustrator to get the designs out, but I know that they’re also using a product that maybe Einar knows the name of, which allows them to do mockups that are interactive and almost look exactly like the end product.

Einar:

We basically use a collection of tools, but we enjoy trying out new things as well. The base arsenal that we have—of course, we usually start this with pen and paper—but then the designs evolve mostly through tools like Sketch to do a quick mockup, we might even use Balsamiq. But we usually use InVision to tie things together and to collect feedback. Then the designers would add the high-definition designs usually by building them in either Photoshop or Illustrator.

We haven’t done much prototyping by using HTML directly. In some cases, we do what’s called a design sprint. We basically spend five days with the whole team to define a certain topic or a certain feature that we would like to implement, and at the end of the sprint we build a prototype, which we do sometimes build in HTML if it fits.

We decided to create the framework for our front end development—the CSS and the HTML markup—and we call it “LEGOlize.”

Karen:

Tinna, you said something that always gets my ears to perk up, which is that as you were thinking mobile-first, you started by defining components. Can you talk a little bit more about that process? How did you break things down into smaller modularized bits, and how is that different from the way you might have worked in the past?

Tinna:

When we started this project during the summer of reconstructing the front end, we decided to create the framework for our front end development—the CSS and the HTML markup—and we call it “LEGOlize.” It’s based on a concept about the small LEGOs component that you create. So, a button is a small component, an input element is a component.

We created this library of tiny markup and tiny CSS where everyone can just pick and choose what they need to build a page. These are the components that we used to say, “Okay, we need these basic components on this page for mobile to get it to work.” Then when we went to the tablet, we might add some more components, just drag them in there or hide and show depending on the functionality that we needed.

That’s how we started to build the page: slowly, by dragging more components to it. But we also have JavaScript components that are using this markup and CSS but that also still have small JavaScript for functionality. We also would add to those components as we needed more functionality for the tablet or desktop version.

They might want to change things quite a bit, which is why the modular design at the front end is very important.

Ethan:

How do you actually review the work in progress with your clients? How do you demonstrate the idea of a responsive interface to them?

Einar:

We have two sets of clients. In Iceland, where the company was founded and where most of our R&D is, we also have what we’ve defined as our test market. So, basically we do have our own personal finance management solution that is a straight-to-consumer solution. In essence, we do product owners here in Iceland as well that are using the solution and we are defining the functionality with them.

We of course have to test on all of these different devices—at least up to a certain point—to make sure that we have a base minimum of requirements that can be met.

But then we also have the banking client. A bank in Germany might have purchased our solution, but they’re also paying us to adapt the interface according to their branding, and they might want to change things quite a bit, which is why the modular design at the front end is very important. In cases like these, we usually set up a test server where the client can access it directly to see how things are progressing. Of course, we might also do a proper type of screen sharing to show them what we’ve been working on and if it’s something that they are happy with, or if there are any further adjustments that they would like us to make.

It’s difficult because some markets can be very different. In some cases, the iPhone is very commonly used and in other cases Android is the major device. So, we of course have to test on all of these different devices—at least up to a certain point—to make sure that we have a base minimum of requirements that can be met.

Karen:

Did you have to do any legal and compliance review for the application? In the U.S., the banking industry is what we like to call a highly regulated industry, and so all banking applications have very strict rules about how things like legal or financial disclosures have to be presented. I certainly don’t know the regulations everywhere, but if I know anything about Western Europe, it’s probably not less regulated than the U.S. So, how do you manage that? Do you have to go through reviews with the lawyers for all of the different countries that you operate in?

Einar:

Yes. Of course, each bank that we go through in each country, they all have a different set of rules and security measures that they have to comply to. This is actually quite different from country to country. For example, Germany and Denmark are quite strict, while other countries like Spain can be slightly more open. But as the solution that we sell is actually installed within the bank itself, it becomes a part of the online bank. As soon as the bank itself is meeting all of the legal requirements, our solution really falls into that as well. Although, they might need to have consent from the customer to be able to, for example, categorize your spending at Pizza Hut as fast food.

The solution has to be very accessible, because in some countries banks could get fined if they do not comply to these regulations.

Karen:

Was there anything different about that now that the product is responsive?

Einar:

Not really, no. The legal aspect really has more impact on the data itself. Although as a bank, we do need to meet special standards. For example, the solution has to be very accessible, so we need to make sure that we comply to the WCAG standards and have Level AA conformance as well, because in some countries banks could get fined if they do not comply to these regulations. These were all things that we had to take into mind as well when we built the solution, that we are fully compliant while doing a solution that should be highly scalable to fit different needs.

Now we’ve set up a rule, a list of physical devices that they have to test, so the process is a lot longer. But at the same time we catch a lot more bugs.

Ethan:

While we’re talking about compliance, I’d love to hear a little bit about the QA process. Tinna, maybe you could speak a little bit to this. As you’re designing this more cross-device interface, how has that changed the way you actually review it and test it on different devices and browsers?

Tinna:

The QA department, before when they were just testing the application, before it became responsive, they mostly used emulators from the desktop browser or BrowserStack to test the device or application. But now we’ve set up a rule, a list of physical devices that they have to test, so the process is a lot longer. But at the same time we catch a lot more bugs and we’re able to support more devices after that.

We’ve had to outsource some of the QA processes, especially the ones that are focusing on mobile, to software companies.

Einar:

But it also has caused us to actually start outsourcing some of our QA. The engineering team is split into different teams, and each team of approximately eight people should be self-sufficient, so it does have a product guy, a designer, a QA person, and then three to four engineers. But we’ve had to outsource some of the QA processes, especially the ones that are focusing on mobile, to software companies. I think we’re using one right now that’s located in India. But we still try to automate some of the testing as well using tools from Sauce Labs to do some cross-browser or cross-device testing as well.

Before starting out, we designed a baseline, trying to minimize all requests and make sure that loading on different types of devices, no matter the size of the device, should be as high as possible.

Ethan:

I’d love to hear, as part of that process, if performance is a design consideration for Meniga. Is that something that’s reviewed during the QA process or even during the design process, how quickly this interface actually performs on different network conditions?

Einar:

To us, this is something that is extremely important. Before starting out, we designed a baseline, trying to minimize all requests and make sure that loading on different types of devices, no matter the size of the device, should be as high as possible. This is technically not something that QA is looking for but it’s more something that Tinna is responsible for in making sure that the quality is kept quite high.

Tinna:

When we started this restructuring, we took out a lot of numbers from the previous design, the previous application to see how many requests we were making, how big the CSS was, how big the HTML was, the JavaScript and everything, and we set ourselves some goals to at least go fifty percent below that because we knew we were able to do it. But we did have some issues particularly with Samsung browsers, that they just responded very badly to the JavaScript. So, we have a patch right now to solve that. But Samsung browsers 4.2 and 4.2.2 browsers were responding very badly while older browsers and new browsers were responding very well. So, we also think this might be something related to the device itself. But yes, this is something that we do check very thoroughly, and we try and not do any releases unless we’re very satisfied with the performance.

Tablet visits, on top of the web, have increased by forty to fifty percent. But we see that usage on mobile devices has increased five-fold. Keep in mind, this is not including the native apps.

Karen:

More broadly, how do you measure the success of this responsive redesign or of the platform itself? What metrics do you have in place to know if it’s working, and has anything changed now that it’s responsive?

Einar:

It’s actually changed quite a bit. The numbers are actually quite interesting. The responsive solution went live in November 2014—we’ve been running our platform since 2010. From the go-live date in November, along with the native app as well, we can see that the desktop visits are roughly the same. They may have increased by ten percent. We can see that tablet visits, on top of the web, have increased by forty to fifty percent. But we see that usage on mobile devices has increased five-fold. Keep in mind, this is not including the native apps, because we can see that the native apps themselves are being used extensively as well. The number of active users that come in regularly almost on a daily basis has grown four hundred percent. To me, this is an indicator that this project was a major success.

It should not be thinking from a desktop-down perspective. You should be thinking about this from a mobile-first perspective, or a tablet-first perspective.

Ethan:

Well, that’s wonderful. I’d love to hear from both of you guys: do you have any advice for other organizations or services that might be undertaking a responsive redesign today, what have you learned as part of this process that you’d like to share with them?

Einar:

I would say that they should focus on the device itself. There are many sites that are just trying to make sure that it still works if you shrink the browser size, but it should not be thinking from a desktop-down perspective. You should be thinking about this from a mobile-first perspective, or a tablet-first perspective. You should be thinking about the user experience for each particular device, not just making the website work in different sizes as a whole.

I believe it’s a trap that many people fall into, just making sure that the website just works in different desktop screen sizes.

As an example, Tinna was actually visiting a client in South Africa, and there was a bank in South Africa, I believe it’s called Capitec Bank. If you resize the browser using your desktop, they will actually show you a message, teasing you that you should not be playing with the size of the window. I believe it’s a trap that many people fall into, just making sure that the website just works in different desktop screen sizes. But you should really focus on the devices themselves.

You sometimes maybe forget to actually test it and see if it’s working as well as you would have liked on mobile.

Tinna:

I completely agree. When you design it in such a way that it looks nice in all the browsers or on all of the devices, you sometimes maybe forget to actually test it and see if it’s working as well as you would have liked on mobile. Since launch, we’ve had to do some changes because some things were just very awkward on mobile. These were usually pages that were not very common and we just maybe forgot to test them very well. But once we started using it on mobile itself, we saw that, “Yeah, this stuff is not working at all,” so we had to go back and just think, “How do I want this to be on mobile?” That’s definitely the approach that you should take.

Also, don’t be afraid to just go for it. I don’t think there’s any reason not to go responsive.

Karen:

Well, I have to say there’s a lot of organizations out there that seem to think, “Well, responsive is great if you have a blog or a very simple content site,” but there’s no way it will work for a complex transactional web application. Einar and Tinna, I’m really grateful that you took some time with us today to explain that, yeah, it’s totally possible. It sounds like you have a really great success story there, so thanks a lot.

Einar:

Thank you.

Tinna:

Thank you.

Ethan:

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

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 also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near you.

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.

Thanks for listening, and we’ll be back next week.