A lot goes into the creation of an awesome app. A big part of creating apps is actually understanding the goal the user wants to achieve. However, as you already learnt computers work in a certain way so technical people need to know how to design algorithms and eventually code them. At each stage you will learn that it is so important to test, test and test some more. In this post you will be introduced to Design Thinking because it is a very good and modern approach to solving real world problems.
In Chapter 42, we spoke about the Software Development Life Cycle, the structure used to develop a system. We saw that there are a number of methodologies available, and for your MATSEC exam, you will need to be very familiar with the Waterfall Method, in which a number of steps or phases are done sequentially.
Not all methodologies follow this sequential pattern. Some, like Agile, work in increments, where a prototype goes through cycles of requirements - analysis - design - build - testing - feedback. In each cycle, more is learned from user feedback, and that feeds into the next cycle 'requirements'.
How do we solve problems?
You might be asking, given the different methodologies around, does how we solve a problem change?
Not really.
Whether we are working sequentially or in iterations, there are approaches we can take to a) define problems, b) come up with ideas, c) validate those ideas. A popular framework for this is called 'Design Thinking'.
It naturally fits with the Agile software development methodology, since 'testing' is done frequently and feedback is used to improve the system. Still, we can take a lot from it even if using Waterfall. In this case, it mainly affects:
step 1 requirements gathering and analysis;
step 2 design; and
step 3 coding + testing.
Discovery | Understanding the User behind the problem
Many people think a project starts with a problem but that is not exactly true, a project normally starts with a human (or many human beings for that matter) who needs to reach a single goal! Good examples of goals might be:
to learn a new language;
to buy some groceries;
to spend less time tracking chores;
to cook a Michelin star recipe;
to pass upcoming exams;
and I can go on...
Whenever there is a human with a goal most of the time there is opportunity... an opportunity to make things better!
Maybe there is a better way to learn a new language rather than enrolling in an expensive school.
Maybe there is a better way to pay for your groceries rather than queuing at the till.
Maybe there is a better way to prepare for exams rather than studying by heart.
More often than not there is always an opportunity to do things in a different way that gives our human a benefit. We techies call such opportunities problems... normally a problem is something worrying but in this case problems are good, fun challenges to solve!
Meet John
Take into consideration a customer of a popular fast food restaurant, John, who wants to eat his favourite meal. Normally he has to place his food order at the counter but always feels slightly rushed because there are so many options to choose from. The goal is pretty clear, John wants to eat his meal but is there an opportunity to make the process of placing an order more enjoyable?
Define and Analyse the Problem
Before jumping the gun with a solution we first need to really understand the problem in as much depth as is practical. To explain, we definitely need to be able to understand the problem from our main human point of view who from now on we will refer to as our user.
Build Empathy
Who is John? What does he like and not like? How old is he? What does he need to get his meal? What is currently bothering him about the process? It really helps to visualise our thoughts. We normally build a Persona and then continue with an Empathy Map so that we can put ourselves in the user's shoes.
Frame the Problem
Now that we really got to know John we can shift our focus at identifying the opportunity to help him. I like using a template for this part and filling in the blanks. This helps me focus on addressing the barriers that hopefully are not unique to just John, allowing me to build a solution not just for John but others like him.
I am persona trying to verb but barrier because cause which makes me feel emotional reaction.
I am John, placing an order for my usual large meal but I would like to learn about similar options because I I like trying new products but at the counter this makes me anxious as I know people are queuing behind me and my server is really eager to rush the process.
There are different strategies. Some people start with a very generic user story that needs to be broken down further at later stages. Another template you can use: As a user, I would like to do something, without barrier, so that benefit. As a fast food customer, I would like to place an order for my meal, without feeling anxious about people queuing behind me and feeling rushed into the process, so that I can have the space to learn about other meal options.
At this stage it is a good idea to be upfront about clear constraints if there are any. In the example we are looking at, we cannot change employees' roles, or add more employees in the mix.
How might we...
At this stage we need to think of how we can address the barriers to make it easier for users to reach their goal. Come up with ideas for solutions which would lower barriers and replace negative emotional reactions with positive ones! Sometimes coming up with ideas in the beginning can be difficult. It might be helpful to start the process with a question. We normally start the question with "how might we...". Below is an example.
How might we help John place his order without relying on a human server whilst also giving him the space to learn about ingredients and allergens of newer products if need be, so that he does not need to feel anxious about others waiting for him?
Things to keep in mind for your brain storming session:
Think big at first and gradually start to come down to reality.
No idea is too crazy, coming up with ideas is cheap so come up with as many as you can.
Draw from your experience... are you using apps or games that you think could help?
Then start looking at your ideas and identify the ones that you feel you can learn from first because they are not too much work. See if you recognise ideas that are similar to solutions that exist already.
A good starting point for our example would be to design a menu — should be digital so that he can quickly navigate but can easily be updated. He can place an order himself through an app and pick it up from a designated point or get it served on the table.
Take an Idea to the Design Stage
After you picked an idea that you think balances risk and benefit the best start visualising it in more detail. A good technique would be to build a story board for your idea.
At this stage, without even writing a single line of code yet you have a very high level design that people like your user or non-techie friends can understand. This is powerful because even at such an early stage you can get useful feedback. After that you would want to make a rough plan.
From the above story board I can already tell that I intend to design a self service to place orders at a fast food restaurant. Looking at the boxes I can see three major features to code and prepare granular user stories for: seeing the menu, the scanning of the QR code to create an order session and to let the person pay for the order.
To summarise, from your story board:
Try to get feedback as quickly as possible from your family and friends.
Identify the main features that you would need to test.
For the first feature you are going to work on create some user stories with the acceptance criteria that clearly indicate inputs and outputs. These user stories have two purposes, they will be your coding tasks and they are your test plan!
How to Communicate Your Ideas
One would communicate with a user differently than communicating with other people that would like to be involved like perhaps other coders that would like to pitch into the project.
Story boards, empathy maps are all good communication tools when communicating general ideas to people who do not need to code. However, developers may need to convert complex user stories into pseudocode and flow charts or structure diagrams to commit to a technical design.
Structured diagrams are a very good starting point, so before pseudocode or flowcharts, as it forces you to look into an epic problem and take on a divide and conquer approach. Note the hierarchical nature of the diagram and the different colours we used to help us identify the input parts, output parts and processing parts.
Validate
To validate your solution just carry out the test plan. Get feedback from real users that are testing your prototype. Go back to the framed problem and evaluate whether you addressed the correct barriers. Did you manage to replace the negative emotions with more positive ones? Can the user still reach the goal in the way you proposed? There will be things we missed, it happens to everybody. That is OK! It just means that there might be a bit more work to do in the future!
SEC Coursework Alert 🚨
In order to get your Secondary Education Certificate in Computing, a local qualification, you must complete a project which involves solving a problem for someone, or even yourself! Adopting Agile and Design Thinking is a very good approach for students who are still learning about programming because you do not need to come up with something perfect straight away. It is a slow but steady journey that gives you the space to try, fail, and keep on trying until your project is perfect for submission. Before you sit for your O Level, you must submit a writeup that describes your project. It is worth a maximum of 30 marks. I highly recommend that you use the resources provided. This is all explained in detail in a guest post here.
Comments