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.)
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.
Let's take a look at how this might play out, using UXPin's Guide to Mobile-First Responsive Design.
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:
3840 x 2160
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:
- Things that apply to desktop systems comparably as they do to mobile
(e.g., content first)
- Things that will be informed by the fact that mobile-first design is
common practice (e.g., hover behaviors)
- That that are irrelevant to desktop (e.g., touch behaviors)
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.