Category Archives: Design

Fighting Friedman

Many years ago, Thomas Friedman wrote a book with the (paraphrased) title, “The World Is Flat.” He has since written other books with similar themes (and titles), each generally well-received.

It seems that in some corners, designers have jumped on the bandwagon as well, embracing flat design for everything from web pages to apps to print pieces. Perhaps it’s a pendulum shift from the previous tendency toward skeumorphism, but whatever the cause, it’s everywhere. Even Apple is doing it for the newest version of iOS!

Now I’m no design Luddite, and I’m all for the evolution of design paradigms. But as with most pendulum swings, I think when we get too far to one side or the other, we lose something. In the case of flat design, I think it’s intuitive affordances.

Although the concept of affordances predates his work by over a decade, I can’t help but associate the idea with Don Norman. His book, “The Design of Everyday Things,” was (and remains) a seminal work on how to design for the benefit of the user and not the designer’s ego. The notion of affordances is that you should be able to intuit, by looking (or touching, in the case of tangibles), how and where to use an object.

In the case of an app, for instance, you should be able to tell what’s a button and what’s not; what’s being updated and what’s not; what’s editable and what’s not. But with flat design, you often lose the intuitive features that tell you where to tap and what is happening. You can be thrown back into the old trope of having to put “Tap to start” on the page or some other such instruction.

You shouldn’t NEED that kind of instruction. It should be obvious. But by flattening everything, a key method of providing that data is gone. As an alternative, perhaps a more hybrid approach makes sense, adding some hints here and there or some visual cues that bring just a modicum of depth back to the interface.

Because even though the world may be flat (according to Friedman), that doesn’t mean the world’s interfaces need to be.

Retro Tech: Beagle Bros

Back when I was trying to figure out this whole technology stuff, The Great Migration happened. For me, that was the migration from a mainframe you had to drive (or, in my case, take the bus) to see and use to a computer you could just go to your room to use. And my first computer (before the TI, before the CoCo, before the C64, before all the rest) was an Apple ][.

Now this is not the time to rhapsodize nostalgic for the Apple ][ per se. But the environment around that computer encouraged hobbyists, students — and it encouraged fun. And one of the leading fun-makers was a software company called Beagle Bros.

They were weird. They were fun. They were whimsical. They’d put code snippets or bits of hexadecimal in their ads that would reveal funny lines, or a previously unknown feature in the computer’s code. Their whole purpose seemed like it was to enable hobbyists to dig ever deeper into the machine and get ever more out.

Take, for instance, their Apple Mechanic software. With it, I could create my own shape tables to use in my little hobby games. I could make ‘em look like they were professionally done. And this was in 1982!

Who else (before Clarus the dogcow) could teach you how to make your computer moo? (CALL 985, by the way.) Who else released so much professional software that was unprotected with code listings available, so you could see how it was done and try it yourself? Who else ran their own comic strip in their catalogs?

And perhaps most tellingly, who else had a software company (now gone) that inspired its own online museum? There aren’t many. And few had as much an impact on an entire generation of today’s programmers.

Perhaps it’s nostalgia, but Beagle Bros was ahead of its time in creating and putting forth a culture that engaged its customers (contests, for instance), respected them (no copy-protection, just a request not to pirate), and supported them (the PEEKs & POKEs poster alone was huge support). Many a company today could take a page from their playbook.

When Is It Done?

When you’re working on a development project for a client, it’s often pretty easy to figure out when you’re all done with it.

After all, you did a requirements document before you started, right? So you know you’re done when the requirements are all met, and the client is happy. Easy peasy.

But on a design project, it’s not always so easy. There’s always something more you could tweak. One more adjustment to that logo, one more look at the spacing on that text. Where does it all end?

Well, on projects where we work by the hour, we usually apply what we call the 90-10 rule. If the last 10% of minor fiddling is going to take lots of time and be virtually invisible to the client, we stop at 90%. Then, when we show options to the client for feedback, we review what additional things we could do (and how much time they’d take). That way, the decision is the client’s.

But on projects where we have a flat fee, it’s a little tougher. At some point, there’s a diminishing return, but when you’re immersed in a project, it can be difficult to see it. So as designs are nearing the end stages (before getting final client sign-off), we do an internal review, and have a discussion about what’s where, and what could still be done, and figure out if it makes any sense.

These discussions are often spirited, and also often lead to great design outcomes. We do it on the dev side, too, but usually earlier in the product cycle.

It can be difficult when you’re head is down on a project to see that you’re done. That’s why we rely on others to help.

Working With Style Guides

We work with clients big and small, so we run the gamut when it comes to design constraints. Sometimes, the client wants to start from scratch and gives us just a few parameters, while other times, we’re just making some minor changes to an already-established brand.

Somewhere in the middle is where we often find ourselves dealing with a style guide. This is a document from the client that outlines (in varying levels of detail) how their brand is represented across all media. Often, it has things like when and where to use the corporate logo(s), official colors, fonts, and that sort of thing.

We are used to working within these bounds, so that’s not a problem. But sometimes, the style guide can go just a little too far.

For instance, we worked with a client at one point whose guide specified the minimum size of the logo for display on the web at around 500 x 300 pixels, and that it had to remain on screen at all times. Think about this in a mobile perspective — that would take up most of a phone screen, and if it has to be onscreen always, then the content is doled out in 5-word increments!

It was clear in that example that the company hadn’t thought very clearly about the different devices and media that might be in play. Conversely, the reverse can happen as well — where the style guide is so vague that you’re not sure if you’re following the rules until you discover later that you’ve broken them.

Sometimes, we find ourselves in the position of creating these guides for clients, and while that can be tricky, it’s a useful reminder of the challenges involved.

What we’ve found is that even when a style guide is clear, it’s no substitute for good and open communication with the client. Sometimes what’s written isn’t what’s in practice, and it’s always good to get the straight skinny.