1

We have a web application built and optimized for larger screens (desktops) but now our users are transitioning to mobile devices and so we have decided to have mobile application as well for our users.

We are kinda rebuilding the whole UI coz existing UI is not mobile friendly and we want the mobile app to look more swanky (won't sacrifice on the UX). This will definitely result in different looking web and mobile version of the same application but we will probably do a redesign of desktop view later.

The product flow is quite long and have UI components that are being used repeatedly in a lot of places. Are there any good approaches/frameworks that I can use for this activity?

One approach I am thinking of is to focus on redesigning the components and then reuse those designs at all other pages/screens. E.g. Let's say there are 4 screens that looks similar and have common UI components being used in them. Now instead of redesigning all the 4 screens, I'll only redesign 1 and use it as a template for other 3. Does that make sense? Do you guys see any loopholes that I may be missing?

Thanks in advance for your help :)

Edit: The mobile app is a native android app. We will be planning for iOS version later but planning should be long term so that we can accommodate changes for foreseeable future developments as well.

  • The question is unclear to me too, you say you will design everything from scratch, based on existing domain model and processes. Basically you are building new app. Do you really need suggestions on designing new app or something else? – ADOConnection Jan 23 at 17:57
  • Yes, the app will have to be designed from scratch but the product flow already exists. What my objective is that we do a good job in UI and the interactions involved for those components. The plan is to templatize these items so that designer doesn't waste time in repetitive work. – Janusz01 Jan 24 at 8:19
1

Template Usage

I am not sure what your question about the template usage is. I think you automatically reuse already existing components when designing, so it isn't even a question - of course you should reuse them to work smarter.


"Downgrading"

I think the bigger question here is how to approach a "downgrade" of a complex desktop application into a simpler mobile one.

You can either design a completely new mobile version from scratch and then build a new desktop version on top of that. Or you can break down your current desktop version and re-create it piece by piece for mobile.

Two articles I've found describe these opposing concepts pretty well:

Progressive enhancement:

What it boils down to is that, the smallest of the designs will have only the essential features, so right away you have designed the heart of your UX.

enter image description here

It is the ideology that mobile design, as the hardest, should be done first. Once the mobile design questions are answered, designing for other devices will be easier.


Graceful Degradation:

This incorporates all of the complexities right from the start, then strips them away later for smaller devices.

enter image description here

The problem with graceful degradation is that when you build the all-inclusive design right from the start, the core and supplementary elements merge and become harder to distinguish and separate. The entire philosophy runs the risk of treating mobile design as more of an afterthought since you’re “cutting down” the experience.

Sources:
A Hands-On Guide to Mobile-First Responsive Design
Intelligent UX: Graceful Degradation vs Progressive Enhancement


So it can be derived that the mobile first, or progressive enhancement, is the more useful route to go, rather than the other way around. But that is obviously the harder way in your case.
I think you can find somewhat of a golden middle: Do not completely discard the current desktop version but rather derive the core features and rank them by priority. Then design the mobile version around these features.

| improve this answer | |
  • So the thing is my team doesn't have a full time designer and I have been mostly taking care of that part. Now since the app is a new offering altogether, I wanted a professional touch to the work. I have somehow managed to get a week time bandwidth of a designer from other functions in the org. So yeah, it's a little complicated and I have to prioritize and optimize well. – Janusz01 Jan 24 at 8:18
0

When it comes to the mobile application - or the mobile version - it is initially worth choosing the form and technology.

Whether it will be just the RWD version of the existing platform, a native application (IOS, Android) or non-native (Flutter, Native)

I like your thinking, when it comes to minimizing components and information, due to its repeatability.

The fewer variables, the fewer components - easier management, less complexity.

I think that problems may arise in details - as the logic will most likely be identical and in the context of implementation only a change of style will be required (unless the IOS platform, Android)

Likewise all - 4 screens can appear to be the same - but slightly different - then it may be problematic to determine the differences. There is often a problem that what fits easily on the desktop - it is not necessarily easy to adapt to mobile.

| improve this answer | |
  • 1
    The mobile app is a native android app. We will be planning for iOS version later but planning should be long term so that we can accommodate changes for foreseeable future developments as well. – Janusz01 Jan 23 at 13:20
  • so it's should be - material.io/design – Piotr Żak Jan 23 at 13:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.