I found this really great shirt last week on the rack. I grabbed my size, tried it on, working each button down the front until it became painfully obvious: this wasn’t made for me.
After a little investigation, I found the fine print on the label which read “European Cut.” Now, maybe this isn’t a problem you’re familiar with and that phrase would mean nothing to you. Congratulations, good for you. But for many of us, we need shirts with more of a… well, American cut.
This post is a continuation of our “5 Signs Your Product Has Outgrown Its UX” series. If you haven’t already, you might want to start at the beginning with “Does This Make My App Look Fat?”
When building an application, it’s best to start with a proof of concept or MVP built for a very specific end user, screen size, device, etc. It’s a lot like making a very tailored shirt that’s meant to fit one particular person. This user-specific approach might seem limited, but it’s a great way to gain momentum on the project and learn quickly what works and what doesn’t.
Many products start with this kind of specificity and focus. And initially, they may receive high praise from the test users. But as the product scales to a larger user base and they start relying on it more exclusively, it will foster a greater need for flexibility. Mike from sales might need to use the app on his tablet. Jenny the executive may have a different phone OS. And while those users may be understanding during a beta period, they will quickly turn to pointed criticism if their needs continue to be ignored.
All of this leads to what I call “User Exclusion,” meaning that the UX is catering to a particular subset of the user base and not the rest. And while this worked for standing up the app in the first place, it isn’t something you want to entertain outside of an MVP or proof of concept. Users will just end up saying, “This isn’t made for me” and abandoning the product.
While there are plenty of ways that you can exclude users in your app, there are three in particular that are telltale signs of an outgrown user experience.
Enterprise applications are built for work. It’s that simple. So there’s a general assumption that users will use the software on a desktop or laptop. This leads to designers creating a UX intended for larger screens with plenty of space.
But the enterprise has changed rapidly in the last few years. More users rely on their phones to perform work related tasks. There’s no longer a clear distinction between what constitutes a laptop-size screen and a tablet, or even a phone and a tablet. If you’ve optimized your designs for the desktop without giving thought to other screen sizes, this will be a huge pain point for your end users.
Hubspot is one application that is really dragging their feet when it comes to mobile services. Undoubtedly, they are operating under the opinion that if a user needs to do anything worthwhile, they will be using a full-size screen. That was a safe assumption in the beginning, I’m sure. But what happens when I need to make a quick fix to a template while I’m on the go? Change a bit of text? They don’t even display a “Log in” button when you view their site on the phone. If you’re smart enough to go straight to the app URL, you’re met with a mess of pages, none of which are properly designed for a smaller screen.
Let Hubspot be a lesson to you. It’s 2019, it’s time we embraced that people work from their phone.
Mobile First Only Design
The opposite problem also exists. Luke Wrobleiski introduced a concept called Mobile First several years ago. The premise being you should design your app in the context of a mobile experience first. This will force you to prioritize the elements that are the most necessary to the user and design a cleaner, simpler UX. It’s an excellent concept to live by as a designer, and if you’d like to read more about it be sure to check out Luke’s book, Mobile First.
But here’s the rub: mobile first can be just as much of a mistake if it isn’t followed with a thoughtful desktop solution. With a keyboard, mouse, and larger screen, desktop users have more power behind their productivity. Limiting your application to a mobile-first approach when it’s being used on a larger desktop is a missed opportunity to empower the end user.
Google’s Inbox product is a great example of this missed opportunity. Inbox was designed around a mobile experience; that’s pretty obvious. But they also intended users to adopt it for the web on desktop. Rather than thinking how the mobile-first UX could be augmented on the desktop, they just stretched out the UI to fill the screen. What you get is a lackluster app that feels half baked in the desktop context.
Platform or Device Specific
Beyond screen sizes are the actual devices and the platforms that run the app. Limiting development to a single device or OS makes testing and development easy in the beginning. But just like the other issues, it will inevitably exclude users when the app scales. This is a tough hurdle to get over in a product’s life cycle, but it’s an important one if you really want to be inclusive. Trust me, I know. I used to own a Windows Phone (gasp!).
Your product will inevitably scale to users with different expectations. Whether it is another OS or just an older version, chances are high that they will want to use the app in an environment other than what you expected. This is especially true over time. Users and technology can be fickle; you can’t guarantee that the platform you built the app on won’t fall out of grace within a few short years.
Alright, alright. Enough talking about the problems of user exclusion. Let’s talk answers. The good news is: if your product is still in its infancy, these solutions will be easy to incorporate into your roadmap. But that’s where the optimism stops. If you’ve got an application that is well on its way to maturity, I’m afraid you’re in for a bit of work.
As device screen sizes have become more diverse, there has been a growing trend around responsive (or adaptive) design. This approach involves creating designs that are flexible in their layout and organization so that they adapt to the size of the viewport. This isn’t really a new concept or technology, but in the enterprise we still see a number of organizations who have been reluctant to adopt it. Still looking at you, Hubspot.
By embracing a responsive approach, you are ensuring that your app will look great on any screen. That means when the new _____ phone comes out next year, you won’t have any technical debt to be ready.
If you’re interested in learning more about the philosophy as well as the implementation of responsive design, take a look at “Responsive Web Design” by Ethan Marcotte. He was an early champion of the responsive web design movement and provides a great foundation on where to start.
Build for the Web
At SitePen, it’s no secret that we champion the web as the ideal platform for most applications. Even if the app will eventually be delivered in a native experience, there are huge benefits to building it with web technologies.
The biggest win is that a web-based architecture will allow your app (perhaps with some minimal effort) to be device agnostic. You won’t need to maintain separate code bases, and the user experience will be consistent for everyone. This will require a smaller team while also allowing you to iterate faster through your roadmap. Win-win, right?
But don’t just take my word for it. There are plenty of enterprise-grade apps that rely on web architecture to simplify their tech stack. Slack is a prime example of this. For their desktop clients, they leverage Electron to deliver a consistent experience to users across platforms. Facebook is another example. They obviously have a horse in the race with React and React Native, but they have open sourced these tools so that anyone can use them to create cross-platform apps.
Does Your App Come in XL?
Is your user base expanding? Is your app inclusive enough? Whether it’s time to port your app to another platform or you just need help creating a responsive experience, our team has the expertise to make it an easy process. Contact us and let’s give your users a few more sizes to choose from.
Other Posts in this Series
Follow SitePen on Twitter.
Originally published at www.sitepen.com on February 5, 2019.