Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

How To Give Our Clients The Best Deal In Mobile

Are we cheating our clients when it comes to mobile? More precisely, are we allowing our desire for mobile work to get in the way of providing our clients with the best solution for their business needs? This is the uncomfortable question we asked ourselves recently when redesigning our agency’s website, and we want to discuss it with the broader Web community: You, dear reader.

The recently relaunched Headscape website
When redesigning our own website, we were forced to challenge our reasons for putting so much emphasis on mobile development.

We are not for a minute suggesting that either we or anyone else is intentionally taking advantage of the current excitement about mobile to “con” our clients. However, we do wonder whether our clients’ excitement and our own desires are hindering our ability to make rational business decisions — decisions that would lead to the best solution for our clients.

Further Reading on SmashingMag: Link

Jumping On The Band Wagon Link

By now, we all know that mobile is the next big thing. Not only do we realize it, but our clients know it, too. The growth in smartphone usage and the availability of fast mobile Internet connections are driving an explosion in mobile Web access. Organizations of all shapes and sizes need to start taking mobile seriously or else suffer in the near future.

Mobile growth infographic5
There can be little doubt that mobile is becoming a major way to access the Web. Image source: Econsultancy.com6.

For us, mobile is new and exciting and spells the future for our industry and careers. Unsurprisingly, we want to be a part of that. This scenario is not dissimilar to the one that many print designers found themselves in, all those years ago. When the Internet arrived and everybody was desperate to get their first website, the print design world skilled up and got building. Many websites were built in those early days that were never visited by an actual user. For many, the excitement got ahead of the demand.

Nothing is wrong with us as a community wanting to move into new areas. Nevertheless, we need to ensure that we do not push solutions onto our clients that they do not yet need, simply to boost our portfolio.

Do Our Clients Need To Think Mobile Yet? Link

Timing is everything. For businesses that are trying to turn a profit, their return on investment (ROI) matters.

Although mobile is important, it still amounts to a very small percentage of the overall traffic for many organizations. So, quite often, optimization for mobile lands at the bottom of the design debt list — the list of issues that have to be addressed by the design team. Business considerations, particular features and technical issues in the shop often have a higher priority, especially if the client’s company is relatively small.

While investing in the future is, of course, important to the client, if they do so too early, they run the risk of investing their money in areas that don’t have an immediate result and that might become out of date just at the moment when the areas become relevant to the client. Helping them work through this timing issue is important for us, as service providers.

Wait a second! If we build our websites mobile-first, surely they won’t go out of date, right? I am not so convinced. Certainly, best practice in responsive design are not the same as they were a year ago. We are learning more all of the time, and best practices continue to evolve. Can you honestly claim that the code and design solutions you came up with a year ago are as good as the code you are writing today? Responsive design patterns7 emerge and change, CSS and JavaScript techniques evolve, and some solutions don’t stick around for a long time.

Percentage of mobile traffic on one example site
For many websites, the percentage of mobile traffic is still relatively low.

It’s difficult because many clients are just as excited as us about mobile. They want to build a mobile app or website because they love playing with their shiny new device. They know that mobile is the future and, so, convince themselves that now is the right time to invest. But it might not be right for their circumstances. Mobile might not yet be worth spending their budget on. Timing is everything when considering ROI.

The Cost Of Native Link

Among shiny things, native apps are the shiniest of all. Whatever arguments you may have against building native apps, if you put your bias aside (we all have bias), it is difficult to argue — at least to our clients — that native is not cool, slick and shiny.

In my experience, when most clients think mobile, they think apps. You don’t see TV advertisements promoting mobile websites, but a lot of ads promote app stores and native applications. Clients might not know the difference between native and hybrid — and our responsibility is to explain the difference to them — but when they think “apps,” they want “cool, shiny and in the app store.”8 They want a native app.

However, such apps are expensive. You need developers with a specialized skill set. It might sound obvious, but building apps is very different from building websites. Apps are software. Software projects need more rigorous planning and longer testing cycles, and so they take longer to complete.

And then you have to consider multiple platforms. If you go the native app route, then each time you roll out an app to a new platform (Windows, iOS, Android, BlackBerry), you have to do a lot of the work again. Usually little can be reused. Also, operating systems are updated a couple of times a year, and there will be at least one new device each year, too. These changes usually require apps to be updated as well. Of course, when dealing with Apple at least, there is no guarantee that your app will be approved and added to the store for customers to download.

You can reduce the costs involved by using hybrid app solutions and HTML5. The hybrid and native approach each has its pros and cons and its own place, but the bottom line is that app development is an expensive business.

The Hidden Costs Of Responsive Design Link

There may well come a time when we need to build bespoke versions of websites for mobile devices. As users replace laptops with tablets and many others access the Web only on their phones, such a move would be a worthwhile investment for some organizations. In the meantime, for everyone else, responsive design is a good solution9. Because it applies a new style sheet to the client’s existing HTML implementation, it need not be costly to implement.

At least that is the theory. In reality, things are more complicated. We all claim that responsive design is a cheap solution, but that depends on how far we take it. At the most basic level, responsive design just requires some changes to the CSS. However, we all know in practice that that is not always the case. Making an existing website responsive can be incredibly time-consuming, especially if you have to deal with legacy HTML code that can’t be easily changed.

The Special Cases Link

Responsive design is not as simple as linearizing the content. Many elements need special attention. The most obvious is navigation10, which often scales poorly across devices. However, it is not the only element. Maps, video11, slideshows, graphics and tables all need special attention. Also, third-party “widgets” that embed content on a website aren’t always configured to be responsive.

Example of desktop navigation
Navigation does not always translate easily to mobile devices.

The Cost of Imagery Link

Then there is the biggest challenge of all: images12. Many Web designers are rightly suggesting that delivering desktop-sized images to mobile devices is unadvisable due to bandwidth limitations. We also now need to consider devices with high-pixel-density displays, which require even larger images. However, optimizing images for different platforms and creating a mechanism to deliver these further increases the cost of responsive design. At some point, you have to consider client-side and/or server-side optimizations to address this and other issues, such as reducing the load of elements that won’t be displayed on mobile devices.

There is even talk now of the need to optimize typography13 so that it scales for different devices. Again, the idea has a lot of merit, but a price tag comes with it. The problem is that we as Web designers want to be seen by our peers as producing websites that use the absolute latest best practices. God forbid that we are seen coding with last year’s techniques!

Giving Our Clients The Best Deal In Mobile14
Now, screens are changing not just in size, but also in pixel density. Oliver Reichenstein suggests that we do not just need responsive layouts, we also need responsive typefaces. He has launched iA’s new website with responsive typography15 with a custom-built responsive typeface.

Of course, our desires are not what matters. What matters is that we provide our clients with solutions that make sense for them. This often entails providing a solution that we consider to be inferior. Not every client needs a Rolls-Royce — some will be happy with a Skoda.

The question is how do you know which solution best fits a client.

Picking The Right Solution Link

As I have already suggested, ROI should be the primary criterion in determining the right approach. If a client has a large audience that is willing to pay good money for an app, then you can go to town and build a Rolls-Royce. But if the project is more speculative, then starting simple would be best.

But money should not be the only deciding factor. The choice between a native app and a responsive website, for example, is not really a budgetary one. After all, a responsive website could cost more than some native apps.

In some cases, the decision will come down to what the app will do. If the client’s primary requirement is to deliver content to the user, then a responsive website is probably more appropriate. In my experience, the kinds of native apps that users download and continue to use are task-oriented. If your client wants to enable users to complete certain tasks quickly, then a native app might be the answer. Otherwise, use the Web.

The only exception is when the client needs to access features on mobile devices that are inaccessible to the browser. Typical examples are things such as the camera and the accelerometer.

If you conclude that a Web-based solution is the right approach, then it becomes an issue of budget and timing. If the client is happy with their existing website and doesn’t wish to change it, then you could consider building a mobile website that targets particular devices. This might not be your preferred approach, but it could be the most cost-effective until the client undertakes a redesign.

If the client’s budget is tight, then you might choose to use media queries to target certain ranges of screen resolutions, rather than going fully responsive. This will make development slightly easier, thus keeping costs down. Similarly, you would have to leave image optimization to the carrier, rather than optimize images on the server.

The message here is simple. Whether talking about native apps, responsive websites or anything in between, we need to put aside our personal desires and even the desires of the client, focusing instead on what the client really needs: a mobile solution that generates the best return for their business.

(Image credits on the front page go to Information Architects16.)

(jc) (al) (il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16

↑ Back to top Tweet itShare on Facebook

Paul Boag is the author of The User Experience Revolution and a leader in digital strategy with over 20 years experience. Through consultancy, speaking, writing, training and mentoring he passionately promotes digital best practice.

  1. 1

    Great article, Paul.

    There’s also PhoneGap which allows you to build hybrid apps with HTML that can access native functionality such as the camera multiple devices.

    One way to keep the budget down is to have a custom or open-source framework in place so that you aren’t always building all project elements from scratch.

    I agree though, the responsive approach can get expensive when you start using bleeding edge technologies and techniques, ie retina picture polyfills, etc.

  2. 2

    I thought these two snippets were the most important part of the whole article:

    “In some cases, the decision will come down to what the app will do. If the client’s primary requirement is to deliver content to the user, then a responsive website is probably more appropriate. In my experience, the kinds of native apps that users download and continue to use are task-oriented. If your client wants to enable users to complete certain tasks quickly, then a native app might be the answer. Otherwise, use the Web.

    The only exception is when the client needs to access features on mobile devices that are inaccessible to the browser. Typical examples are things such as the camera and the accelerometer.”


    “The message here is simple. Whether talking about native apps, responsive websites or anything in between, we need to put aside our personal desires and even the desires of the client, focusing instead on what the client really needs: a mobile solution that generates the best return for their business.”

    Finally some common sense is starting to appear in the Native vs Responsive debate. Native and Responsive should be seen as two tools in any web developer’s tool chest. Each solution has it’s strengths and solution solves a particular set of challenges. It comes down to the business needs. Responsive vs Native is not an all or nothing scenario.

    Debates about specific technologies which don’t consider the end user’s goals are really just nerd egos dueling it out at the expense of a successful project.

  3. 3

    Great article and a lot of very sensible advice too.

    As native developers we’re often approached to develop “apps” for existing websites especially e-commerce businesses. Over the last year though we have taken to advising clients that investing in mobile friendly versions of their existing sites would be a better spend.

    Most clients are un-educated in this area and it’s important that honourable developers give them sound advice rather than selling them expensive services clients don’t actually need.

    • 4

      Zach "The Z Man"

      October 5, 2012 5:19 pm

      Agreed. And it doesn’t help to have the media fueling the un-education by consistently using terms such as “HTML5” and “Responsive” in everyday speak when the general public has no clue these types of “technologies” have been around for a few years now.

      Whenever a client mentions either of those 2 things, my immediate reaction is to ask them “why?” and “what’s the overall goal?” and then educate them on whats-what surrounding the web and let them now make an informed decision.

  4. 5

    I think, as well as satisfying our own egos, we do need to massage clients too. I am not saying take advantage but give them credit for wanting to go mobile.

    We could debate until the cows come home on whether or not clients adapt the right strategy when considering mobile options. However, as UX professionals we should be steering the BAs, PMs and senior management with our valuable insight and not just let them dictate what they think they want. This is what leads to the devaluation of UX if the product doesn’t reach their expectations

  5. 6

    This is also a bit of a chicken and egg scenario, mobile traffic to a website could be low become they don’t have a Mobile friendly version of their site. Its important here to look at the users of a particular website, and therein the strength of having good user personas come into play. I think as important a factor than straight analytics is understanding if a website’s users use their mobile phone often to visit websites. This could be used as an indicator on whether a mobile site is needed.

  6. 7

    ROI is not a very straight-forward topic. Calculating it is not as simple as comparing the number of sales on desktop vs mobile. There are a lot of hidden factors which are not easy to see. For example, the users could shop the store on mobile, but only trust to make a payment on the desktop version or when they get home and discuss the purchase with family. In this case, our analytics numbers will tell us exact oposite of the truth: people did not buy using mobile. This is a strong issue and is a big news with recent Facebook research campaign:

  7. 8

    I enjoyed the article Paul. We (@exumatech) are a niche desktop software company transitioning to deliver more mobile applications. Our customers by and large spend a lot of time on the road or on the move.

    As we make this transition I often think about mobile ROI vs the hype factor, and whether my customers are chasing the next shiny ball or have true mobile business needs. One decision we did make was to build HTML5 apps and migrate to mobile by way of Phonegap. As a business app provider, this has proven to be a useful platform for us.

  8. 9

    Michael Meininger

    October 8, 2012 5:59 pm

    Great article- I am a fan of responsive and fluid sites…

    But, what about the option of having a separate mobile site ? A browser detector can send the visitor to the “m.” or “.mobi” site. This has been the norm for so many popular websites( major networks, forums, etc). There is even software out there that allows you to make a “mobile web app” – this is basically an app that sits(and serves) as a website(no app store, downloading, updates, publishing fees, platform variances or opening apps).

    We actually did a case study for mobile website bounce rates and the results were amazing. Our mobile site had an outstanding bounce rate of about 2%!!!

  9. 10

    With PhoneGap you still have to install tons of SDKs, xcode, build mobile apps, developer certificates, push upgrades to app stores. Way more hassle , compared to regular web applications.

    Services like or remove the pain of having to support multiple SDKs and doing builds, but these are not mature products yet. just went out of beta, but is still unreliable. Features like phonegap hydration are supposed to make updates distribution smoother, I haven’t tried them yet.

    The point is, native apps have significant support overhead which is often overlooked.

  10. 11

    Nick Chambers

    October 9, 2012 12:02 am

    I quite like the approach that Microsoft have taken with ASP.Net MVC 4 which allows the developer to create separate Views for Mobile and Desktop which has worked really well for me on some recent projects

  11. 12

    A rebuttal to Paul’s perspective that takes into account a marketing/branding perspective:

  12. 13

    As a user- the mobile experience better be REALLY good. I spend most of my time surfing the web on my mobile on sites that are NOT optimized or served up uniquely to a mobile device. It’s because most of the time the execution of a mobile site is bad and/or content is missing. If that is the case, I either wait until I can get to my laptop or just stop visiting the site all together.

    Then there is this new trend with ads on mobile sites- most of the time they are horrible on mobile optimized sites!

    As a developer, I always try and figure out if a unique experience for a website is warranted the extra effort. So far, most of the time it’s not.

    • 14

      Yes, thank you.
      I keep reading that we need mobile optimization. But mobile browsers were designed before the option to have a mobile specific site existed, and consequently are very good at navigating full size websites.
      When a hastily created mobile site replaces that, it’s almost always a disservice to the end user. They are often uglier, limit content (assuming they know what I won’t be looking for), or are just generally harder to find things on.
      I’m not saying not to create specific mobile designs, I’m just saying don’t bother if you aren’t going to do it really well.

  13. 15

    “The choice between a native app and a responsive website, for example, is not really a budgetary one.”

    Tell that to the client.

    Overall as Michael mentioned above, I don’t think any type of mobile specific TBD is the way to go.
    The trick is delivering optimized content to the user, regardless of the device they are using.

  14. 16

    The article covers some of my feelings with regards to RWD. I think the cause is noble but I believe a lot of the “stakeholders” beating the drum are often a little bit ahead of themselves for a variety of reasons, some of which Paul mentioned in the article.

    1) People expounding “Mobile First!”. I see no logic to this. People have seen the explosive rise of mobile users and thought “ah ha. I best get on that bandwagon”. But I rarely see the people pushing this philosophy put an analysis of their site traffic where it shows they need to treat mobile devices as the first port of call. Generally a lot of users will be using traditional PCs or laptops. A number more will be on tablets and other devices with “large-ish” resolutions.

    2) The myriad issues with typography, images, video and legacy code that aren’t designed to be responsive. Sure there are no shortage of workarounds, frameworks, javascript plugins and the like which attempt to deal with these. The fact is the underlying technology in HTML and CSS just isn’t fully ready yet.

    3) People using the fact there are a million devices of all shapes and sizes as a reason why you need a fully responsive site. I’d argue it sometimes/often works counter to that claim. Because of the sheer number of devices, screen sizes, pixel densities etc it’s nearly impossible to design a site “once” and have it work perfectly. I noticed that the new headscape site has issues (i’m on a desktop using Opera 12). Currently the home page has some info on “stuff we’ve done” for Blue Cross. At certain screen widths the text displays over the iPhone image used on the right.

    What I tend to favour is what some have termed the “lazy” way out. Have (usually) the one code base and just use 4-6 base sizes for media queries. Say a small 320px mobile, larger mobile (480px), tablet views for portrait and landscape, an old school 960px size and then a larger desktop size (1180px+). Obviously you adapt to your particular needs. Provided you take a bit of care and create the queries correctly you can make sure you don’t end up serving a 960px wide wrapper to a person using a device that is only 800px. Some will scoff that it’s silly to do the same thing 4 or 5 times but I’d probably find it more silly to spend time aching over how every last pixel flows around with often unpredictable or irritating results. At least with the way I approach, I can end up with a design functions correctly. With fully responsive approaches combined with all the shortfalls in HTML and CSS – next to no chance without way more time and effort. I’m not sure clients of the company I work for are interested in indulging the designer when they are being billed thousands of dollars in time.

    For the end user who happens to have a 1600px view but gets bumped into a media query for something like (min-width:1200px) – Do they care if they get served a centered website using 1140 or 1160 that doesn’t use absolutely all the space. Do they care that the content doesn’t flow like water as soon as the screen size changes? No. 99% of people won’t be resizing their screens at all. Or they’ll not have a device capable of it. They have better things to do. And as long as it works and the site looks decent they are happy.


↑ Back to top