Here’s the problem. Designing prototypes for clients in Sketch, Photoshop or other tools don’t always show realistic expectations of what the real-world product will represent.
These tools are powerful, helpful and easy to use — for the most part. They allow designers to create beautiful designs for conversation purposes and marketing material. But, they are static. Additionally, mockups are typically designed with data that fit the intended views.
What happens when a product launches and real-world users start to input data. Do the views still work? Do they still represent the visual appeal your design team or yourself intended for them too?
In a recent post, Clay Carpenter, explained how to create a mock database for an AngularJS application.
While this approach works and could solve the problem of designing without real-world data, is there another approach designers can take to quickly spin up a mock database and start playing with real data?
Yes. Let me explain this designer-friendly approach.
What You Need To Do
- Create a new Google Sheet on Google Drive. Make sure the file is available to the public.
- Create an account on Sheetsu.
- With your Google Sheet open, copy and paste the URL into the form field on Sheetsu that says: “Paste Your Google Sheet URL Here”.
Congrats you have now created a mock API that can be integrated into your web project. It’s really that simple.
How Does MBM Use This Service
Most of Made By Munsters’ applications are a combination of a front-end powered by AngularJS, Gulp and Sass and a backend API created in Ruby on Rails.
For us, using a service similar to Sheetsu, allows us to mimic our current development flow.
- Create a model to store information in the backend.
- Write a service on the front-end to return the information.
- Display the content in the view.
The only difference in this flow when prototyping with our mock database, we wait to create the backend models until we feel comfortable with the data we are returning from Sheetsu.
This process allows the designers at Made By Munsters to create front-end prototypes that both receive and push data. It allows our clients to get a better sense of what their product will feel like in the browser.
It also allows our designers to work with data that does not conform to their pixel-perfect designs. In an ideal world, users would understand our vision and conform to the design. They would edit content when it overflows boxes, they would always capitalize their name when signing up for the application and provide a square avatar.
Sadly, we can’t always control these factors. We don’t always know what users will do when they sign up.
However, creating a playground with a mock database allows us designers to test edge cases, find what happens to our navigation when a user’s email contains their first, middle and last name.
Instead of having to produce three or four static mockups for these fringe cases, we can test solutions in the browser.
If you haven’t tried this method give it a try. If you have, let me know what you think of it.