I thought I’d pop these notes up here because they’re easy to share and I like the format. These notes are a few tips to help out with anyone doing the second assessment in advanced web design. They also cover a general method for the initial stages of designing a simple tracking app.
The structure for completing A2 is a simple one. Here’s a step by step guide to follow:
- Write the Introduction
- Paper Sketches
- Data Model
- Wireframes
How to write the introduction
“Provide a brief introduction describing your chosen context for the web application, outlining its general purpose, target audience, and goals (~1 page).”
First thing to do for the brief introduction is to reread the design brief. Go line by line and pick out some clues to help you explain your apps purpose, target audience and goals. Explaining these three things is the purpose of your introduction.
In the design brief, the end of the first paragraph gives a clue as to what the goals of any app for this assignment might look like:
“These applications use technology to store and analyse data related to behaviours, habits, performance, and more. By leveraging the power of data, tracking applications can help people make more informed decisions and take actionable steps towards their goals, or just provide useful historic information.”
Can you guess what the goals hinted at might be? I see the goals app as:
1. Track behaviours, habits and performance with user entered data
2. Help the user to break down large aspirations i.e. becoming a great cook or getting fit into smaller actionable tasks
3.Incentivize the user to keep up their training or practice using historical information.
With these clues, the next step is to suit the general goals of the brief to your chosen context. Remember, you don’t have to stick to the provided topics i.e. media consumption, fitness and exercise or food and cooking. If you have another idea that fits the brief, go for it!
Here’s an example so you can see what a specific context, purpose, target audience and goals might look like:
Chosen Context:
This app is designed for beginners in meditation who want to track their progress and stick to a practice schedule.
General Purpose:
Unlike going to the gym, the benefits of meditation are not external. You don’t get bigger muscles from daily mediation. You can however develop emotional resilience, focus and concentration, stress reduction, enhanced self-awareness, increased creativity, better sleep, reduced anxiety, and pain management. This app aims to make tracking that development easier through a series of daily metrics. The app is designed to be used on days when the user meditates and on days that they don’t, asking them to rate how they feel in these daily metrics.
When they do meditate, it asks the user about the method and intention of that particular meditation, providing categories to answer the questions quickly. The user can view historical data and discover what method and practice style work best for them by comparing the methods used with the perceived effect on their metrics.
Target Audience:
Beginners in Meditation who are motivated to practice 10–20 minutes of meditation daily, who want to be accountable to a deadline and are interested in tracking the benefits of meditation.
Goals:
- Get users to commit to a daily meditation practice.
- Incentivise users to return to the app by delighting them when they view their progress
- Provide guidance with particular meditation methods to try out
- Track their meditation schedule
- Ask them questions about how their meditation felt today with self ratings and an optional reflection
You may have noticed that a lot of the information is repeated between these sections of the introduction. That’s because the idea is pretty simple, it’s a meditation tracking app. We repeat the info across our context, purpose, target audience and goals because of reframing.
Reframing is a key part of the design process, it’s a way to break down vague concepts in a problem area into specific bits of information. By coming at the problem from multiple angles, the design and functionality becomes clearer and makes the jump from writing to sketching a smooth transition.
So that’s the introduction done. It should be standard page. Around 250–300 words. You can get a lot of reframing done in 300 words.
How to start the paper sketches
Wireframing begins with an idea. I’ve found the best bang for your buck in the realm of app ideation is a paper based beginnings. You don’t need to get bogged down in software just yet, keep it conceptual as you reread your introduction and start visualising what some of the interaction might look like. If you’re stuck, here are a few questions to kickstart your sketches.
- How does your app fit into someone’s day?
- What do people love about your app?
- If someone was explaining how your app works to a friend, what would they say?
Once you’ve done your paper sketches, you’re ready to move to your data model.
How to write the data model
Using the data model example as a guide, start by writing out the different properties that will go into the core object of your app.
But what are properties? Well, properties in this context are the properties of a Javascript object. So the data model that we’re writing out will reflect the code we write when it’s time to build the app.
For example, in the meditation app example, the object might be something like ‘meditationSession’. I’d need to capture all the stuff that was mentioned in the introduction, plus a few extra specifics that get discovered through the sketching process. That’s why we sketch on paper before we write the data model. It provides a visual guide.
So the meditationSession object might look like this:
meditationSession
> meditationDate
> meditationTime
> meditationDuration
> meditationEffects
>> emotionalRegulation
>> focusAndConcentration
>> stress
>> stressType(postive or negative)
>> selfAwareness
>> creativity
>> sleep
>> painThreshold
Since we’re working with JavaScript objects, we can make categories and sub categories of the object quite easily.
Once we have the properties laid out in pseudo code, filling in the Description, JS Data Type, Example Values and User Input comes next. Lets walk through them briefly.
Description:
The description just explains what the property does, like emotionalRegulation might take a score out of 3, with 0 being no emotional regulation and 3 being strong emotional regulation.
JS Data Types:
String
Number
Boolean
Undefined
Null
Symbol
Object
Array
Function
Date
RegExp
Learn what each of these data types mean and think about what type best suits each property. For example, since I’m using numbers to represent sentiment, I’d choose:
the Number type for the emotionalRegulation property.
Something to keep in mind is the idea of mapping values. Even if I wanted to display this to the user as a dropdown of words, I can still store the property value with words and then map the words to numbers.
Example Values:
Write some values that might appear in your property. In the emotionalRegulation example, the values are numbers for the object property but the user would see something like strings in a dropdown menu. In a mapping case like this, it would be good to include examples of how the string map to numbers to explain the functionality more clearly.
So for the emotionalRegulation regulation example, I could write:
Mapping between numbers and dropdown values for the user.
0 = no emotional regulation
1 = weak emotional regulation
2 = moderate emotional regulation
3 = strong emotional regulation
User Input:
This is how the user interacts with the property. so for this example i’d write something like:
User selects dropdown menu when filling out meditation effects.
Sometimes the property might populate automatically, like the GUID (globally unique identifier) that should be automatically created for every meditationSession object. That’s quite important so I’ll say it again. Make sure to include a GUID. If you don’t know what that is, look it up and learn how to make one. It’s very important for code maintainability when making objects in an app.
In automatic cases like the GUID, the user doesn’t add an input so make sure to include a short description of what triggers the automatic process for that property. For example:
GUID User Input:
No user input required. GUID is created automatically for each meditationSession.
So that’s how you create a data model. When you’ve filled that out for each of your properties, you’re ready for wireframing.
How to Wireframe
Wireframing is how you visualise what you’ll build for assessment 3. High Fidelity Mockups aren’t a part of this assessment so wireframes are the end of the line. This is your opportunity to present what you’ve worked on in your sketches in a way that shows someone else how your app works. Here are some things to keep in mind while you wireframe:
Don’t spend time on colour or images or specific content. When it comes to app design, aesthetics arise from functionality so don’t worry about making it look pretty. If you’re unsure of what wireframe fidelity is required, check out balsamiq. Feel free to use it to build your wireframes or match the fidelity in your preferred design software e.g. figma.
We’re build SPAs (single page applications) so there’s only one ‘page’ that you need to wireframe. However, one page can have multiple views, or include multiple layouts. Don’t feel you need to cram all your functionality onto a single view. Think about how the user will progress through the app and organise your views accordingly. When wireframing, include shots of each view you’re going to build, in both mobile and desktop design. As well as this, include a user flow, which is a flow chart of your views and how a user progresses between the views.
When it comes to mobile and desktop design, don’t worry about finding the perfect width. We just need you to demonstrate that you’ve considered layout across multiple devices.
A note for assessment three:
When it comes to the next assessment however, You’ll need to clearly mention what screen sizes you built in, so we can mark your apps in that size.
Keep in mind that this isn’t launch ready responsive design, since an app should work across all the devices it could be used on, but CSS can be a major timesink for the new web developer. We don’t want you to get bogged down in the little details before you demonstrate all the cool JavaScript you’ve learnt.
Annotate your wireframes with a very short description of how the user interacts with each component. If the component interacts with the data model, include how in your annotation.
Include a design justification for how you’ve built out each view and how structured your user flow. It can be short, but it needs to demonstrate how you’ve linked your wireframes to your purpose, target audience and goals.
I hope this helps in your app building adventure. Go forth into realms unknown and bring your ideas to life!