Sunday, 4 August 2019

Prototypes - Beginning the Design

Well, we have already explored the context scenario in the previous post on personas, though in part they probably form more the part of the prototypes. In a way what we were doing there was sketching out the functionalities of our application with how each of the personas would use it. In a way it allows our apps to start taking shape. It also helps us keep focused on what we really need to do as opposed to what we would think would be really cool to do. It sort of comes down to that 100 in 1 type of idea in that what one person may really, really want, pretty much everybody else is either not interested in it, or rabidly hates it.

Here we can begin to sketch out the design, or the functionality, of the app. Now, we aren't going for anything too fancy here - that comes later, what we are doing now is just getting an idea of how the app is going to fit together, and how people are going navigate around it. Sort of like a flow diagram.

As we could see from the personas, everybody is going to be using the app in their own special ways, which is why the context scenarios are important. Once we have our ideas on the utilisation of the app, we can then start bringing everything together to see how our app is going to work, and how each to the functionalities are going to relate to the various parts of the app.

Now this is how the process begins to flow. By looking at the context scenarios, we can determine what the user's needs happen to be, whether it be data or functional. In the scenario we had with our stock market app, the data needs might not just be the share price, but also any news that is related to that share, and the various metrics, such as PE/Ratio and Buy/Sell spread that are also attached to it. As for functional needs, well, we might need a way to keep track of our portfolio, and to buy and sell shares when necessary. However, these data and functional needs are going to differ across our persona.

However, before we continue, consider this flow chart below, and it gives a good idea of the development phase.

Scenario-based approach to design Two 
However, one of the important factors here is the user experience, so while we are determining functional and data needs, we should also be focusing on the user experience. Remember, this is one of the key points here - a user that doesn't have a great experience is going to be a user that will end up looking for something else. Sure, if you hold a monopoly on functionality then, well, your users are going to be struggling to find a competitor, but get that idea out of your head - it is unlikely you are going to be in that situation, unless you score a job with Facebook or Youtube.

Now, once we have the context scenario, we can then create a table that gives us an idea of what functionalities are required. Now, I have previously created a key path scenario, which is also quite similar, but the key path scenario tends to flow on from this table.


I'll be honest, and was basically using the Commsec app as a basis for this, since I'm not really all that interested in creating my own app (unless it involves computers using machine learning to understand stock price movements, and buying and selling on my behalf, but unfortunately you can really only buy and sell through a brokerage). 

Now there is what is called the posture. This is basically the feel of the app, and we need to consider the users in this regard. Is it a professional app, a transient app, or a fun app. It's not all that good having a stock trading app that looks as if it belongs in a cartoon, people simply wouldn't take it all that seriously. We also need to consider input methods, particularly when we are dealing with mobile devices. Traditional computers handle inputs through keyboards and mice, however mobile devices have resulted in so many other means of input that we really need to take it into consideration. For instance, facial gestures may actually be a valid form of input.

Functional elements

Now, let us go back to our stock market app and consider what functional elements are required:

Functional Element: View Stock
Include: Name of Stock, Stock Price, News, and Charts

Functional Element: Buy Stock
Include: Purchase price, number of stocks, value to purchase, timed purchase, purchase based on price or volume.

Now, we also need to take into account things like real-estate - that is how much of the screen we have available. You will have a lot more real estate on a desktop than you will have on a handheld device. However, being able to buy and sell stocks on a hand held device may be a lot more convenient that having to wait until you are in front of a computer. We also need to take into account proximity - you know, like buttons next to each other, and also other factors such as what displays are available.

Then there are also the various views, or you could say the screens on which various functions play out. For instance you will have the front page from which you can access other parts of the app. Then you have the stock view, and a part of that might be the chart view. Finally there is the view which enables you to buy, or sell, a stock.

Pen to Paper

Well, now we get to work and start designing our app. Ironically, even some of the most advanced companies still use pen and paper. Honestly, I don't blame them, particularly since it is much quicker to sketch a basic design than it is to muck around on a drawing program in these early stages. Okay, there are some other disadvantages, but it is a start. An example for my app is below:


But I think this one is a much better example:

Source: Martha Eierdanz
These are basically known as 'paper prototypes' and it is here we begin to work out the user experience. As you can see, the example above is much more detailed than my example, but it is here that the creators have gone into more detail. However, my mockup was a basic start that was scribbled in thirty seconds, unlike the example above, which probably took a lot more time.

The thing with paper prototypes is that you can start to see how the app will take place, and if you start to see problems with the usability, you can then start to remodel it here before getting into the really time consuming and tedious parts - the ones you draft on the computer. What it also allows us to do is to experiment with alternate scenarios before we settle on the final design.

Mockups and Fidelity

There are two types of prototypes here - the high fidelity and the low fidelity. The low fidelity is still the basic design where we are looking to filling in some of the gaps in the original paper designs. The high fidelity prototype is much closer to the finished product, however ideally, when you get there you pretty much want to be in the position where you only need to make minor changes as opposed to scrapping the whole project and starting from scratch. High fidelity prototypes are incredibly time consuming to produce, and you really want to move from there to the beta release.

So, there are some pros and cons for both models. The low fidelity tends to be cheaper to develop, enables you to explore multiple avenues, is a useful tool through which to communicate, good for identifying market requirements, and a great way to explore the proof of concept. However, on the flip side, it is difficult for the back end coders to be able to develop the code (this is usually happening concurrently), there is a limited scope for checking errors, the process tends to be driven by the facilitator, there is a limited scope for usability testing, and finally there are navigational and flow limitations (the flow of the app is a very important aspect of the user experience).

With high fidelity prototypes, there is the problem of cost - it is very expensive to develop. However, you have complete functionality, it is predominantly driven by the user, there is a fully implemented navigational system, there is a look and feel of the final production, and can help quite a lot with marketing and sales. Other then cost, there is also the problem of time, and it also doesn't work all that well when you are still at the proof of concept stage.

Now we have the horizontal and vertical prototypes - the horizontal one is where you have a look at the breadth of the functionalities, but don't go too deeply, which the vertical prototype is where you select a single function and explore it in detail. Now, at this stage the aesthetics are of little concern, but we should still have an idea of the look and feel of the app - the look being how it is perceived, and the feel being how it is experienced.

We have already discussed paper prototyping, but as mentioned it is a handy tool. In fact one method is to have a hole cut in a sheet of paper that simulates the screen. One person plays the computer and another plays the user. By pressing parts of the screen, which simulates clicking, the computer moves the screen as necessary. You can also simulate text entry simply by writing something down. However, instead of my explaining it, consider this video exploring how pintrest used paper prototyping:


Doing it on paper isn't the only option, as you now have a number of applications, such as Balsamiq and Azure, which allows you to prototype digitally. Honestly, I still prefer using paper, probably because that no matter how bad my drawing skills are, drawing on a computer is even worse.

And Finally

Look, I did want to mention wire frames, but that is basically what is covered above with the paper prototypes - wire frames are basically very rough sketches of the app. However, there is another process called Storyboarding. Now, this is used in film production, where the film is created on paper using rough sketches based on how it is going to look. It also appears in UX design, namely to visualise the keypath scenarios.

Anyway, I'll leave it at that, and next time we will be usability testing.
Creative Commons License

Prototypes - Beginning the Design by David Alfred Sarkies is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. This license only applies to the text and any image that is within the public domain. Any images or videos that are the subject of copyright are not covered by this license. Use of these images are for illustrative purposes only are are not intended to assert ownership. If you wish to use this work commercially please feel free to contact me

No comments:

Post a Comment