FE Development Good Practices: Design and develop with pseudo-real content

Web and mobile app frontends are where users experience the services of your app. While apps’ backends undertake the heavy lifting of running business logic, the front end acts as a medium through which users use or interact with it. And it’s important that the front end be able to offer elegant hospitality to users consuming app services.

We have decided to write a series of blog articles out of our experience in developing numerous FEs(front end) to date explaining practices we follow at Tarkashilpa. These practices are time-tested by numerous happy users experiencing them every day. This article is part of this series.

Popularly accepted practice in frontend and app development is to first design the UI in prototyping tools like Figma or XD or in the form of a series of jpeg images. Once designs are ready then development is started on FE. And it is often observed that FE looks wonderful in design but looks way different when it is developed. While designs are just models of actual apps the difference between actual and model should be kept to a minimum. In this article, we will talk about bridging that gap.

General content development practice

Generally, the practice that designers follow while designing the frontend of an app involves referring to similar or competing apps in the space and understanding their design. Then they begin to design the frontend directly, with inputs from competitors' apps. While it’s a good idea to refer to competitors and get inspired, no two businesses are the same and the app might differ from the competition in size, scale, or features. It's necessary to clearly understand and define content structure before starting to design. Designing frontends without understanding the content structure might lead to frontends that look great during the design phase but fails to meet expectations when developed when the real data starts flowing in.

Suggested practice 1: Define the content structure before building the frontend

A business analyst on the project or another appropriate person should design the structure of your content with its limits. For example, if you are building an app similar to Justdial, the FE Or app would serve the content of businesses. It’s important to define the details we are going to capture for each business and what type of content to expect for each detail. Say you are capturing the name of the business, it would be text and its length should be max. 100 characters. Again if you are capturing photos of shops and business establishments, limits should be defined in terms of max. the number of images, min and max dimensions of these images, and max size of each image that the app should allow.

Though this activity might sound like an extra overhead at the beginning, it has long-term benefits that enable developers to draft a much more relevant design for the front end or app.

Suggested practice 2: Invest in generating pseudo-real content for the app

Another bad practice in designing or developing apps is using dummy content. Again designing the front end with dummy content might make it look stunning in the design phase but the front end or app with real data might appear drastically different. Moreover dummy content might lead designers or developers to miss necessary corner condition handling. For example, in the Justdial-like app, we mentioned above, the dummy content for business description was used the same for all the businesses. However real business description content varies a lot in length and formatting. Since the designer or developer uses the same dummy content for each business, corner conditions like too long content or content of different formatting that cannot be rendered correctly tend to be missed.

So it’s important that designs are made with content similar to the real (pseudo-real) content. This pseudo-real content should cover all variations of the content possible so that designer gets an opportunity to test their designs against real content and handle corner cases. For example in our Justdial-like app, pseudo-real content for businesses should contain business with a lot of images as well as with only one image. It should also contain businesses with long-length descriptions as well as with very short-length content.

This practice is a must-do and very powerful way to build resilient frontends ready for real data with corner conditions handled flawlessly.