Category Archives: Design

On recent Mercedes-Benz dashboard designs

Mercedes (is it ok if I call you MB?), I think we need to talk. You’re doing great in Formula 1, congratulations on that! That said, you’ve gone in a weird direction with your passenger car dashboards. I suspect there are five different teams competing to win with these dashboards and I don’t think anyone, especially this car enthusiast, is winning overall.

Here’s your current entry-level SUV, the GLA. If my eye is correct, this is one of your more dated dash designs:

All the buttons!
All the buttons!

Back in the day, I think, you had someone on staff at MB whose primary job was to make sure your dashboards had at least 25 buttons on them. This was probably a challenging job before the advent of the in-car cellular phone. However, once those became common, that was 12 easy buttons if you just throw a dial pad onto the dash. And you did!

So it’s easy to identify this as an older design from the dozens (43) of buttons. But the age of this design also shows from the LCD. One, it’s somewhat small. Two, and more glaringly, you simply tacked the LCD onto the dashboard. What happened here? Did you run out of time?

I think you can do better. The eyeball vents are nice though!

Now let’s look at a slightly more modern, and much further upscale, design. Your AMG GT coupe:

All the suede
All the suede

OK so you lost most of the buttons in favor of bigger, chunkier buttons. That’s good! You also made a little scoop in the dash for the LCD. That’s progress, but the placement still feels awkward. I know that’s where all your luxury car friends put the LCD now, but you’re so dominant in F1, maybe you can do better here too?

Can we take a moment to talk about the interactions a little? Your take on the rotary control is a little weird. You’ve got one, and it’s got a little hand rest on top of it. That seems good. But then the hand rest is also a touch interface for scribbling letters? Seems weird! I’ve never used that, but I’m a little skeptical.

Next, you’ve gone through some weird stuff with your shifters. You had a really lovely gated shifter on the S-class couple as long ago as the early 90’s! Lately you’ve tried steering column shifters, and now it seems you’ve settled on a soap-shaped chunk of metal that you move up and down to change directions and put it in park. I feel like you should give up the physical shifter thing and just go with (you’re gonna like this) more buttons.

My parting thought on the GT’s interior is this: width. Your designs impart a sense of tremendous girth in the dash, making the car feel bigger. We’ll come back to that immediately…

Finally, one of your most recent designs, the E-class sedan:

All the pixels!
All the pixels!

Again with a regal sense of width. Personally, I don’t like it. It makes your car seem like a giant sofa.

You are making great progress on reducing the number of buttons. Again, kudos.

OK, clearly you got a great deal on LCD panels. Plus, an almost equally good deal on eyeball vents. Good for you!

Also you put an analog clock on the dash. So that’s nice.

I don’t think we’re going to like this giant piece of software and glass thing for very long. Did you see Her? There are hardly any displays in it. All the computers are somehow inhabited by the characters, either by talking to them or interacting within a projection. Why take one of your classic instrument clusters, make that an LCD, and occasionally project information onto the windshield if the driver or passenger needs to see it there? Just a thought!

I’m a little split on the design of your wheel there. It’s nice that technically it’s a 3-spoke design but really, if you count, it’s 4 spokes. The lamest number of spokes. Perhaps with the split you were trying to add more negative space and perhaps evoke a very old, SL-like 2-spoke design? That’s a nice gesture, but I think you missed here. Surely you could engineer a straight-up 2-spoke wheel?

In summary:

  • fewer buttons, less noticeable screens, more seamless interactions
  • a few retro design elements (eyeball vents, analog clocks) are great, too many is too much
  • reduce your five design teams (screens, buttons, wheels, interactions, A/C) down to two: driving interactions and auxiliary interactions

Hope that helps!

Thought + Quality

Oliver Reichenstein, Putting Thought Into Things:

Quality — as in “fitness for purpose” — lives in the structure of a product. A lack of quality is a lack of structure, and a lack of structure is, ultimately, a lack of thought. One does not find a solid structure by following some simple method. We deepen the structure by deepening our thought on the product. Our role as designers is to put thought into things.

I’ve noticed I do the worst, as a developer, when I’m using tools and methodology to avoid thinking. Not entirely sure how to solve this problem, write some tests and commit whatever makes them green. Troubleshoot by tinkering with commenting code out, trying different incantations, pasting snippets found on the internet.

Each advance in how I build software is lead by finding some way I defer or avoid thinking and correcting that shortcoming. In doing so, I find myself a little more opinionated, a little more specific about what really matters in making software and what is dressing.

Put more thought into what I build. Always think about what constitutes The Quality for the kind of software I want to build. Seek to avoid the tech vogue in search of deeper quality and thought. I’m far from mastering any of these disciplines, but the results so far are promising.

Get thee to thy hammock!

When Developers Design

I see lots of “should designers code?” articles and introductions to coding for designers. I see far less interest in the converse. So what’s a designer think? Cap Watkins, a designer; Should Engineers Design?:

If you think design is 100% about creating “design artifacts”, I’d say your scope is too narrow and has the potential to stunt your personal and professional growth.

There’s so much to designing that isn’t about choosing colors, fonts, producing icons, or drawing. Developers can, and should, get involved in how the applications works, how copy guides the user through workflows, when to prompt about invalid data and when to fix it automatically, and how to help users through interactions. That’s design!

To wit:

Throughout my entire career I’ve had engineering partners deep in the design process with me. I show them sketches, bounce ideas off of them, have whiteboarding sessions to figure out what we’re going to do. I trust engineers I work with to let me know when something seems confusing, when there’s an edge case I haven’t thought of and to push on my ideas to find where they break and help me make them even better.

Developers often don’t even realize they’re designing when they’re building libraries and tools for other developers. Writing a good README so developers know why your project is awesome and how to use it? That’s design. Sweating the details of an OO or REST API? That’s design. Opting to remove a feature or solve two problems with one feature? That’s design!

The design was in us the whole time, and we didn’t even know it!

I leave you with this excellent wisdom:

When you look at design as a process and not an artifact, everyone on your team becomes a designer. We have different areas of expertise and skill, no doubt, but the product experience belongs to every member of the team. The more familiar you are with each other’s responsibilities, the more you’re able to participate with and help each other out when needed.

Here’s a fun thing I do that you should try: when you read articles about design, squint a little bit and pretend it’s about designing programs. You might find something you want to try the next time you sit down to work on some code.

Pancake publishing

I’m currently jazzed by the idea of full stack writing:

Hi is what we call a “full stack” writing and publishing platform. Just what is a writing stack? Capture. Write. Publish. is our summary of it, but really it breaks down into five parts:

  • Sudden inspiration!
  • Capture
  • Draft
  • Publish
  • Converse

Some platforms provide tools for parts of the stack. Hi gives you tools for the full stack.

All the pancakes.

Love the breakfast food metaphor! Hi’s tools and community integration seem pretty nifty. That said, the break down of inspire, capture, write, converse is what I can’t get out of my head. I don’t think you need special tools to approach it with that breakdown. WordPress, Jekyll, Medium, whatever. Always be writing, publish small ideas frequently (a thing I need to do more often!), develop the ideas that stick in your head or that lead to great conversations, repeat. Don’t let the layout of your blog template or the name of the tool limit your writing. It’s an easy mental trap to fall for!

NSHipster rainbow bar

NSHipster Rainbow bar

My favorite design touch in the Gowalla apps was the rainbow bar. Small wonder that fellow Gowalla alumni Mattt Thompson included one on the landing page for his collection of NSHipster essays that you can now buy as an eBook with cash money. Ed. apparently all the Gumroad pages have a rainbow bar. Mattt’s still awesome.

Web design for busy programmers

Here it is: I’m somewhere between horribly afraid and way-too-smart to seriously attempt front-end web work. Browsers are not the software whose bugs I am interested in knowing about.

That said, putting information on the web that doesn’t look like utter dross is a kind of required literacy in our field. While bravely dipping my toes back into the front-end waters, I recently found some great tricks. Rediscovered, probably, but I’m not sure where the idea originally came from.

Most important: design in greyscale. Color is hard and can lead to tinkering. My goal is to get in and out of the front-end bits quickly, so tinkering is the enemy. Greyscale is one dimensional, greatly simplifying matters. Give important information higher contrast and less important information or “chrome” less contrast. Now you’re done thinking about color.

Almost as important: use a fixed-with font. As a programmer, you look at them everyday, so it’s a touchpoint of comfort. Pick a font you don’t use in your editor all day, just so you can stare at something different for a while. Copy and paste a “font stack” from the aptly named fontstacks. Make important things big and unimportant things small. Now you’re done thinking about type.

The key to avoiding browser dragons, it seems, is to skip horizontal layout, i.e. pull quotes, text wrapped around images, etc. It’s pretty easy to use CSS if you only run things down the left side of the page. All the depth and despair of CSS is in trying to get things to appear off the left margin. So don’t do that. Leave it to people who know how browsers work and how to manage their gnarly bugs. Now you’re done thinking about layout.

It’s tempting to think you should make your code examples look really nice. Don’t worry about it; highlighting code is of marginal value. You’ll never be satisfied with how it looks. The human mind is capable of reading code without a rainbow spectrum of colors. Spend time on writing about the code, not on polishing the colors and how its highlighted.

With all of those things out of the way, your way is clear to think about the really important things. What do you need to say, how do you structure the message, what do you leave out, how do you organize all the information? That’s the essence of publishing on the web, not the accidental complexity of making things look interesting.

Context is data to burst your bubbles

Designing with context:

Context is a slippery topic that evades attempts to define it too tightly. Some definitions cover just the immediate surroundings of an interaction. But in the interwoven space-time of the web, context is no longer just about the here and now. Instead, context refers to the physical, digital, and social structures that surround the point of use.

Great design is built around people, not devices or software. Applying responsive design or native app UX is a tool, not a solution. Instead, we should design software that solves a problem for a real person (not a power-user or one of our colleagues) given the devices available to them and the context of use they’re in.

A high information density display is no good to a parent trying to get their kids out the door. Documentation based on video tutorials is no good for someone riding a bus. A developer troubleshooting a service bottleneck needs to know more than the average response time.

As both designers of user experiences and developers of software, we need to get away from the desk and out amongst those we’re building for. It’s too easy to build for ourselves and our friends. We need to consider how others approach and use what we make. Armed with that context, we can design a solution for everyone, and not just those we share a bubble with.

A handful of useful project mantras

You could do a lot worse than following the heuristics set out by this Software Architecture cheat sheet. The tip I need to follow more often is “Is There Another Way”; I frequently get way too caught up in my first idea, which is usually too simplistic or requires too much architecture. The tip I often try to guide people towards is “What If I Didn’t Have This Problem?”; routing around problems or trying to reduce them to problems that require less code is a super-powerful judo chop.