James McQuarrie is a UK based Senior Product Manager who helps teams design, build and deliver digital products and services that delight their users.

Category Archive: Interface Design

  1. How “paving a cow path” resulted in a 10x increase in the number of people sharing content

    Comments Off on How “paving a cow path” resulted in a 10x increase in the number of people sharing content

    It’s 2019. I’m working as the Head of Product, leading a squad of 12 at a recipe sharing website / app company in Bristol, UK.

    The squad is a multidisciplinary team consisting of: Developers (iOS, Android and web), a Product Designer, a Data Scientist, a QA person and me.

    I’m responsible for the squad hitting their goals. Goals that they have helped set in alignment with the company’s goals for the quarter that are focused on retention of users who author content on the platform.

    Our squad’s goals (set as OKRs) are all related to the features within the product that relate to communication. Commenting, sharing content, chat, etc.

    We’re The Communication Squad.

    One of the goals we’ve set ourselves for the quarter is to increase the number of users who are sharing content from our platform with their friends and family. The idea being that if we can increase the number of people sharing content, we can increase the numbers viewing the content. If we can increase the number viewing our user’s content, we can increase the numbers giving feedback to authors (likes, comments, etc) about their recipes. As a company we know (from extensive user research) that receiving feedback is one of the key drivers for author retention on the platform. We also know that while our product is similar in many ways to a social network, most of our users aren’t connected to many people they know on our platform, so when they find a recipe they want to share they have to do so outside our product.

    From user research done by our insights team at the company we know that time and time again people we interview tell us that they like to share recipes with their friends and family via WhatsApp.

    So, to increase the number of people sharing content from our platform with their friends and family we dug into the data we had about historical sharing behaviour on the platform.

    The data confirmed what our researchers were telling us. The data showed that WhatsApp was by far the most popular way for our users to share recipes from our platform (at least in the countries / regions of the World where WhatsApp is the messaging service of choice, which were also the countries / regions where we had the most activity on our service at the time).

    Based on these data we reviewed the current user journey for sharing a recipe via WhatsApp and evaluated how we could improve it.

    The journey required a user to first view a recipe, then find the UI control to reveal sharing options, then choose from sharing the recipe via our app’s built in chat feature or via the “share” controls built in to the OS their device ran. Then they had to find WhatsApp from those OS level sharing options, then go through the process of sharing the recipe as dictated by the OS’s WhatsApp sharing mechanism.

    We, as a Squad, decided to experiment with different ways of improving the overall sharing experience, and while we did that we made one small change to the user journey specifically for WhatsApp users:

    We moved the share via WhatsApp option to be the first option the user saw when they opened the recipe sharing options, before they saw the OS share sheet. Effectively promoting WhatsApp two levels up in the chain of steps users followed when sharing content.

    We deployed the change and monitored its impact.

    The results were better than we’d expected. This seemingly simple change increased the number of people sharing recipes via WhatsApp by just over 10 times.

    One small change, driven by qualitative and quantitive data that supported it, lead to a 10x increase in users doing what we wanted them to do.

    That was a win for our Squad.

    Unfortunately, we weren’t able to map the increase in sharing activity to impacts on author retention in any meaningful way, but as an isolated exercise in insight-driven design I think it’s a great example of why sometimes “paving the cow paths” really is a good approach to product design.

  2. How we learnt we needed to slow our app down from observing user behaviour

    Comments Off on How we learnt we needed to slow our app down from observing user behaviour

    It’s 2015. I’m part of a small team of people working out of an attic office space in Farringdon, London.

    We’re a startup that’s just secured £2million in funding from a corporate backer to build a disruptive service that offers a new way of helping homeowners with home repair emergencies and niggles.

    Having spent months researching, reviewing and learning the ins and outs of all the existing ways people could get help from repair experts (think: plumbers, electricians, heating engineers, etc) we had convinced ourselves, our backers and a significant number of people we’d spoken with that there was a much better way of delivering home repair help: video calls.

    The startup was called “DAD” and we were building a service that allowed customers to install an app and hit a single button to start a chat or video call with a home repair expert (in seconds).

    The idea was that instead of waiting hours (in the case of emergencies), or potentially days (in the case of other repair issues), just to pay someone to come round to your house, suck air through their teeth while looking at your issue and tell you “I’ve not got the parts for that”, or “It’ll cost you to get that replaced”, we would get you expert advice within minutes of you discovering problems in your home.

    You would connect with our experts via video and show them the problem and they would give you advice about stopping it getting worse, diagnose the issue and either talk you through a fix on the call (our testing showed that about 60% of issues could be solved this way) or make arrangements for a tradesperson to come and visit you.

    In the case of us needing to send someone round to fix the issue, we were able (thanks to the video) to not only fully brief the tradesperson, but in most cases, let them know what parts, materials and tools they needed to complete the job, making our home visits more efficient than competitors in the market.

    The service worked. The tech worked. The customers we had mostly loved the experience.

    I say mostly because, as with any new product or service, we didn’t get everything 100% right from day one.

    One of the biggest mistakes we made took a few months to uncover.

    Back in 2015 making video calls over the internet was not a new concept, but the technology to make it work was not as advanced as it is today.

    At the time of writing (weeks into the UK’s 2020 covid-19 lockdown) there are several well developed API services that you can use to build video call services with, requiring very little effort. In 2015 that wasn’t the case. WebRTC was a standard and there were a couple of services offering solutions in the space, but we had to make most of the tech ourselves.

    Our CTO and his small engineering team did an amazing job and built us a really great video calling platform with a lot of custom features (the ability to record and save all calls that customers could watch back at their leisure in the app, for example).

    They did such an amazing job we accidentally introduced a big usability problem…

    People in 2015 were, on the whole, not overly used to making video calls. That’s a sweeping statement, and one that particularly feels like a massive generalisation 11 weeks into a lockdown that has made using Zoom and other video conferencing services part of the general public’s everyday vocabulary. But, back in 2015, the majority of people (at least those who were using our service at the time) didn’t make a huge number of video calls.

    If they did they were normally either on laptops / desktops in a work context, or they were via Skype or FaceTime and used for family calls or to speak with friends, socially.

    They were not used to the idea of using video calls to speak with companies as customers. And few were used to holding a phone or tablet while making the call.

    As part of our efforts to learn what was working well and what needed improvement we watched back a sample of customer calls each week.

    Seeing how they spoke, where they pointed the camera, how they held their devices allowed us to learn a huge amount about how we could improve the service.

    Thanks to these observations we introduced:

    • better scripting and support in call for our home repair experts
    • the ability for our experts to take photos (screenshots) while in the call so they could capture things like a boiler’s model number while the customer pointed their phone at it
    • the ability to turn a device’s flash on like a torch light, from within the call UI, allowing customers to easily shine a light into places like their cupboard under the sink to see what was going wrong with their pipework, etc.

    The usability issue we discovered by watching the calls was subtle.

    We noticed that a significant number of calls started with the customers looking startled and stuttering a: “Oh! Hello!”.

    It took a while to work out why so many seemed shocked at the beginning of each call.

    We did post-call user interviews, asking about their experience with our experts. We reviewed a wider sample of calls to see if we could uncover a pattern. We did our own calls, testing the process from a user’s point of view.

    Eventually we worked out what the issue was: we were connecting the customers and their home repair experts too quickly.

    The customers would hit the “call us” button and expect a delay. Our engineering team and the CTO had been too efficient in designing the connection process, making it so quick in many cases it seemed almost instantaneous, which caught our customers by surprise.

    While I’m all for building products and services that surprise their customers in delightful ways, surprising them by instantly connecting them to a live video call wasn’t delighting them.

    It was shocking. A harmless shock for most, but enough to put a significant number of our customers off at the beginning of their calls, and enough to make many of them have to take a few seconds to collect their thoughts before being able to explain why they were calling.

    To address the problem we redesigned the connection process on both the customer’s app and the home repair expert’s app.

    We built in a delay between assigning the expert who was answering the call to the customer, and when we actually connected them with picture and audio.

    In both apps we added status screens showing the process:

    • first “Calling DAD”
    • then “Connecting you to DAD”
    • then “Connected to XXX” (the Expert’s name), and a countdown “3, 2, 1”
    • then the call was live.

    During the count down we showed the customer’s own video feed on screen so they could see how they looked on camera and adjust their position / lighting etc before starting their conversation with our expert. (We did the same thing for the experts, but they were normally working from iPads that were sat stationary on a table / desk, so were less likely to need to reposition their camera, etc).

    Having put the redesign live we continued to watch a sample of recorded calls each week and I was very happy to see that we’d significantly reduced the number of customers who started their calls looking like Rabbits caught in the headlights of an oncoming car.

  3. Freelancers can update their availability in under 30 seconds with NEXTFREE

    Comments Off on Freelancers can update their availability in under 30 seconds with NEXTFREE

    From the very start of NEXTFREE we’ve put a lot of effort into trying to make it as easy and as fast as possible for freelancers to update their availability.

    We’ve focused on making it easy for one simple reason: out of date information is junk.

    If a Freelancer doesn’t keep their availability up to date, it’s useless.

    In order to get Freelancers to keep their availability current, we knew we’d need to make doing so as effortless as possible.

    I’m happy to say, we’re starting to see the results of our efforts paying off.

    Our stats show that it can take less than 30 seconds for a Freelancer to update their availability. That’s from when they load our log in screen, through to a successful update. Less. Than. 30. Seconds.

    I’m happy with that. But, we’re not stopping here. We’re still working on other ways of reducing the effort needed to keep a Freelancer’s account up to date. More on that in the future…

    More about NEXTFREE

    NEXTFREE is changing the way Freelance Contractors and Consultants share their availability with the World. If you are a Freelance Contractor or Consultant and would like to try our service for free you can sign up for an invite to our Beta program at Freelancer invites.

    If you hire Freelancers and would like an early invite to our Recruiter Beta program when it starts sign up for an invite at Recruiter invites.

  4. Imagine if your watch knew what you were holding – Disney Research shows you how

    Comments Off on Imagine if your watch knew what you were holding – Disney Research shows you how

    This is an extraordinary video demoing how a smartwatch can be made aware of what you’re currently holding / touching and be programmed to respond accordingly.

    My favourite thing about this demo device is it’s use of audio feedback. I think audio UI is a massively underused and under explored area of design at the moment. Too many of our devices and products allow us to talk to them, but aren’t capable of talking back to us. There are many cases where a speaking device would be inconvenient, invasive and potentially, useless. But, I think there are a growing number of uses for audio feedback. Especially when so many people have headphones plugged in while at work, or commuting, etc.

    For example, if I get a phone call while I’m listening to music / podcasts / etc with headphones on my iPhone, I’d love it to say the name of the caller as well as ring. Pausing what I’m listening to and ringing in my ears is good, and gets my attention, but I still need to look at my phone or my watch in order to know who’s calling and make a decision about whether or not to answer it. If I’m already listening to something, and the headphones are in, and the phone already knows to pause audio, and play the ringtone, why not also get Siri to say; “XXX is calling”. If I don’t want to take the call all I have to do is ignore it, or dismiss it with either the headphone controls or my Apple watch, etc.

    I’m sure this is coming. Siri, and her fellow assistants on other platforms are getting more integrated into our devices everyday. And are becoming more capable. I’m looking forward to the day when they are more like the device in this video and can talk to us a little more in the context of what we’re doing.

  5. What if there were no screens?

    Comments Off on What if there were no screens?

    We look at them every day. For many of us, we look at them for most of the day.

    Wrist screens. Phone screens. Phablet screens. Tablet screens. Laptop screens. Desktop screens. TV screens. Cinema screens. Billboard screens.

    Often we have multiple screens in front of us at once.

    As web and app designers, we spend all our time thinking about designing for these screens. Designing how to present information on screens, designing how to navigate that information on screens, designing how to receive input and display feedback on screens.

    But what if there were no screens? What if screens go the way keyboards are heading on phones and disappear? What if we liberated our content from screens and could present it to people by other means?

    How would that change how we design?

    Google Glass is still a screen based device, but its heading in the screen-less direction.

    The iPod Shuffle was screen-less.

    The Misfit Shine is screen-less (and often criticised for being so).

    But how would we work differently if more devices were screen-less?

    Researchers have already produced working versions of a device that projects it’s content onto your hand or arm (see Skinput turns your arm into a touchscreen).

    Augmented Reality devices and apps are showing us glimpses of how screen-less worlds might look, of how we might design for a time when information is overlaid on the physical world around us instead of being stuck on a screen.

    The explosive growth of smartphones forced many designers to think about screen size for the first time. Design became about being adaptive and responsive to the capabilities and sizes of the devices that content is being displayed on.

    How would we adapt to no screen at all?

  6. A New Car UI: How touch screen controls in cars should work

    Comments Off on A New Car UI: How touch screen controls in cars should work

    This is a really interesting concept. I like that someone is thinking about how to improve what can be very hard to use in-car controls.

    I like the idea of a more loose design, where the controls can appear and fit to wherever you place your fingers on the screen. There are some very nice touches with the resolution of the controls too; small increments for volume up / down and bigger, easier to hit increments for music sources, etc.

    But, there are three issues that this design hasn’t been able to overcome:

    1. firstly there’s no affordance in the design. While the concept allows for up to eight different finger combinations to trigger eight different controls, there’s no indication in the design of what these eight combinations may be. How a driver would discover what the options are and then remember them all is not clear.
    2. secondly the interface is limited to the number of features it can offer by the number of finger combinations you can create with one hand. This may not be a problem if car manufacturers could limit themselves to only using this interface for eight or less controls, but I’d imagine there would be more they’d like to use it for.
    3. finally, assuming that all eight combinations of finger gestures were used for this interface, anyone who is missing one or more fingers would be unable to access all of the controls.

    I think this idea is really interesting though, and addresses a real problem with many current design solutions. I’d be interested to see if the limitations I’ve listed could be overcome.

  7. Redesign

    Comments Off on Redesign

    It’s finally here. After well over a year of thinking about a redesign, sketching ideas, hacking code, testing and then testing some more, I can finally reveal version 6 of this site.

    The last update was done back in June 2011 and was more of a tweak to the design than an overhaul. This update is a total visual re-imagining.

    The content stays the same, and the organisation and navigation doesn’t change much either. What does change is the layout, the look and feel and (I hope) the reading experience.

    Focusing on reading and therefore typography

    The majority of visitors to this site come for one of two reasons:

    1. to find out more about me and the work that I do
    2. to read one or more of the (limited number of) blog posts that I’ve written over the years.

    In both cases people are here to read, so making the reading experience as pleasurable as possible became my number one goal for this redesign.

    For a while now I’ve been telling anyone who would listen how my iPad mini combined with apps like Reeder and Instapaper have changed the way I read online content. In the past I’d tend to skip through anything that was too long as it just wasn’t a very nice experience having to read long screens of text on a laptop or desktop.

    Reading long form text on an iPad is more comfortable as it allows for a more lean-back, relaxed reading experience but many sites are not designed with smaller screens in mind and are therefore either not accessible on an iPad or don’t render very well on a small screen. Apps like Reeder and Instapaper help solve that problem by allowing me to extract the content from sites that have not been designed with smaller screens in mind, and present it on my iPad in a way that has been specifically designed to make reading on it a pleasure.

    Reeder & Instapaper on iPad Mini screenshots Figure 1 – Reeder and Instapaper on an iPad Mini

    Inspired by my experiences of reading on my iPad I wanted to find a way of making reading my own site, in a browser, on any sized screen just as pleasurable.

    To do this I started by looking at what made the experience so good in those reading apps. It all stemmed from the treatment of the typography. Good typeface choices, comfortable line lengths, pleasant spacing and white space, good text sizing, clear visual hierarchies and colour and contrast choices that are easy on the eye.

    I spent time focusing on each of these aspects of the design and applying them to some example content from my site to get a feel for what would work and what would not. This process was not linear: I would settle on a typeface I liked for headline and body texts, play with the spacing, sizing, colour, etc and then see a new typeface I liked or find the contrast wasn’t enough on a particular device’s screen and have to rework each element again and again.

    Weeks of experimenting resulted in what you’re reading today. I still have a lot to learn about designing with type (The Elements of Typographic Style is on my ‘to read pile’) but I’m happy with the results so far and think they are a vast improvement on what was here before.

    Once I had the basics of how I’d like the text to look nailed down I started working on how non-text content would look. I don’t often add images to my blog posts, but almost all of my portfolio pages include screenshots or illustrations of the work that I’ve done, so I wanted a way of including images in amongst text that was both visually interesting and flexible enough that I could include images that could work on different sized screens and be referenced within the copy.

    Again, before I started working on the design I turned to examples (both online and offline) of beautiful uses of imagery for inspiration. Digging around in magazines, product catalogues and blogs I built up a picture (no pun intended) of how I’d like to treat images in the redesign. I settled on supporting two sizes: full width of an article and half the width of an article. Half width images can then be placed either to the left or right of the article when space allows.

    To add visual interest I’ve been cropping the screenshots that are shown at half of the width of the article to only show half or two thirds of the full image. I’ve been careful to not use this style for images where you need to see the full screen to understand what you’re looking at or when the full image is needed to illustrate a point in my text. But where I’m including a screenshot to give a feel for the design that I worked on, I think the cropped images work nicely.

    With the designs for the content of blog posts and portfolio pages sorted I turned my attention to designing the navigation and branding elements of the site, and the most important element: the overall grid.

    Embracing the grid

    Grid Systems in Graphic Design cover image Figure 2 – Grid Systems in Graphic Design

    Having not had any formal design training I have only discovered grid theory in that last few years. As designing with grids has become a widely talked about technique in the web design community I’ve realised that there’s so much I don’t know. I’m still learning about the theory, and how it can work in a fluid, responsive web world, but I’ve tried to read as much as I can on the topic and relied heavily on Grid Systems in Graphic Design (Figure 2) to help me think about grids while working on this redesign.

    To make the site work on screens of all sizes, I wanted the design to:

    1. make full use of the space available on all screens; without breaking the carefully chosen line lengths and text proportions I’d already designed for article text
    2. look consistently like my site from one screen to the next not similar in terms of layout but similar in terms of text treatment, proportions and design elements.

    For this to work I developed two layouts: a single column layout for smaller screens and a two column layout for larger screens. Both layouts are designed to be fluid and expand and contract proportionally to make the best use of the screen space available. Both are based on the same underlaying proportions of an eight column grid.

    I’m still learning how best to approach design using grids and struggled on more than one occasion to figure out how best to do it. But I’m glad I persevered. Purists may not agree with how I’ve applied, nor implemented the grid for this design, but I like the results, so I’m happy.

    I’m still working on optimising the code and the behind the scenes tools that run the site to make is as snappy and fast to load as possible. I’m still also tweaking the type and grid styling as and when I find problems or read and learn about better techniques. I’ve tested the site now on every browser I can get my hands on and on as many devices as I could find. With only one or two exceptions (Kindle devices, I’m mainly looking at you) I’m very happy with how the site loads and looks in most of them.

    As always, your mileage may vary so please do get in touch if something looks a little strange to you.

  8. Scrolling is not the root of all evil and there is no such thing as “the fold”

    Comments Off on Scrolling is not the root of all evil and there is no such thing as “the fold”

    Time and time again I get non-technical clients asking me to make sure that I design their web based product screens to reduce scrolling and to make sure I get as much as possible on each screen “above the fold”.

    And time and time again I have to explain why there is no such thing as “the fold” online and why we should focus our efforts on designing for clarity and readability rather than worrying about how much scrolling a user will need to do.

    The fold does not exist*.

    The term “above the fold” is a print world term referring to making sure a newspaper’s headline or main front page image is visible when the paper is folded in half on a newsagent’s shelve.

    In the world of digital, online publishing and products the term is used to describe the desire to make sure that the most important elements of each screen’s design were visible without the need for a user to scroll down “below the fold”. Which was an admirable aim and design philosophy back in a time when web design was still an emerging discipline.

    We as designers had not learnt important principles like how navigation design and information hierarchy helps to orientate users within our content. Users weren’t used to having to scroll to interact with the web, in fact; users weren’t used to interacting with the web at all.

    But, those days have past. Today we as designers know how to organise content, how to structure the information on a screen and, even more importantly, users have learnt to scroll.

    I have never once sat observing a user during any usability testing and seen them give up the task in hand because they had to scroll a page. They may have not been able to find what they were looking for, or they may have not understood what to do next, but not once have they not known how to scroll.

    In fact, one of the first things many of them do if they do get stuck is try to scroll to see if they are missing something, if there is more to see somewhere off screen. Often they will do that before using a site’s navigation menu if the labelling isn’t clear enough, “just checking if there’s a better option somewhere else.”

    If you ask these same users whether they like scrolling, they will say no. “I don’t want to scroll to find things”, “I don’t like scrolling pages and pages to find something.” But when you observe them using a site or application scrolling does not hurt their progress as long as the page has been well designed.

    What users say when asked abstract questions and how they behave while actually using something are not always the same.

    Trying to explain this to a client can be hard. The no scrolling mantra has become universal law in the minds of those who do not design for screens daily. It is one of those mythical rules of web design that many a project manager will wheel out to show they know about the web when appropriate (another favourite, that is thankfully starting to die a death, is; “everything should be no more than 3 clicks away from the homepage” – remember that one?).

    Explaining that we cannot control a user’s screen size, orientation or resolution goes some way to helping clients understand that the fold is at best a moving target. Explaining that not everyone browses with their browser window in full screen mode, or that some users have enough browser chrome to take over a third of the available window height also helps, but there is no silver bullet for changing people’s mind on this.

    Sometimes I have to give in and reduce the line-height or padding or margin to fit that little bit more content on the screen for the client’s choice of browser / screen size combination.

    It is their product and their choice.

    I only hope that as more of us use smaller devices like smart phones and tablets to interact with the web and more of our web experience is touch driven making scrolling child’s play, more clients will let go of their believe that the fold exists and that scrolling is the root of all evil in the World.

    *Okay, so the fold does exist to some degree. Not everything will always fit on a screen. And if you’re designing a page with minimal content, or designed purely as a hook to draw the user into a more in-depth process / engagement (think landing pages / sign up screens) it is worth trying to make as much of the content “above the fold” as possible on as many screen sizes as possible. But as with anything related to the web, to try and apply that rule universally to all content and use cases will not work. Be sensible and be guided by your content, its purpose, its audience and their needs.

  9. User Experience design is not User Interface design and neither is an optional extra in product development

    Comments Off on User Experience design is not User Interface design and neither is an optional extra in product development

    It is great that more and more clients now consider the user experience of their products to be critical to their ongoing success. It is nice to have witnessed attitudes change over the last five years or so as clients have realised what a difference a great user experience makes (largely influenced by the success that Apple have had, attributed to the excellent design and overall user experience of their products and their ecosystems).

    What is not so great is that many organisations still seem to be of the opinion that designing their product’s user experience is something that they can do after they have built it. They confuse user experience design with the graphical bit of user interface design and incorrectly assume that both can be added at the end of a project build as the polish on top.

    Both assumptions are wrong; user experience design and the graphical component of interface design are not one in the same. And neither should, or can successfully, just be added at the end of a product’s development as the “polish on top”.

    The look and feel of a product’s interface plays a big part in the user experience of said product, but it is not the only thing to consider. There is also the product’s information architecture, interaction design, information design and navigation design to think about. The design of each of these elements should be driven by your content requirements and functional specification, which in turn should be guided by your user needs and product objectives. Once your product has been built it is too late to change all of these elements of its design.

    You can’t add a great experience to a product that is already built to work in a specific way. A technology driven development process, where design is considered an optional extra to bolt on once you have built something is wrong. To create a great user experience for your customers, you need to be designing your product with them in mind from the start; for web based products that means you need to adopt a user driven approach to your development, designing your product’s interface, process flow and experience before developing the underlaying technology.

    Jesse Jame Garrett was spot in his book The Elements of User Experience. To have a great final product with a great user experience you have to have been thinking about delivering that great user experience from day one of your project. You sow the seeds of success when you ask that first set of questions about what do the users of this product want and need? If you can’t tie every decision you make about what your product does and how it does it back to the answers of those simple questions, your user experience will not be a good as it could be, and no amount of polish will change that.

  10. Interface design – Simple vs. Sparse

    Comments Off on Interface design – Simple vs. Sparse

    When starting any new application design project one of the discovery phase tasks I like to complete early on is to get a feel for what visual style my clients are looking for. This may constitute nothing more complex than a five minute discussion about their favourite designs or could be as involved as a half day session evaluating screenshots of designs that they love and hate to help understand why and what elements of one design make it good in their eyes over another.

    Going through this exercise I’ve noticed a change in trends of what clients are looking for.

    In days gone by I’d get requests like “make it like Amazon / Google / Ebay / insert-poster-boy-application-of-the-day-here

    The most common request I get for now from all clients is: “Make it simple” (often followed by; “like Apple do“).

    As someone who spends a lot of his time thinking about the holistic user experience of the applications he designs, I love that they want simple. But I know that making something look simple and making it simple to use are two very different things; many of my clients don’t.

    When they say make it simple, they mean make it look simple. They mean make the interface sparse. They argue for one word where three are needed to explain the context of a label. They argue for removing icons or background colours where they are intended to add meaning to elements on a screen. They argue in favour of text being bunched up, smaller and badly spaced so it takes up less room on a screen, so it fits “above the fold”.

    They lack an appreciation of the difference between simple and sparse. Between merely looking at or admiring an interface and actually using and interacting with it.

    To paraphrase the excellent Mr Steve Krug; “A web application’s interface should be obvious“. It should be self-explanatory. A user should look at every image, every label, every heading, every input or button and know what to do with it, know its relevance to them in their quest for information or task completion. They should not have to think about how it may work.

    One word labels like “Filter”, “Save” and “Add” without very careful placement or grouping with the things that they are related to can raise more questions than they answer. “Filter results“, “Save settings” and “Add a user” are more self-explanatory and even when carefully placed next to, or grouped with, their related interface elements still serve to re-enforce their meaning and reassure the user about what they are referring to.

    While I once spent my time encouraging my clients to remove the guff and bloat that they insisted on adding to every screen of their applications, I now find myself spending time encouraging them to add just enough back in to make their interfaces understandable and meaningful.