In previous lessons we developed the User stories and documented the functional and non-functional requirements of the system. Both of these artefacts are key inputs into the UI design phase of the SDLC.
Let's imagine we are developing a system for recording apprentice off the job time. Our requirements may look as follows.
| Id | Priority | Description |
|---|---|---|
| F1 | MUST | Apprentices need to record their off the job training (OTJ) hours |
| F2 | MUST | Apprentices need to record the OTJ Date |
| F3 | MUST | Apprentices need to declare the activity took place during work hours |
| F4 | MUST | Apprentices need to select a category for the activity they are recording |
| F5 | MUST | Apprentices need to describe the activity in words |
| F6 | BONUS | Apprentices can access and use default values |
| Id | Priority | Description |
|---|---|---|
| NF1 | MUST | Apprentices need to record their off the job training easily |
| NF2 | BONUS | Apprentices should be motivated to update their OJT |
| NF3 | BONUS | Apprentices can complete their OJT quickly |
We now want to translate these requirements (and associated User stories) into a UI design.
The place to start is asking the question of yourself...
What are the inputs to this UI component?
What are the outputs of this UI component?
Once you have the inputs and outputs you can think about the human computer interaction (HCI) and the 10 heuristics. For example if we need to collect a date, which of the 10 heuristics should we consider? Consistency and Standards? Could we consider Systems and Status. Presenting a date input field that was populated with today's date might be a good start? Are their constraints that would help the users? Guide rails; like not picking a date in the future.
You can start to experiment with possible arrangements of the different input fields. One of the non-functional requirements is this data should be quick and easy to collect. So I'm thinking maybe the "submit" action is also the declaration that this activity was performed in work hours?
Start in a lose way sketching out different options. Keep referring back to the 10 heuristics. Try lots of different ideas.
From this jam session I like the twisting clock idea, like you'd twist an egg timer to collect a time in hours, but its a bit unusual interaction and people may not know how to use it. I like the chatbot style interaction where the OJT widget is a series of questions. The apprentice only needs to think about 1 thing at a time.
I think this exemplifies the heuristic of Aesthetic and Minimalist Design Interfaces should not contain information which is irrelevant or rarely needed. Some how I think just answering 1 question looks less time consuming than seeing all the inputs all at once. I would also need to show progress through the questions so I'm communicating Visibility of System Status in my design.
I might develop this idea a bit further. In my next prototype I am getting more interested in the details of the interface. What buttons do I need? Where will they go? How will I communicate Visibility of System Status? At this stage I am not concerned with look and feel. I just want to block out the controls and components.
Now you can turn to your prototyping tool of choice. I have done these on "Sketch" for Mac.
Each box represents the different state of the same component as users enter the different data points we need to fullfil the functional requirements. I'm using the row of little circles at the bottom of the component to indicate to the user where they are in the series of inputs, can you recall which heuristic that is honouring? I learn a few things from putting this together. With the slider for hours I might just flash up on the screen the current hour that is selected.
That feels cleaner to me. Wireframes are great because I can easily iterate and try different things out till I'm happy.
What is it actually going to look like? What colours, fonts etc? How about the true scale of the elements, that needs refining. It's worth working up better mocks to closely resemble what we will finally put in front of users, and have designs that are ready to hand to the developers to actually write the code for our OJT component.
It's really helpful to see the new component in the context of the page among the other components. Our high fidelity mock really helps with that. Can you see the other alterations to the design that I ended up making?
With the high fidelity mockups I can really communicate my idea clearly to stakeholders and other members of the team. I also get to check that my design really will work before spending time on the coding side of things.
Can you produce these 3 kinds of UI prototyping artifacts?