Page 1

Hello class. This week’s topic is a continuation of our exploration of some approaches to prototyping in the design cycle, and will also mention some tools that can be used when moving from strictly low-fidelity to early medium-fidelity work.

Please pause to read or ponder slide details as needed.

Page 2

To recap some material from earlier classroom time, let’s review the early part of a good software engineering lifecycle. This is what should happen before “real” code, even for solid medium-fidelity prototypes, starts being written.

The design team should be working to find out what user needs are not being met and could or should be met through the new product or product update.This should involve thinking carefully about who the users will be, what their tasks will be, generating realistic task scenarios, and having them verified by example users.

Once you have a solid foundation of user and task analysis, these should inform the designs that then lead to prototypes for example users to try out.

Ideally, you start with a low-fidelity prototype and then move into different levels of medium-fidelity before locking in on a theoretically final specification. I say theoretically because in reality, even a solid user and task informed spec might need to be iterated during production code implementation.

The good thing is aiming to have that final spec be as solid a foundation as reasonably possible.

Page 3

Referring back to our “Design and Prototyping with Users“ slide deck and class discussions and activities, please pause to review the list here, and refer back to the earlier slide deck to refresh your memory as needed.

Welcome back. Among the reasons we use these are the speed with which they can be built relative to writing code, the associated lower costs of doing so, the lower threshold of attachment software developers might have to the prototypes, and the freedom our non-programmer design partners have to suggest and contribute changes.

Page 4

On this slide is a simple storyboard that I created to think through an idea for a selfie app that would use the front and back cameras of a smartphone to create a sort of virtual postcard that would allow the user to photograph where they were without their face blocking a bunch of it, and yet still have a record of themselves being there.

While for a number of reasons, the final product would have been different in it’s final output, this storyboard was useful in sharing the concept with others and getting a discussion going that further refined the ideas represented.

Sadly, the ability to have both front and back cameras active at the same time is highly dependent on the phone model, so the project has been temporarilyshelved.

Page 5

Here’s another type of storyboard, this time for an app that would use geometry to measure a tall building in an attempt to get kids interested in learning geometry.

From showing these to some children and trying to have them iterate the idea with me, what I found was they saw it as a transparent attempt to trick them into learning math.

Oh well… At least I saved myself a lot of Android coding and working on math equations and formulas, which actually demonstrates part of the motivation behind low-fidelity approaches early on in the design process

Page 6

In medium-fidelity prototyping we want much more realism, but even at a low-fidelity level we might aim for a touch of realism, such as with phone size or using simple art supplies to create a pseudo-realistic frame in which our low-fidelity screens can live.

Please visit the Wii U Gamepad prototype article to see an example from industry.

Page 7

At certain stages, we move from strictly low-fidelity prototyping to hybrid approaches that will take a little more time and cost but will add realism that can be useful to refine ideas some more.

Some of these can get quite involved, and yet still be faster and more flexible than coded prototypes.

Please pause to visit the URL shown and watch the video there. Be aware that there will be a loud sound around 4 minutes into it.

Welcome back. This playtending through mock-up is more extensive than what you will be doing in your Team Project this semester, though there are elements that I was going to ask you to do in class back when we would have had in-class presentations.

The paperclip-based game play would have gone beyond what I would have requested even in class, but this level of playtending can be very useful both in pitching a product internally and in getting customer reactions.

Page 8

An interesting playtending example is how Jeff Hawkins refined the design of the PalmPilot, which revolutionized the approach to mobile devices, by walking around with a block of wood that he refined in shape and size, and printed screen mock-ups for to pretend to use for note-taking, meeting scheduling, and other things he felt could be common tasks on such a device.

I’m pretty sure the stylus was a chopstick, but through its use he worked on how to incorporate a simple holder for it to fit into the device.

8

Page 9

There are many levels of medium-fidelity approaches that still have lower costs but can add a sense of reality to prototyping. Again, that can be important for useful feedback once a strong foundation is developed through low-fidelity explorations.

I’ll cover several of them here, and Phase 4 would have utilized some of these in depth had we not lost time and in-person meetings this semester.

9

Page 10

A variety of digital tools exist to support interactive prototypes that are still relatively simple in terms of programming.

We might use Invision in Phase 4, which will allow you to “connect” screen drawings by setting up virtual hotspots on one drawing that when tapped will take you to a different drawing.

Some tools have some basic logical flowchart programming supported to make the interactions look and feel more realistic. One such tool is Mockplus, which we might have used in Phase 4 normally.

Another candidate was Adobe XD since you all had experience with that in HDCC105.

Page 11

11

As you are considering the development of radical new technologies to support a product idea, you might first want to confirm the product will be wanted by customers.

A technique known as Wizard-of-Oz has the example users think things are really autonomous, even though a human or set of humans are really providing the hidden backend logic or infrastructure.

In addition to the examples for you to read on this slide, this approach which used to simply be called an experimenter-in-the-loop technique, was used to explore the usability of real-time natural language processing systems back in the 1970s before such software actually existed.

Page 12

Wizard-of-Oz moves us past the point of cheap and simple in many ways, and into a family of medium-fidelity approaches that can provide realism, that is still cheaper to prepare than production-level software even though it is a non-trivial investment.

In a course for computer science majors, more realistic medium-fidelityapproaches listed on this slide, other than Wizard-of-Oz, is typically a prototyping level that is used extensively after a low-fidelity round.

Page 13

Whatever the fidelity level, you need to consider how wide and how deep your prototype will explore things.

It is very common to start with a focus on the horizontal or surface layers of how things would look as you launch an app or website, without much exploration into full tasks.

Page 14

However, having a few vertical drops showing how full task scenarios can play out is very useful.

You tend to start with a small number of these that represent task scenarios that will reveal common design elements and then build up from there.

In medium-fidelity you aim to have far more vertical drops, getting close to having every feature cluster represented.

Page 15

15

One important thing to note as we wrap up this topic is that as you move into medium-fidelity the reality comes with hazards of which we should be aware.

Since we won’t be getting too far into that I’ve listed a few here.

In general, every level of prototyping has pros and cons, and the challenge is how to face them and make the most of the pros while being sure not to be unaware of, and then surprised by, the potential cons.

One of the biggest from a practical level is that as soon as you start having coding, you lose flexibility if the user does unexpected things or if you missed a bug during your own testing of your code.

In your team project, you will be focusing on low-fidelity explorations through Phase 3. We’ll play Phase 4 and the medium-fidelity by ear, but will likely stop with Invision where there isn’t a high chance of coding bugs.