One of the things you need to give a thought to when preparing the docs is the user data that will show up on your screenshots and in your examples.
A very straightforward and down-to-earth example – the sign-up functionality for a website. Let’s take a very common case like signing up for Twitter.
Here’s what their sign-up form looks like:
You have the good old fields like Name, Email, and Password, and everything looks simple at this point. Let’s do a bit of exaggeration and remove the placeholders and field names (well, not in this particular example, but still). You ask why? A couple of reasons here:
- Placeholders are more about HTML5 (which is still not always the case) and about the web (they’re a rare thing in desktop apps).
- If users have screenshots, they rarely read the field names and look at the sample data instead.
- Placeholders do not tell users a lot about what kind of data is exactly expected in the fields.
So, for users, the sign-up form might actually look something like this:
Houston, we have a problem. I know that I am exaggerating with the UI text here, but if there are chances that the UI is not intuitive enough, your users will need to reach out for the documentation. And this is where it gets tricky.
The good, the bad, and the ugly
Technical writers that are just starting out in the field may sometimes disregard those simple no-rocket-science-involved things like getting the right data for their screenshots and examples.
Usually, there are three cases that we might end up with:
- Empty fields on the screenshots
This kind of screenshot does not provide any value to the users, especially to the ones that tend to follow the screenshots first and read the text only when the screenshots are not enough.
- Filled out screens, but not filled out properly
This screen starts giving a small hint of what is actually expected from the user. The data on the screenshot is a bit of an exaggeration, however, things like +323@vdfv still do not tell me as a user that I need to enter an email in a valid format in here and what the valid format actually means. On a side note, screenshots with such data are just not that ‘handsome’.
- Real-life data on the screenshots
This is the a-ha moment. So you want my name, email, and password. And you have some requirements for the fields. Now, your user can actually go through the steps described in your procedure, even if they follow the screenshots only.
As you can see, the data that shows on your screenshots does matter (and we’re just talking about simple sign-up forms, not the advanced screens that we deal with on a regular basis).
Where to get user data
But how do you come up with the data? The funny thing is that it might take ages to make up something as simple as the user’s name, or to figure out a phone number that would match the user’s country.
So where can we find data that would resemble the real-life one?
My first stop would usually be the Fake Name Generator. Here you can benefit from the following options:
- Name sets (American, Finnish, Japanese, and more)
- User data tailored to the country (you can select from around three dozens of countries)
- Rich user data – you get name, address, date of birth, email, social security number, and a whole lot more
Basically, this is more of an identity generator. Here is what it looks like on the website itself.
For a final touch we might need a user photo. This is where UIFaces comes in – they have a sound directory of photos, all of which were provided by actual people who were graceful enough to give their consent to have their photos used on live websites, not just the mockups.
Even more places to get user data
The resources I mentioned above are not the only ones out there, these are just the ones I use. You can also take a look at the following resources:
- DataFakeGenerator – provides user identity generator, and also includes a password generator that can be tailored to your needs (for example, you can specify password length or the type of characters that should be included in the password).
- Random users generator by Designskilz – includes user profiles with basic data such as name, photo, email, phone, and occupation (the occupations are mostly related to design/coding).
- Random User Generator – I first used the photos they provide (turned out that they have integrated UIFaces), but there is actually a lot more to benefit from. They provide a free open-source API for generating random user data. Might come in handy if you’re doing not only docs, but apps as well.
A level deeper into user data
The last resource made me think about cases when you need something fancier than just data for your screenshots. A yet better decision would be to have realistically looking user data available in the application itself.
This can be achieved with the help of user data generators – but in this case, the ones that have an API or can generate a lot of data in formats like JSON or CSV. The decision to use such resources is not something that Information Developers would usually handle, however, you can always suggest this option to your team (especially to the Quality Assurance team who do a lot of testing and therefore need a lot of data).
So, what are the resources that you can start with?
- Mockaroo – provides the possibility to generate data in a variety of formats including CSV, JSON, SQL, and Excel.
- Generatedata – script that generates the user data for you. Supports the possibility of extending the out-of-the-box script in order to tailor the data to your specific use case.
- Random User Generator – as mentioned above, provides an API that sends JSON, SQL, CSV, or YAML objects that you can incorporate into your application.
- JSON Generator – the name is pretty self-explanatory. Generates user data in the JSON format, also supports JSONP.
What we have in this article is definitely not the end of the list. If you have any useful resources to share, you are more than welcome to share 🙂