Prototype – Connolly Design

May 25, 2015November 1, 2020

Using realistic data in a design prototype

I mentioned code-based prototypes a few weeks back. Here’s a related observation.

I like to put realistic-looking content into my higher-fidelity prototypes. The main reason for my preference is that, in many cases, a design can’t be effectively evaluated if it doesn’t present realistic data and/or information. You need to see how the design handles the real thing.

When I was at Karos Health, I regularly used the names of jazz musicians to create fake patient data that was used in various design prototypes. I did it for two reasons, the first being my preference for realistic data and/or information.

The second is more subtle: while the names looked realistic, anyone who recognized a name like Miles Davis or Louis Armstrong would realize that what was being shown wasn’t real real patient data. That was an important consideration in health care, where patient privacy is a critical concern. One of my favourite moments came when someone viewing a prototype noticed that a birthday shown for Miles Davis was correct. (In fact, all the birthdays were correct.) The attention to detail made an impression!

May 5, 2015November 1, 2020

Why I write software code as a part of my design work

Now that the whole designers-coding-stuff thing has died down a little (or maybe it hasn’t?), I thought I’d share some thoughts on why I code on my own design projects. There are a couple of main reasons why I engage in this activity.

First, I believe that it’s important for me as a designer to have a solid understanding of the medium for which I’m designing. Being able to code helps me better understand the things that matter to developers on a software product team, and it enables me to communicate more effectively with them.

Second, creating prototypes is a part of the design process for me. Prototypes, in various levels of fidelity, help me think through what the interaction should be for a particular design solution. Obviously prototypes have other uses; they are great for communicating a design to product team members and, of course, they are central in the testing of a product design with users.

There are many tools available for creating product prototypes. As it turns out, though, because I’ve been coding with html/css/js for so many years now, I can actually work fairly quickly to create a code-based prototype that I can iterate on and refine efficiently. I’m able to create realistic interactions and behaviours that are a big challenge with other approaches. I can start with something crude and wireframe-ish and iterate to something more polished. I like to call late-stage, high fidelity, code-based prototypes “real software with fake functionality”! It might be best to avoid ray guns, though…

November 2, 2010November 1, 2020

Marshmallows at Karos Health

Several weeks back I reported on the results of running two editions of the Marshmallow Challenge. Yesterday I tried it out with my colleagues at Karos Health. Three teams completed three towers — a 100% completion rate, a higher rate than at the previous two events that I wrote about. It was good fun, though after facilitating three of these events it would be fun to build something as well.

September 20, 2010October 31, 2020

Marshmallow-centred design

Last week I had the good fortune to facilitate not one, but two Marshmallow Challenge events. Briefly, the Marshmallow Challenge has the deceptively simple goal of building a tower using spaghetti, masking tape, and string, that will hold a marshmallow highest above a table top. Of course the lessons learned and the experience of building the tower, rather than just reading about it, are revealing and meaningful. The two big ones are to question your assumptions and to prototype early and often to learn as much as possible.

The first event, on Thursday, was the September meeting of uxWaterloo. The competition was close, and the teams all had a great time. After declaring a winner, we watched a video of a TED talk about the Marshmallow Challenge. That was really just a starting point for some enlightening discussion about the experience of building towers and about the ideas explored in the video. My favourite moment of the night was the realization that when designing for user experience, the user isn’t a marshmallow that can be plopped on at the end. Tower-builders that take that approach rarely succeed, and a user interface that doesn’t involve users early in the design process will often fail as well.

The second event, on Friday, was at VeloCity residence at the University of Waterloo. Having experienced the uxWaterloo event, I knew that VeloCity should go well, but I was still taken aback by the large number of students and by the enthusiasm and positive energy in the room. The event structure was the same as for the previous night, and the students dived in and seemed to have a great time with the challenge. Needless to say, I had a fine time as well, and enjoyed the conversations immensely. A major bonus for me was that Dan and PJ from tinyHippos were their as well, their young family in tow, to talk about what’s important in building software products at a startup.

Thanks for the invitation, Jesse.

April 13, 2010November 1, 2020

They built a faux iPad and they’re going to use it

Speaking of UI prototyping, have a look at how the folks at Omni approached designing for the iPad without having laid hands on one. Not only did they make great use of paper prototypes, they created a non-functional mockup of an iPad to help get a feel for the interaction on a physical device. This reminds me of Jeff Hawkins, founder of Palm, carrying around a crude wooden prototype of the original Palm Pilot as part of his design research into that product.

UI prototypes help explore, share, and validate a design. Going the extra mile to create a simulation of the device on which a software product will be used undoubtedly contributes to a successful design.

April 12, 2010November 1, 2020

I built a ray gun and I’m going to use it

This month’s approaching UX Group meeting, a UX ‘show and tell’ for artifacts developed in support of creating a user experience, has me thinking about UI prototypes.

Creating UI prototypes is an important part of the design process. Whether built using pen and paper, dedicated prototyping software tools, image-editing software like Adobe Photoshop, or plain old html, a UI prototype makes the design concrete and helps to build a shared understanding of what a product’s user experience will be like.

At one end of the prototyping fidelity scale is a paper prototype, which has the great merits of being inexpensive, easy to create, and eminently disposable.

At the other end of the scale is what I like to call a ray gun. What’s a ray gun? To answer that, I’ll go back to my inspiration for this particular metaphor. One of the first science fiction books that I read when I was young was Tales from the White Hart, a collection of generally humourous short stories by Arthur C. Clarke. I haven’t read it in many years, but I have fond memories of it. (I’m not sure how accurate those memories are, though!)

One of the stories, “Armaments Race”, describes a competition between the makers of rival science fiction television programs to create impressive special effects for weapons. The details of the titular armaments race are quite entertaining as each program’s team unveils increasingly realistic simulations of ray guns. At this point I’ll add a warning for those of you who haven’t yet read “Armaments Race” that the next sentence is a spoiler, albeit one that is crucial to the point of this post! The punch line of the story is, in essence, that an actual functioning ray gun with real destructive power is built in the pursuit of a great simulation.

Metaphorically, then, a ray gun is a UI prototype that crosses a line into a functioning product. I have to admit that I’ve built more than one ray gun as a user experience designer. Depending on who you talk to, that’s either a good or a bad thing.