The following information on this page represents my design thinking and process for the Infusionsoft design challenge.
I always start projects with some type of discovery activity that allows me to gain a better understanding of the jobs the software application needs to support as well as understanding who the audiences are that will be using it. In this case a design brief was supplied.
To help college students stay organized by reminding them of upcoming classes and assignments due.
I'm a busy college student and I sometimes miss classes and homework assignments because I don't get reminders.
The student can easily see how much time remains before the next class, as well as where the class takes place.
The student can see what to-dos are due, as well as add new to-dos.
The student can check off to-dos.
I created a quick user persona based on the provided details in the design brief. The only addition I added beyond what was provided was the image - it is good to put a face to your subjects so that it is easier to have empathy during the design step.
The above project brief provided a good starting point, however I needed more details regarding the various pieces of information that would make up this type of application.
The above diagram represents the data model that I extracted out of the design challenge brief. I almost always map out a rough idea of what the data model looks like so that I can understand what content needs to exist that potentially will be displayed to the user. Using these types of spider diagrams help me visual the parent / child relationships between the various attributes.
The above image represents some initial quick sketches I created to begin to visualize potential design approaches for the different display needs of the application. I knew this application would need to rely heavily on notifications and with that I wanted to establish some type of visual priority levels that the user could quickly notice.
initial main screen sketch
After thinking about some of the different attributes that would need to make up the information being displayed, I started creating some rough sketches to examine how the overall hierarchy should work.
In this next sketch I added some additional details as well as the countdown timer function.
I continued creating new sketches as my thinking expanded beyond the initial day view. The above sketches represent the day view, a detail view of a single class and then an assignment screen.
To add some additional value to an application like this, it made sense to think about how it could be applied to a wearable. The above is a quick sketch to demonstrate the possibility of how the countdown / class timer could potentially work on a watch device.
Overall design pieces
Since I felt I had covered quite a bit with the sketches, I didn't feel the need to do extensive wire framing as well as design. I felt I could move quickly right into design and use higher fidelity screens for prototyping and further testing, when needed.
I leveraged some pre-defined Sketch UI library components as a starting point and began to create all my screens. As a side note, I really enjoy using Sketch as a design tool. I especially like how easy it is to export design elements into assets at different sizes (1x 2x, etc..) very quickly.
Since I created some watch interface sketches I decided I would go ahead and create some quick visual designs to help communicate what the timer color intervals might look like. The first two screens represent the watch display with a swipe to reveal assignments.
Once I created all of the various screens I built a quick prototype to demonstrate the interaction workflow using Invision. I used the screens defined above and created a separate Sketch instance where I could make slight modifications to represent changes to specific screens when there was a need for a slight change.
Once completed I exported all screens into Invision and built the interaction between them. From there I used a Mac app called GIPHY CAPTURE to record the click-through.
Now that some designs have been created, you almost always have questions that need to get answered before your truly good-to-go with a design approach. As I progressed through the different stages of the design, I captured questions that I knew would need to be answered in order to make final decisions. This is where testing comes in. The below list of questions are things that I think would need to be answered and more thinking applied once some tests were performed with perspective users.
How important is displaying the duration of a given class?
How much flexibility should be given to setting different alert prompt variables (for time before class: 1hr, 45min, 30min, 15min + time before assignment is due: 5 days, 3 days, 2 days and 1 day)? More flexibility may require additional color support which in turn somewhat deviates from the effectiveness of the impact of the interval itself.
Should the countdown timer always display on the day view? Should the user be able to hide / show it?
Should the countdown timer exist on the class detail view?
How important is the location map display? Does the user need to see this right away, or is it sufficient to just show building information and have map on detail screen?
Where should the user start? Which screen is more useful, the month view or day / week view?
In the month view - do we need to display some visual identifiers to represent which days have activity without requiring a tap to see details?
From the month view should there be an icon to jump into the day / week view? Currently I have a tap action on the day to move from month calendar to day / week view, however this could create problems that need to be ironed out with viewing activity in the month view.
Is the various tap target areas understandable? Should there be some more visual clues added to help demonstrate what portions in the view are tappable?
Does the "Add Assignment" form need to be able to allow the user to edit / create class data if needed? For the purposes of this design, I decided the Class data would be populated in settings when the app is setup or could be provided in the back-end.