The Problem
Convince team to move beyond desktop
My client had an enterprise app that converts a set of photos into a 3D Model designed and built by an outside consulting agency. Before releasing the Beta, the product owner came to me to see if I could redesign the app from the ground up inside of 3 weeks.
Initially, I was told that the user community would only require a desktop application. After reviewing the existing desktop application and it's intended use cases, it was clear that most of the functionality could easily be made available on any device.
The Solution
Show them the Tougher stuff
What I mean by "show them the tougher stuff", is to show how the app can do the same things on a mobile device as it can on a desktop device. In many cases, that means showing how easy it is for users to edit something that is seemingly complex even on a handheld device.
In this case, I knew that if I could show the team a desktop edit screen next to a mobile edit screen that it would be easier to literally "see" how little needed to be adjusted to provide a mobile or tablet experience.
Here is my first example ↓
Getting engineering on your side
Hopefully, your first reaction to seeing the desktop version side-by-side with the mobile version is that they are mostly the same - both from a user and an engineering perspective. Some features, like "download", are not available on mobile, but 95% of the functionality is available on all devices.
At this stage in my career, I know that there is a wide difference in how engineers react to seeing something like this. I find it is helpful to have them on your side. One way to achieve that is to show someone on the engineering side your mockup outside of a formal review to let them ruminate on it for an afternoon.
As you can see in this design, I have "chunkified" the sections of the app view into the following sections:
- Viewer
- Model Details
- Photo Set
- Tags
- Actions
This allows the engineering team to think about how to create flexible components that can easily be modified at key breakpoints. For most projects, there are likely to be four breakpoints:
- 1440
- 1023
- 767
- 600
From there, engineering can start to think about how to make each page responsive as well as more accurately asses the level of effort required.
Let's look at a few more examples:
Getting Product On Your Side
Nothing helps your cause more than figuring out who your product team cares about impressing. I say this not to trivialize how the Product team thinks about their career but rather to embrace the reality we all face building products. We are all fighting and selling stakeholders, users and partners for resources to build our products. Maybe a top executive likes to use an iPad Pro. Maybe a key stakeholder has already stated a desire to see enterprise apps be available on mobile. Whatever the case is, it pays to be aware or seek to be aware of political factors that will help your case that designing for mobile is in the best interest of the success of the product.
More Mobile Examples
The Results
App is now responsive
The product has been successfully developed as responsive experience across all devices. This was, of course, a team effort requiring the buy-in of engineering, product, users and other key stakeholders, but this project proves that a motivated Product Designer can employ strategies to win over other members of the team.
