Mockups — validating my app idea

This is a repost from, originally from 2016

In March this year, the company I worked for closed it’s doors and I found myself looking for a job. I hadn’t updated my CV in the two and a half years I had been working there and I had no clue how to job hunt.

Job hunting is a full time job and like any job it takes some time to master.

What I learned from my user survey

The data from the survey had helped to focus the development of the project. Users wanted an app that helps with creating a CV targeted at meeting the job specification from the application and then helping the user to prepare for the interview.

You can read my post Getting an insight into job hunting to gain a much deeper understanding of the survey responses.

Mock — yeah — ing — yeah — up — yeah

Building a mockup is a liberating experience. Armed with the knowledge of what your user wants you do your best to translate this into a series of screens that make this a reality but you ultimately know you’ll fail the first few times.

This failure is the key to why building a mockup is great. You invest a few days or hours (depends on how many existing assets you have) on it, shove it in front of someone to use, learn on how you completely missed the mark and then tackle that flaw in the original.

By the time you’ve done this a few times you have a really good idea of what works and what doesn’t and better still you discover so much more about the product you are building. A feature I thought was just a simple means to an end has now become the backbone of my entire plan thanks to building my mockups.

One thing to note when building a mock up is to try and ensure that people have a rough idea of what the product will do before they use it as sometimes they struggle to make the jump and get confused when certain parts are not ‘implemented’.

Lost in translation

While the process of showing off mockups and learning from users is great actually getting to that stage in the first place can be a little daunting. If you don’t have an existing design framework or styleguide to work off of then it can seem a like there’s loads of work to do but a simple grid and typographical scale will help get your idea across (which is the point, although places like Dribbble would suggest otherwise).

As mentioned above the important thing to remember is that you won’t get it right the first time, or the second one either so don’t get too bogged down making everything perfect and just experiment while you have the chance before you lock down parts of the app.

Here’s my journey through building the mockups that I used validating the idea(s) around my job hunting app.

Pencil and Paper

Many many mockups

Before I sat down and started making things on the computer I sat down and tried to envision how the app would work. This included rough information architecture diagrams as well as sketches of how certain views would look.

I generated around 40 pages of drawings on the various aspects of the app before I moved onto building these in Sketch and it was worth it. I think there’s this conception that using a computer will make everything easier to do but you really don’t have the ability to just brainstorm when you use a medium that is rigid by design.

Mockup 1

I had decided at an early stage to use Semantic UI for my app as I favoured it’s systematic approach over something like Bootstrap and as I was going to build the app in React I could take advantage of it’s semantic-ui-react library.

There’s a very limited Sketch document they recommend you use as a template but I ended up finding no use from this and instead built a set of components in Sketch from scratch using the examples from the Semantic UI site as guidance.

Building the components in Sketch helped in three ways:

  • I was able to take advantage of Sketch’s feature that allows you to change the text of a component on an instance by instance basis
  • I could bake in a 16px margin of bottom of components which made alignment much easier
  • Restyling components was as simple as creating a new version and selecting ‘Replace With…’

I built the first mockup to centre around what I thought was at the time was what people would want. It was a very literal interpretation of the main themes of the survey which was represented in the feedback I got from it.

Mockup 1 on Marvel


  • People were not aware of the multiple columns of the job hunting board due to no visual clues
  • People were not aware of how to create a CV due to there being too many levels in the navigation
  • The use of save buttons threw off a lot of people; they felt it was too much effort or they were unsure of if entering data and then going back to the board would save it

Mockup 2

Following the feedback from the first mockup I made a few changes:

  • I made sure that the job hunting board was a little more compact but you could see additional columns on the left or right sides
  • I moved CVs and Stories into their own sections so it was a little more apparent on how to edit these
  • I changed the way that CVs are created to be more like a kanban board to make the navigation shallower
  • I added a page at the start to help explain the idea a bit better
  • I removed the save buttons from most pages
  • I removed the breadcrumb navigation
Mockup 2 on Marvel


I was able to solve most of the problems from the first mockup which meant people were now helping to give me a better understanding of what they expected from the product as well as how they felt when first viewing certain screens (such as making things more explanatory).

The feedback I was getting at this stage really helped to reassure me that I was on the right track and I started to realise some important truths about the product that I’m now only starting to look into.

Jumping the gun

After receiving all the feedback on the mockups I was sure that I was ready to move to building a prototype. The architecture I have in plan would allow me to build the React frontend and build the more backend components such as CV generation at a later point.

However, after building a RAD, going through the process of learning how to integrate Redux with PouchDB and essentially rebuilding the app from the ground up due to architectural changes caused by the latter I now see that I’ve jumped the gun.

As I’ve started to componentise the app so I can work on it I’m becoming more and more aware that I’ve yet to iterate over the individual components themselves and have instead validated the overall app idea with the mockups I’ve built.

There’s still a lot of work I need to do to build up the feature set of the components, learn about what the user wants from the components and more importantly I need to give myself that liberation to try new things before locking down ideas.

Next steps

My next steps will be to build mockups that focus on the individual components of the app. These being:

  • The Job Board
  • Story entry
  • CV Creation
  • CV PDF Generation
  • Sign up
  • User Profile

I will then use my findings from the mockups to create the acceptance criteria for the user stories around the app and begin development having got a functional and non-functional testing safety net in place. The feedback will also help to build the product backlog so I can start creating a release plan to incrementally make the app more useful.

Currently building Interested in building shared understanding, Automated Testing, Dev practises, Metal, Chiptune. All views my own.