Creating Demo Accounts for Web Apps: Learnings from My Two Last Projects

Intro

I recently built two projects to learn new skills and bolster my portfolio, both of which include Demo User accounts.

The first project, pause.app is a journaling app to help people keep track of their self-care activities and to-dos. It was a week-long group project built with 3 other developers using the MERN stack and JWT Authentication.

The second was red ink, a platform for connecting writers and editors with specific subject-matter expertise. It was built in 10-days with TypeScript, React, Node and Google Cloud Firestore, and Firebase Authentication.

In this blog I cover:

• why demo accounts were necessary for these apps
• the initial requirements for the demo accounts
• challenges that arose during the development process for pause.app and how we tackled them
• what I'll do differently next time based on learnings from red ink

Why Demo Accounts?

Both of these apps are portfolio projects, so requiring someone to create an account in order to see the full functionality is a bad idea. A portfolio is designed to showcase your best work, so introducing friction between your portfolio site's visitors and your apps' coolest features makes it more likely for someone to leave your app before getting to see your best work.

Requirements for the Demo Accounts

The core requirements for the demo accounts of both pause.app and red ink were the same:

1) Demo Users can access all of the same features as a normal user, given that neither app has any paid features yet.


1) Demo Users must have sample data seeded for them for each demo so that they can get an idea of what typical user data looks like without having to create it all themselves.


3) Demo Users will not be able to see data created during previous demos.


4) Accounts can be created with one click.

In order to fulfill all of these requirements, my pause.app teammates and I came up with an initial solution outlined in the diagram below ⬇️

pause.app Challenges

Our original design assumed that it would be O.K. for each demo user to use the same account. This was a naive assumption, and could lead to problems in the event that two people tried to log in to the demo at once. Once we realized this we made a few changes to our design ⬇️

In our new design, each user gets their own account, and each new demo account is seeded with the same data. This ensures that each Demo User will have the same experience, and won't be able to edit anyone else's data.

Thankfully we realized the flaw in our initial design early on, and were able to change our plan before tying together the frontend and backend.

red ink Challenges

Given that pause.app is a journaling app designed for solo use, and red ink is a platform to connect two different types of users, creating Demo Accounts for red ink presented its own unique set of challenges.

A core feature of red ink is that both Writers and Editors receive email notifications when certain events occur in the app. Writers receive notifications when an Editor has finished making edits on the writing they submitted, and Editors receive emails when Writers submit a piece of writing to them, and also when a Writer presses the "remind" button for a given assignment.

Given that Writers receive fewer email notifications, I decided to make the Demo User a Writer account, as that will allow for a Demo User to experience a higher percentage of the app's functionality than if the Demo User were an Editor.

I also had to ensure that Demo Users are not able to actually trigger emails to Editors on the platform so that Editors aren't flooded with emails asking them to Edit documents sent from Demo accounts. This change was simple, requiring only a few extra lines of code for some conditional logic on the server so that the function that sends emails to editors is never called if the Writer submitting a document is a Demo account.

After seeing how simple it was to alter the Demo User's capabilities without changing the experience they see on the frontend, I realized that I can use some more simple conditional logic to clean up my database the next time I create Demo Accounts or if I spend time refactoring the backend of either of these two apps.

For both pause.app and red ink, when new demo data gets seeded, it is stored in the same table / collection as normal user data. This works fine from the user's perspective, but results in records getting added to the database that are identical apart from the timestamp assigned to them. This can make analyzing user data more difficult, as it adds the extra step of having to cut out all of the demo data from the database before being able to analyze the actual user data.

Going forward, I'll make a separate collection/table for demo user data so that to avoid this issue.

Conclusion

Creating Demo Users presents unique challenges for every single app, and there are a lot of approaches one can take to create a rich demo experience for users. It's important to spend time thinking through your desired demo experience before starting to code, and it's also important to think about what may happen if your app is successful in attracting users and you end up having a lot of demo and real user data to deal with.

If you're considering creating a demo experience for your app, I hope this blog helps in some way! If you have any questions or suggestions on how to create better demo experiences, please reach out via Twitter or through my personal site.