Mastering Real-World Constraints (A Case Study)

Advertisement

As UI designers, we’re always interested in learning, reading user research, understanding best practices and keeping up to date on all the latest approaches and tactics for building websites and applications.

One of the most exciting concepts we’ve started to apply to our thinking is the mobile-first approach, famously pioneered by designer Luke Wroblewski on his blog1 and then in his subsequent book. Generally, this approach provides a healthy way to gain focus, cut the fat and get to the heart of what’s important — for both content and interaction.

But what happens if you have an existing site or app that was built for desktop without a responsive or mobile strategy in mind? And more specifically, what if you, like us, don’t have the resources, time, or budget to start over from scratch in the near term? Despite being a design shop, we at Fresh Tilled Soil2 found ourselves in this very position. This is how we addressed it.

The Challenge

As a Web and mobile app UI design firm, we couldn’t very well ignore the problem for much longer and let prospective clients pinch, zoom, and squint on their phones to assess whether we were the right agency for them — particularly when we offer mobile Web and native app design services!

So what to do?  A design firm offering mobile and responsive design solutions should certainly practice what it preaches – especially with the data showing an increasing number of visitors accessing our site from their smartphones. Because we wanted to share the same information regardless of device type and maintain a single codebase, a responsive approach was the best solution.

Though our resources were limited, we were fortunate enough to have several team members with a limited window of upcoming availability. We quickly assembled a small team with the goal of rapidly making our entire website truly responsive (though keeping a particular eye on our iPhone and Android users). Based on our analytics reports, these devices were by far the most popular among viewers of our site.

Our research showed us that 51% of mobile visits were on iPhones, 40% were on iPads and the remaining 9% was broken up between various Android smartphones and tablets. However, we felt that a truly responsive solution where each of our layouts was fluid made for a better solution than just targeting specific devices.

How To Begin

  • Identify Key Layouts to Address
    As a group, we discussed what mattered most from a prospective client’s point of view, then identified which layouts would need custom design and which could be handled directly in the code.
  • Focus On Screen Size Beyond Just Specific Devices
    Once the custom layouts were designed and coded, we identified organic breakpoints between mobile and desktop for further refinement.
  • Account For New Device Capabilities
    We updated graphics to support the higher resolution associated with retina displays.
  • Design and Code in Parallel
    While the designers got to work on the custom layouts, developers began adapting the website to small screens, converting fixed widths to percentage-based. A designer and developer then worked side-by-side to further refine the typography, navigation and layouts in code, making improvements in real time.

Our Process In Action

1. Streamline the Navigation

Consider the limited real estate of a mobile screen and examine ways to simplify layouts.

In designing for the mobile experience, the first decision we made was to simplify the navigation to a series of icons that represented each of the sections. We removed the large background image of our handsome CEO, Richard Banfield, and focused on making it easy to see the positioning statement and start any of the videos.

2. Identify Device-specific Use Cases

Think about what visitors want most from your mobile website and consider how to make it easy for them to access.

We thought it was important for clients who were visiting us for the first time to be able to easily contact us or access a map to our location. By envisioning this from the user’s perspective, we decided this content was important enough to be in a prominent location on mobile devices. Simply showing this section when the device screen width implied a mobile resolution and setting it to not display on larger screens was enough to do the trick.

Contact information and directions were made more prominent in the layout on small screens, to assist clients who are visiting for the first time.3
Contact information and directions were made more prominent in the layout for small screens, to assist clients who are visiting for the first time.

3. Simplify Existing Functionality

Make sure your interactions work smoothly on smaller screens and retain their context.

The portfolio section was simplified on smaller devices to only showcase six projects, and the portfolio detail images now appear above the thumbnails rather than over them to keep the context of the portfolio section.

Interactions were simplified to make sure they work smoothly on smaller screens.4
Interactions were simplified to make sure they would work smoothly on smaller screens.

4. Rethink Potentially Awkward Interactions

If something requires a custom design approach, invest the time to truly optimize it.

Some UI choices that make great sense on a desktop simply fall flat on a mobile screen. On the desktop version of our website, the team bios slide into view above a grid of team members, with each person’s details appearing to the left of a larger head shot. Knowing that these biography layouts would probably have to anchor and jump much higher than the grid and would then require quite a bit of scrolling to read the bio, we came up with an altered design treatment that resembles a modal overlay.

UI approaches that didn't work well on small screens were given a different design treatment.5
UI approaches that didn’t work well on small screens were given a different design treatment.

It was important to identify that the team section would need custom design early in the process so we could get started designing, testing and iterating. We used a div that slides up from the bottom of the page, covering about 90% of it. The bios were then shortened in length so that each bio could be presented without scrolling in both the portrait and landscape orientations on our target devices.

5. Use Tried-and-true Responsive Patterns

Not every layout needs to be re-designed for a smaller screen. Sometimes making columns stack and letting their widths fit the screen is the optimal treatment.

On our website, not all sections required custom treatments for smaller screens. Below the team area, the “Habitat” (article, workshops and events) section implements a more straightforward responsive approach in which the two-column layout simply stacks vertically. The detail pages for each of those items also use a similar stacking approach, and we made sure the option to register for a workshop was in a prominent location.

6. Removing Unnecessary Elements

Always consider simplifying. If something on your desktop website doesn’t apply to a mobile context, then maybe you can remove it. If you find it’s an improvement, then consider ways to simplify the desktop layout as well.

Toward the bottom of the page, our contact section was greatly simplified to only include a mobile-friendly contact form for prospective clients to get in touch. Since we already feature the “call us” and “directions” buttons at the top of the website, we were able to remove the address and map from this section.

The contact section was simplified to remove duplicate elements.6
The contact section was simplified to remove duplicate elements.

Lessons Learned

  • Make informed decisions.
    By making the website structure fluid, by testing and by identifying which sections could be reordered or re-structured to optimize for mobile, our small internal team was able to get started immediately and move quickly.
  • Teamwork is key.
    Everyone was able to present their case for what to add, remove or change, as long as it came from a place of putting the user’s goals first.
  • Don’t over-formalize the process. As with many design projects, quick sketches and white-boarding sessions, followed by small changes to design comps and actual code, brought the bigger picture into focus without us getting too carried away with an overly formal process.
  • Understand what devices your audience is using, but take a fully responsive approach.
    Lead Designer Alex Sylvia says, “We were conscious to test on the devices our clients were using, but we also wanted the design to react organically. The only way to discover that was to interact with the site at various sizes.” By using this approach while also testing on devices we knew our audience was using based on analytics, we got the best of both worlds.
  • Use the best technology for the job.
    One of our senior UI designers, Alec Harrison, quickly spun out design comps for the team member treatment, using LiveView to immediately showcase the comps on his iPhone. This provided the right context for improving the design.
  • Collaboration is key.
    Rather than designing independently, collaborating with a developer to make design decisions directly in code helped us reach an organic solution. Our lead developer, Sarah Canieso, had this to say about the process: “This project reiterated for me that responsive projects are very much a collaboration of design and code. It was a balance between the visual — where the design changed at different breakpoints — and maintaining functionality that would provide a good user experience across devices.”

The Impact

Since launching the responsive version of our website, we’ve noticed the following improvements in mobile user behavior:

  • A 17% reduction in our bounce rate.
  • An increase of time spent on our website — up to 3 minutes from just 40 seconds.

Additionally, we’ve received several compliments from prospective clients who have accessed our website for the first time using their phone.

While a mobile-first approach gets to the heart of simplifying a site or interface for all resolutions, large and small, that just is not always possible. In a crunch, we feel the process we undertook helped greatly improve our site on smaller devices. And in the process, it made us even more knowledgeable about  supporting various devices with a single codebase.

(cp) (ea)

Footnotes

  1. 1 http://www.lukew.com/ff/entry.asp?933
  2. 2 http://www.freshtilledsoil.com/
  3. 3 http://www.smashingmagazine.com/wp-content/uploads/2013/01/Article-Image-1.png
  4. 4 http://www.smashingmagazine.com/wp-content/uploads/2013/01/Article-Image-2.png
  5. 5 http://www.smashingmagazine.com/wp-content/uploads/2013/01/Article-Image-3.png
  6. 6 http://www.smashingmagazine.com/wp-content/uploads/2013/01/Article-Image-4.png

↑ Back to topShare on Twitter

Alex Fedorov is the co-founder of Fresh Tilled Soil - a team of designers, coders and UX experts that helps entrepreneurs and businesses build bloody brilliant user interfaces and experiences for web and mobile applications through consulting, training, education and events. Since 2005 the firm has helped 300+ clients including General Electric, Microsoft, MIT, Harvard, Bill & Melinda Gates Foundation, Walgreens, Hubspot, TEDx, Time Warner Cable among many others. Alex is passionate about clean, data-driven design that helps increase efficiencies and solve business problems. When he’s not working with the Fresh Tilled Soil UI team, researching or designing an interface, he's most likely making rap music.

Advertising
  1. 1

    John MacMenamin

    March 28, 2013 5:48 am

    Great post and I love that you added the results from your efforts.

    7
  2. 3

    “Design and Code in Parallel”

    I’ve never come across a circumstance where this is a good idea.

    -16
    • 4

      I have. I do all my design mockups in the browser. It’s much quicker than making a full mockup in Photoshop and then going through and transferring everything to code. Plus, you never have to ask the question, “How will this look in an actual browser?”.

      Also, because of HTML tags it’s much easier to change line spacing, margins, colors, etc… using CSS as opposed to making all those changes to all the Photoshop elements just to see if the changes are correct or not.

      5
    • 5

      In my experience, it reduces the iteration cycle significantly. The sooner a designer knows where development and presentation issues are, the easier he can redesign a solution for it. If the designer(s) and developer(s) are working closely and in tandem, it’s a great flow. Constant communication is key though.

      1
      • 6

        Thanks Emily. I agree – we recently completed a project where a designer produced two key pages that defined the structure, composition, color and general style or theme of the project and then using the requirements for what belonged on the other pages, we were able to rapidly design many of the other pages in code, checking in every so often with the designer to ensure that his vision was being respected. It also helps when designers have HTML/CSS chops and can interpret how additional pages or elements might look given some initial direction.

        1
    • 7

      I can understand the hesitation to adopt this workflow, but what I was specifically getting at in the article was the concept of coding and adjusting as much as you can in the browser using responsive principles and designing solutions that need special attention.

      1
    • 8

      We do it all the time, where I work.
      In previous jobs, unfortunately, the general accepted ‘norm’ was it was bad practice to do so. The crazy thing is, this wasn’t decided by coders nor programmers, but rather by management / accounts.

      It’s a mindset where you want every individual to fit exactly within predefined daily time slots. It’s also a mindset practiced by companies who don’t allow their designers and developers to make big decisions – it’s the top down approach, with a single persons vision dictating. Finally, it’s an outdated mindset that originates from more ‘traditional’ industries – heck, I’ve actually NO idea where it originated – control freaks?

      “Design and Code in Parallel” is a *brilliant* idea, because it recognises web development is a team effort that needs to constantly adapt at short notice.

      It doesn’t necessarily mean that the designers and coders are working together each day, it should be a flexible approach with lots of communication.

      0
      • 9

        Agreed, and I’d add that designing in this way really does break from the traditional approach of Wireframe > Design > Code since you have to consider so many variables from the onset. My hunch is that we’ll see more of a design/code collaboration as UI/UX gets more widely recognized and appreciated.

        -1
  3. 10

    Great article. Thank you so much for letting us in on what some would consider the monumental task of repurposing an existing site to RWD.

    There has been a lot of talk regarding the dangers of assumption in the mobile environment. Google research has shown that most mobile device happens at home vs. on the move. Did this research influence your design, and if it did, how? I only ask because the use of the call us and directions buttons seem to be based on the assumption that the mobile user is, well, mobile, but in my mind they add to, not take away from, the mobile experience.

    Very well done, especially considering the limited time frame.

    0
    • 11

      Great point about mobile assumptions, Ryan. I also recently heard similar findings – that essentially, users are capable and prepared to engage in every type of activity even if they’re on a small screen in a mobile context. Perhaps we should use a mobile detection script to load those “Call Us” and “Directions” buttons as opposed to just screen width.

      1
  4. 12

    As much as I love Responsive Web Design, and as sold as I am on the Mobile-first approach, I’ve yet to this date in finding a resource that shows you from the ground up how to take on and utilize these concepts.

    I have a good understanding of HTML and CSS, but many either lose you by assuming you’re familiar with certain concepts or I just don’t successfully grasp what it is they’re trying to tell me.

    Maybe a discussion on sketching up the design and defining breakpoints first? I love using the white-board and drawing. Take down a list of the individual components of the site, work on arranging them, list pitfalls of the process, etc.

    I just dropped $25 for some videos on Responsive Design and though well put together, they didn’t answer many questions.

    6
    • 13

      Thats the point when you have to put the pieces together and do a video yourself.

      -1
      • 14

        I find it funny to see people put a negative rating on my comment simply because I’ve stated how difficult it is to find a resource that can teach RWD concepts effectively.

        Not sure what was so offensive to them; *I’m* the one having a hard time comprehending it. Heck, I’m even to the point where I’m willing to read a book to figure it out, and I have serious issues comprehending subject matter in non-visual mediums.

        9
        • 15

          I agree. All this fairy tail theory talk is great, but where’s a real working, viable solution to handling things like image re-sizing? That is, without forcing users to download three + sets of images or using some javascript program that may or may not be the best way to go into the long term?

          1
        • 16

          Uhhhhh you should have already read two books on the subject. A book apart was a great intro. People give negative ratings cause people are weird. Dont let it botter you. If you said you like vanilla cake some one would give you a negative rating.

          -1
          • 17

            Trip, did you read it? If it’s a book that ACTUALLY teaches not only the concepts but explains the step by step as it puts such a site together, then I’ll buy it right here right now.

            Too many times I’ve found that Smashing Books (as much as I love Smashing) are mere collections of articles word for word that are already publicly available.

            So far all the resources I’ve found talk about what RWD is, but they don’t explain the concepts and go into the nitty gritty.

            2
        • 18

          I cant for some reason reply to your final reply, so i will do it here:
          I understand your feelings, in some cases i need a fool proof step by step guide so i can be taught something new. In this case it was responsive web design that i just couldnt wrap my head around. I scoured the web and it was either “hurr you dont know? well too bad” or “here is something if you already know how”. Not much use.
          To cut to the chase, i bought this book which was exactly what i wanted. Teaching you RWD to those who know NOTHING and guides you step by step with easy to understand explanations:
          http://www.abookapart.com/products/responsive-web-design

          I just realized i sound like some home shopping commercial now, but “noobs” (like me) are constantly entering the scene like always, but its getting harder and harder to get up to speed.

          0
    • 19

      The reality is, virtually every website requires a different approach.
      Many of the tutorials and common methods use relatively simple websites as examples – and for good reason, as they teach you the basic building blocks.

      On some responsive sites, I’ve opted for grids, on others, I’ve gone completely off grid. I take bits and pieces from different frameworks, because I’ve found that for commercial websites designed to suit customer requirements, frameworks more often than not, don’t fit.

      Decent frameworks are well aware of this and are modular – you can take the parts that suit you.

      There’s no quick-fix solution to responsive, it’s hard. You not only have the various desktop browser quirks to cater for, but also mobile browser quirks, screen size, DPI, touch vs. point & click, accessibility.

      It’s not for the feint of heart & you really need to know your basic craft in order to create unique websites.

      1
  5. 20

    Congratulations Alex! Your research and hard work will benefit so many.
    Good Luck!

    0
  6. 21

    “less is more”, which is here “removing elements” is not actually as easy as it sounds!
    most of the problems i usually have in UI optimization is deciding “What” to remove…

    Thank you, great article!

    2
  7. 22

    Thank you so much for sharing this experience.

    0
    • 23

      Happy to, thanks for reading. Our hope was to share some field notes for people who don’t have the luxury of getting to start from a blank slate.

      1
  8. 24

    I am just giving you some serious critique of the design and some stuff I noticed.

    Design is clean and quite fluid. However, there are some things that I notice right off the bat. One the different areas are not very separated. Now, I am guessing this is intentional. Nonetheless, users can focus better when stuff has division in it. Currently each major area flows together with a simple HR type border line. I don’t know what section I am in unless I look at the menu. This is truly a pain, because most people focus on the content they are looking at. Therefore in order to figure out what section they are in they have to break away from the content.

    I suggest actually providing some form of header for each section. Does not have to be text, but something to distinguish it and give the user an idea of what type of content they are looking at and where they are at on the page. It could be simply an icon like you have up in your menu. Also, provide each section with a slightly different color background to let the user know they just entered a different section. The only section that I can tell that actually provides an actual clue as to what it is, is the Habitat area.

    I also find it interesting that your menu does not follow the same linear fashion of the display. Contact menu item is off, as to where it hops over to habitat and then back to Contact when scrolling down. As a user I would expect it to flow exactly in order as what is displayed. So the menu should flow: Portfolio -> Process -> Team -> Habitat -> Contact -> Blog

    Your click here button on the contact form has misaligned padding – small but noteworthy. Also, I recommend not using the word “Click Here”. Give the button some context instead of just “Click Here”. Something along the lines of: “I’m ready to rock!”

    I have also noticed that y’all seem to be stuck in the trend of showing your employees but without their names first visible, or some brief info. Now to me as a user, it would take me far too much time to hover over each to see their name. Also, I am not presented with any substantial information as to what their role is in the company when hovering. Instead I have to click. I can guarantee users are not going to spend time hovering over every person to see their name and click to see what they do. As a user I want to be able to just scroll and see brief info about each person and what they do. My recommendation is to include their name on the actual picture area as a transparency or it can be added to the bottom, without having to hover. Also include a job title. That way it gives me an idea of what they do. Now you can keep the click to show the more detailed info, or even on hover present a even shorter detail, but also allow click for full details.

    Just my 2cents, and I am just trying to help y’all.

    4
  9. 25

    Alex,
    Great work on turning your site responsive! The company I work for is finally getting on board with RWD and I just went thru a similar process with an old Joomla 1.5 based website designed and built about 5 years ago!

    I was wondering if you used any ‘RESS’ methods?

    1
    • 26

      At the moment, we’re not using any RESS methods for optimization, but we’re looking into PictureFill, which we just used on a smaller project. Our lead developer found that it significantly reduced load time and was relatively straightforward to implement.

      0
  10. 27

    Great article and explaining it with own website example makes it easier to understand

    0
  11. 28

    One more thing I would like to mention. I was viewing your site on iphone. For menu items you have used icons but for layman its difficult to understand which icon is for which section. I feel there should be some description in text so before clicking on icon I know which part of website I am going.

    0
    • 29

      Thanks Hetal. Regarding the icons, we tried our best to choose ones that spelled out what each section was – but to that point, “Habitat” being such an unusual section to begin with even in text, it was tough to spell out exactly what you’d find there. The other icons seem more expected, and with Habitat – even on a large screen, it’s really meant for exploration and browsing of all the different content associated there.

      0
  12. 30

    Very useful to know. Even a small increase in the time that a user spents on a website can make the difference!

    0
  13. 31

    Thanks for the info this is some great stuff. George Hewitt – Austin, TX

    0
  14. 32

    Hi,

    Interesting artical, didn’t finish reading it yet but it’s on process.

    U speak a lot about the changes you made from your “desktop site” to an easy and suitable mobile use. One thing that was really took my attention was how when you click on a link to read the article from Facebook application, and than click on photos in the body of the article to make them bigger for viewing smaller details- first, the picture is very bleary, second, it is impossible to go back to the same spot you stopped reading at. It ether lets u go back to the last page you viewed on Facebook before clicking the link, or either gives u a refresh option, which takes you right back to the top of the article .. Now, maybe I was missing a third option, which I would love to know about, or maybe the answer appears later in the article, where I didn’t read yet.. Would love to know so I can keep reading properly

    Thanks

    0
  15. 33

    Totally off subject from the post.

    You have some good looking people working at your firm :)

    0
  16. 34

    Quick question. Has anyone ran into the issue with iOS 6+ having some serious issues with AJAX caching. We’ve ran into this multiple times and figured this could fall into this conversation because it is a real world constraint as of late. It is highly documented by many developers. It seems that many people who have site using AJAX or use HTML5 web apps are having some severe issues with the way iOS6 caches web page POST. Any one had any other issues?

    0
    • 35

      Ah…..the dreaded iOS 6 overzealous caching feature. There is debate whether this is a feature or bug, but based off Apple documentation it’s a feature to increase perceived browser performance (at least that’s how I interpret it) . If anyone hasn’t run into this yet save yourself time and lots of head banging by reading this stackoverflow Q&A.

      http://stackoverflow.com/questions/12506897/is-safari-on-ios-6-caching-ajax-results

      Short story, make sure you include ……headers: { “cache-control”: “no-cache” }……..into all your ajax calls for a quick fix.

      0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top