User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I am on a project designing a CRM-type system for call center operations.
The only people using it will be doing so on a company desktop, and there is no mobile or tablet functionality.
Is there still value of designing/sketching mobile first and then building out the desktop view? Or is it a waste of time building for a non-existent use case?
The main advantage of "mobile first" is that it forces you to narrow the app to its most essential features. You simplify the IA and the interactions.
Then as you design the desktop version each additional feature has to earn its way in. You have to carefully scrutinize whether the desktop features really need to be included.
Therefore, I'd say that a "mobile first" process would result in a better desktop app, regardless of whether an actual mobile app exists.
A CRM appplication is usually a lot of dashboarding with many and sometimes all the information/action about your user on one screen. I've worked with CRM apps which need browser on fullHD screen
I believe mobile first is wrong in that case for UI.
But you should design all your backend API to be small and modular enough to be able to (query, request, change) small part of your dashborads. One day, if the priorities changes, you'll be able to create a secondary (small,touch,no mouse,no keyboard) UI for mobile with the same backend API.
Yes, use your favorite mobile-first design process for desktop-only apps
Don't get hung up on the word "mobile." There is still value in mobile-first processes, even if the app won't be used phones or tablets.
As far as screen sizes go, this will probably be easy to accommodate, but don't simply assume the design will work on your user's screens. (You have the advantage that you can find out pretty easily everything about your users' displays, so there's no reason to skip.)
Progressive Enhancement
Mobile-first methodology includes using progressive enhancement techniques. These are every bit as relevant to desktop users as to phone users. Identify your base system - that is, the least capable browser you will need to support.
You may be pleasantly or unpleasantly surprised. If your users have modern browsers (or you can require them to) then front-end developers may be able to use powerful new web technologies. If your company is still stuck on IE 8, you want to find that out now and plan accordingly.
Choosing a design process
Looking at a web project that won't support phones/tablets, I see three choices regarding what to do when you would otherwise use a mobile-first design process:
(1) Skip the process. Just do it ad hoc.
(2) Discover a new (streamlined?) design process for desktop.
(3) Apply the same mobile-first process that you would use otherwise, skipping the irrelevant parts.
An illustration
Let's take a look at how this might play out, using UXPin's Guide to Mobile-First Responsive Design.
Responsive Breakpoints
Is analyzing responsive breakpoints irrelevant for desktop-only sites/apps? (You might ignore this if you were design ad hoc. And it might be at the top of your list of "mobile" steps you could remove from a desktop-only design process.)
What if you analyzed the resolutions used by your users anyway? In 2016, common resolutions include:
That's quite a spread - a whole additional screen-and-a-half a display you might use.
Take a look at your app, do your users need to pogo-stick between a list screen and a details screen? Would 3840 pixels be wide enough to have the list view appear beside the detail view, saving the user from extra clicks and frequent content-switches?
Mobile First is Common Practice
Mobile first practices are so widespread that users are accustomed to them, and websites that don't adhere to them seem dated, strange, and confusing.
Just to sketch out one example, consider the step #5 of UXPin's mobile-first design:
- Don’t count on hovers
In my opinion, relying of hovers for anything important was never such a great idea. But still, I've recently been asked about adding some to a site where "mobile doesn't matter."
The thing is, because so many sites have removed them to be more mobile-friendly, users are going to be less accustomed to hover behaviors than they were in the past. They may not find hover tool-tips, and hover dropdowns are likely to seem strange and annoying.
Don't re-invent the wheel
In your favorite mobile-first design process, the checkpoints will fall into three categories:
The items in the third category won't waste much time just to "check off the list." Just use your favorite mobile-first pattern, and let it make your desktop-only solution better.
For most apps written with html and css it is easier to add functionality for desktop than to remove it.
If there is a remote possibility that your app will have to eventually function on mobile apps (and let's face it - it probably will), then you should design for mobile first.
Here is a practical example:
A lot of apps today are built with an interface framework that is mobile first - like Bootstrap 3. In that particular framework there are specific css classes that dictate how your app will appear at different size viewports.
If you start with the smallest possible size (xs for phones), than all of the larger sizes that follow (tablet portrait, tablet landscape, various desktops) will inherit the styles of the smallest without you having to add anything extra.
But if you start with desktop and work your way down, you will have to remove any desktop specific classes that conflict with your design as you work your way down to smaller sizes. This would quickly evolve into a nightmare to maintain.
So from both a design and technical perspective mobile first is a practical choice for desktop development.
You may want to look at it this way - Given that most of the users would access it using big screens (desktops), there is straight away not much sense approaching it from the mobile-first side. Rather, given the nature of your application, think of smaller screens(not devices) as something that might complement the larger set of actions that the user can perform on the desktop. Say for example,
1) On the mobile version (which could of course be planned later), the user could get alerts, notifications etc for important activities happening on the application. In case of CRM, assume that could be some key analytical reports or the likes, which could be defined in the desktop version.
2) As I said, it makes sense to think smaller screens as an aid to the mother application, rather than using it to access the entire feature set. That would help with two things - a) You are not limited to design the feature set on the desktop, and b) You can plan the mobile version later as and when the users demand.
3) You could, however, keep the application's responsive design healthy - and not ignore it.
I totally agree with Ken Monhkern. And here's an UXPin article by Ben Gremillon that supports that method A Hands-On Guide to Mobile-First Responsive Design. BUT you must remember what differences good UX designers from... not so great, is the ability to decide whether the implementation of a tool is appropriate or not (in this case "designing for mobile first").
You mentioned:
Is there still value of designing/sketching mobile first and then building out the desktop view? Or is it a waste of time building for a non-existent use case?
Is not a waste of time at all! But if the company you're working for is in a hurry, and you see that working on this step will consume valuable time due to the deadline of the project. Well, it might be not such a great idea. Even if it helps to the final product.
We, as UX designers, want to deliver the best product possible to our final users. And sometimes we forget who are we working for. The implementation of a design tool/process will always depend on these 2 things: 1. The amount of time available. And 2. The resources available for the project.
I would highly suggest start to design mobile first if is a requirement and a valid use case. Retrofitting a CRM is not a pretty situation and easy to design.
I have worked on similar types of projects before, and used the term 'desktop first' responsive design to frame the overall design concept/direction.
This implies that the design should still be able to accommodate different viewports and devices, but that instead of making sure that it works nicely on mobile devices first, the priority is that it will look good and suit desktop monitors and configurations. This then also gives the possibility of extending the scope to mobile websites and designs later down the track without having to redesign the entire interface.
Even for your particular application where people will be doing actual tasks on a desktop machine, it might be good to consider notifications, updates or dashboard/reporting displays on mobile devices because it is almost becoming an extension of a lot of desktop purpose applications. It doesn't hurt to cater for such possibilities, at least to minimize the risk of going down a design path that won't cater for it later on.
If its a company back office CRM and will only be used in the office, there is no need to design it mobile first. It will just cost you additional unnecessary resources.
However, in my opinion, you should use responsive design and focus on the desktop resolution. This way your system will be optimized for desktop and in the same time mobile ready in case in the future you want to use the CRM on mobile devices.
Good luck.
I'm gonna disagree with most here.
No, it is not useful to actually design a mobile view. Nor do you need to take in consideration things like extra large fonta due to higher pixel density.
Yes, deciding on prioritized content is good. Yes, backwards compatibility is good. Yes, pay attention to performance.
But those are all tools and strategies. You also use the same tools to make a cabinet as you do a table. But you don't first make a table and then turn that in to a cabinet.
Curation, optimization, both are common-sense approaches. They aren't exclusive to mobile-first design. They're essential to any kind of decent design.
