Meeting with a customer for the first time can be a nerve wracking prospect, but if you know what to expect you’ll soon realize that this is one of the easier parts of your project. In my opinion the second meeting is the more difficult since you must show the customer what progress you have made towards implementing their project such as with a prototype, whereas in the first the main thing you have to do is listen to the customer express what they want. Because of this, it is imperative that your software development team works effectively in the time between the first and second meetings, to create a prototype.
The first step to creating a prototype is to identify the requirements for the minimal viable product. User stories are one of the easiest and most effective ways of identifying the requirements that need to be implemented in a software system. While expressing requirements as business goals or usage scenarios may be helpful for some, user stories allow the development team to relate better with those that will be using the system. A user story can be divided into three distinct parts, the first is the ‘As a..’ part which serves to identify who the user is, next there is the ‘I want to…’ part which is used to identify the interaction the user will have with the system, and finally there is the ‘so that…’ part which is used to explain why the user will want this functionality included in the system.
Currently I’m working on a project involving overlaying ancient maps of cities over current ones through leaflet.js, with historical site markers from a google fusion table being present on the layered maps. One of the user stories we came up with is, “As a medieval studies scholar, I want to add a new city to the data, so that I can explore it like the existing ones.” After coming up with this requirement my team thought about how this would be represented in a prototype. We determined this could be accomplished with a button that would take 4 inputs from the user, the city name, the GPS coordinates of the modern map, the old map file which would then be altered by the mapwarper program, and the name of the fusion table to be created or opened, which would store the historical markers data.
Below is a link for further information on user stories:
http://it-ebooks.info/book/3815/
After creating all the user stories, we could think of we worked on representing the requirements in a prototype. There are multiple formats to use for a prototype, a prototype can be as simple as using pen and paper. As an example I have included my prototype for my overlaying maps prototype created in Moqups. As well as a further reading on prototypes.
https://uxmag.com/articles/what-a-prototype-is-and-is-not
Once your prototype is created you can then present this in your second client meeting, and based off their commentary on the prototype you can start work on the first working iteration of your product to show at the next customer meeting. From there you can go from meeting to meeting until you feel the product has met the client’s desires as well as implementing bonus features that go above and beyond the minimum viable product if you have time.
