A look into the web app design process: an interview with Jacky Chung

How does web app design differ from designing for a website?

Web apps are websites 2.0. In the past, you visited websites to download an application (EXE of DMG files) that you installed on your computer. Now the website is the app, and rather than installing a file; you click a sign-up button.

However, there is still very much a split between websites and web apps. If I were to use a physical analogy of television, then today the websites feel like the packaging with the pretty branding, information about the tv specs on the back of the box, and instruction manuals. In contrast, the web app is the TV device itself, which you use to watch content daily.

Since websites have a more standardized format and purpose, nowadays, there are a plethora of website builders that can allow you to have a live website up and running in minutes. Whereas web apps are more unique and require much more effort to build (which used to be the case with websites too).

You can also be a lot less precious when designing a website. It’s easy to change the design of one page without it affecting others, which allows you to be a lot more experimental. Whereas everything in a web app is much more integrated, there’s a lot of logic built-in that can make seemingly simple design changes much harder.

What are the main challenges in web app design?

There are so many browsers available today, and they all handle things a little differently. So when making design decisions, you sometimes encounter problems specific to a browser. For example, a certain media format not being supported on Safari, scrollbars appearing differently in Microsoft Edge, etc. And that’s just for desktops! Mobile adds another dimension on top of this.

Since you can open a web app in any browser, you have to consider how it works on desktop and mobile. This can be costly when designing products, especially early on. And more often, you need to make a tradeoff and only focus on one of them. For example, I often use web apps on my desktop that have completely broken UI when opened on my mobile. As a designer, I understand why. It’s usually down to resources, time, and business priorities, but allowing users to encounter broken UI like this always pains me as a designer.

Web apps are powerful and create a lot of possibilities for what you can do in a browser across platforms. But someone needs to consider all of these different cases, which have definitely increased the demands on designers and engineers.

How can teams prototype for web app design?

Prototyping has come a long way. In the past, everyone I knew used Invision, but now there are so many options to choose from. I use Figma for prototyping because it has come a long way and does most of what I need, which means I don’t need to move stuff between different apps.

There are two essential aspects to prototyping for me. The first is to emulate the “feeling” of using a new feature in the real app as much as possible. For example, how it feels when you hover over a button, and how the page transitions from one state to another. The second is to achieve this first aspect as fast as possible.

There are some really powerful prototyping tools out there where you can spend a lot of time fine-tuning detailed interactions. Still, in my opinion, if I’m going to spend my time fine-tuning these things in a prototype, I might as well spend the time doing it in the app itself. It’s more important for the prototype to show the “design intent” than to be as life-like as possible. But if you can have a prototype that behaves just like the real thing without spending much time creating it? That’s the dream.

How does the team at Bird iterate for web app design?

At Bird, we use Figma prototypes heavily in our design development process. We review all our designs via life-like prototypes. We’ve developed a component setup that makes it super quick to create them. Especially with Figma’s launch of interactive components, our prototypes behave even more like the real thing. It does this to the point where some of our developers thought the app was broken, only to realize they were looking at a Figma prototype that had previously been left open in a different tab. Reviewing designs in a way that’s as close as possible to the real thing allows you to uncover more issues at the design stage, making them much cheaper and faster to fix than discovering them at the code development stage.

Of course, life-like prototypes also unlock a more immersive way to test designs with users. In the past, prototypes had to follow relatively fixed linear paths, like a PowerPoint presentation, so the experiences were restrictive when you handed a prototype to a user. Whereas prototypes today can be built with a lot of logic and flows that mirror the real web app. So during testing, you can literally give the user a prototype, let them click around, and observe to see what they do or where they get stuck as if you’ve handed them (almost) the real product - before you write any code, that’s amazing.

Wrapping up

So, what does this mean for you as you design your next web app? For your team to improve your iterative process? First and foremost, it’s important to remember that a website is not the same thing as a web app. Websites are standardized and relatively easy to create. But, at the same time, web apps require a lot of logic built-in that can make seemingly simple design changes much harder.

Secondly, when designing your web app, be sure to take advantage of modern tools to make the process easier. Your team can then focus on creating an integrated experience that meets the needs of your users. What tips do you have for designing better web apps? Please share them with us on Twitter.