Digital media lessons that have withstood the test of time.
This article is inspired by a talk I gave nearly three decades ago in the early days of interactive media. It was February of 1992 and I was leading a team of designers and programmers at a think tank imaginatively named GTE Imagitrek...
Digital media lessons that have withstood the test of time.
This article is inspired by a talk I gave nearly three decades ago, in the early days of interactive media. It was February of 1992 and I was leading a team of designers and programmers at a think tank imaginatively named GTE Imagitrek, in San Diego, CA. We were inventing the tools, processes and delivery mechanisms for some of the earliest examples of interactive media. During that time, I gave a talk at one of the many “New Media” conferences, titled “7 Hard Lessons” (of interactive media). It was meant to be a bit of a manifesto for my team and the industry at large.
I recently came across this presentation and realized the lessons shared still hold up surprisingly well. So, nearly 30 years later, I’m putting into writing an updated version of the verbal presentation that accompanied these slides.
As for the graphics, at least for me, they are a fond reminder of the early days of digital media when Photoshop was so raw it offered very few bells and whistles — no drop shadows, no emboss, no bevel, no reflections, no stroke, no mask layers, no trendy image filters, etc. Effects were done manually by manipulating alpha channels using the built-in alpha channel calculator (add, subtract, multiply, divide) and lots of experimentation to create repeatable FX recipes, or “Chops”1 as we called them.
Please keep all this in perspective as you review these humble graphics!
- 1 Chops: Channel Ops or Channel Operations
The 7 Hard Lessons
Empower UsersThis lesson can be amplified to read, “Empower users to explore your app and don’t penalize them for doing so!”
Empowering Users speaks to the notion that a user should always understand where they are, how they got there, and how to get back. The easier and more obvious you make this, the more likely a user will explore and benefit from all the functionality you have worked so hard to include in your app.
Make it hard, or worse yet make the user feel dumb or cheated, and you have lost them – and likely for good.
Performance CountsNo matter how powerful our devices become, “performance” must never be taken for granted.
Check the performance of your app, early and often, stress-test it with real-world data as opposed to simplistic dev test-set data.
If it’s a website, use GTmetrix or Google’s Page Speed Insight tool to evaluate how well your site performs, especially on mobile devices.
Beware of Creeping FunctionalismCreeping functionalism or “Feature Creep” understandably "creeps" in over a period of time as the team gains a deeper understanding of the potential of the product they are creating. It’s not that these additional ideas are wrong. In fact, more often than not they are right. It’s more about the timing and the notion of shoe-horning these ideas into an existing design, mid-development, that is ill-advised. Much better to complete the sprint or sprints as originally intended, while maintaining a backlog of future improvements.
Creeping functionalism is more likely to happen when you rush to implementation, allowing inadequate time for design iteration and testing. This is why we encourage clients to slow down a bit to iterate over slightly longer rather than shorter periods of time, providing sufficient gestation.
Taking longer doesn’t necessarily mean more expensive. Quite the contrary, it generally will save you money.
I used to say that every dollar spent on design validation will save $4 in development expense. I stopped saying this, however, when several developers challenged my assumption. The consensus is that it’s more like $10 saved in development for every $1 spent prototyping and testing.
Which leads to our next lesson.
Test...Test... Re-test!Frankly, this slide only highlights one aspect of testing – frequent and ample – and completely ignores what goes on in between test sprints: iteration and improvement. The point of testing is to validate your design with users, find bugs and usability cul de sacs and then FIX these issues. Once you do, it’s time to test again.
If I was creating this slide today, I think I’d rewrite it as, “Test… Iterate... Repeat”.
NOTE: 10–25% of your total budget should be spent on design, prototyping, and validation.
When is Good Enough?It has been said that perfection is the enemy of success, and conversely good is the enemy of great. So how do you know when your product is good enough?
Quite simply, your users will tell you.
When your test users start asking when your product will be available and indicating they want to be early adopters, you are definitely onto something.
Learn Your PlatformAt the time I originally created this presentation, we were designing applications for Philips CDi. An obscure technology that was very powerful, and like many technologies that are powerful, it was complicated. I remember asking the lead engineer if I could get a copy of the hardware and software spec for the platform. He chuckled and handed me something similar to a phone book. I took it back to my desk and started reading.
Imagine a display made up two planes on which any one of seven graphics compression formats could be deployed independently, two horizontal lines at a time, each with its own rules, bit depths and horizontal resolutions. Keeping track of everything required detailed schematics of each region for both planes that comprised each and every screen. It was nuts — but oh, so cool!
Because I read the spec and asked a lot of questions, we were able to design and implement functionality that even Philips had only seen crude programmer demos of because nobody else had bothered to use many of these features in their applications.
Today’s hardware platforms include desktop computers (MacOS, Windows, Linux), mobile devices (iOS, Android), embedded systems and the many coding languages and authoring frameworks for each. By learning your platform, you most certainly will uncover powerful functionality that less enterprising designers and developers will overlook.
Beware of CuteMany early interactive media designers were guilty of trying to differentiate their applications by coming up with novel navigation metaphors, forcing users to learn a different navigation interface with every new application. Don’t be afraid to embrace standards or familiar patterns.
With the advent of web design frameworks like Twitter’s Bootstrap and Google’s Material Design, navigation conventions are much more consistent and therefore, more predictable for users today.
Having said that, we still have a long way to go. Whenever I have to acquaint myself with someone else’s microwave I feel completely inadequate. Or, worse yet, try to fire up someone’s home entertainment center to do even the most basic tasks like watch TV, change the channel and adjust the volume. Maddening! If you are fortunate, the considerate host has left instructions or tutored you in how to accomplish these tasks.