Posts tagged ‘Design’

Hire a Renaissance Designer

vitruvian_manIn a utopia, there would be a person for every job and a job for every person. We don’t live in a utopia. Whether you are a startup or a global corporation, the odds are good you can’t afford to have every role silo’d. It’s just too expensive – either in dollars or time (or both).

A Renaissance Designer brings a mix of skills to the task of delivering a great product. They should poses a solid foundation in their own discipline of design – user research, ideation, sketching, user testing, mockups, etc. They should also possess at least rudimentary skills typically bestowed on the team segments they work with. It’s true, whether we are talking industrial design, print media, or software design.

An industrial designer should understand the manufacturing process for materials – how plastic flows, how strong it is, the limitations of a carbon fiber layup, or the methods of combining fiberglass with metal.

A visual design working for a print media company should understand the side effects of the print process, bleed, and the limitations of scaling.

A software designer should understand the fundamentals of the UI framework, the constructs of HTML & CSS, or be familiar with the platform UI interfaces.

A Renaissance Designer is more adept at working side by side with their engineering and technical brethren. When there is a relatively seamless collaboration between designer and technician, they are able to more quickly develop a concept, test it with end users, iterate it, refine it, and productize it.

Using a web application example, the UX Designer creates a mockup of an idea and tests it with end users and then conveys the mockup to a developer to codify. There are clear boundaries. A Renaissance Designer may create an interactive mockup or ask a developer to create a rough prototype; then apply all of the necessary CSS to visually match the design. The result is a more seamless transition – a blurring of the lines – between the design tasks and the development tasks.

It seems intuitive but often, companies over delineate roles. This slows progress, establishes an “us vs. them” environment, and results in less design reaching the end user.

Can’t find a Renaissance Designer? No problem. Look for is a Designer who is curious to learn. The range and depth of skills they need is easily attained as projects and tasks evolve. You get an invaluable asset and they get a nearly endless dose of fresh challenges.

Developing trust requires empathy for the user

image by truefreestyle

I was recently asked to help out on a new software project related to security. I was told the problem was that “users don’t understand.” I guessed that wasn’t the real issue.

One message the team heard consistently was, “Why is this a ‘risk event’ and not that?” When we dug into the underlying feelings behind the users’ comments we learned they wanted more confidence that the software was doing the right thing but initially they just didn’t trust it.

How do we instill trust in the end user? On this project, the deployment team gets the system up and running and then spends a large portion of their time explaining what is happening behind the scenes.

Why not incorporate the explanations directly into the software? Historically, the software was like the Wizard of Oz, “pay no attention to the man behind the curtain” – in other words, the team designed and delivered a user experience that was deliberately and impenetrably opaque.

The researchers and developers on the projects are  incredibly smart and they have invested thousands of hours to create intelligent algorithms, so it’s no wonder they repeated say, “We want all of this to be automatic”.

Automation is good, but only once the user trusts it.

A historically similar situation is spam filtering. In the beginning, spam filters had a habit of false positives and frequent misses. They eventually got better – but never perfect. Two factors made the filters better; one was better algorithms and the other was giving the user some control to mark things as spam and not-spam.

For this project, my advice was to expose some of the software intelligence. Let the user understand why the algorithms identified a risk or why it has dismissed it. Let the user contribute their own assessments by promoting/demoting a risk event. Finally, let the user hide it all when they are not interested – like when they start to trust the system !

POH Kneeboard 2.0

New POH Kneeboard with write-on surface
New POH Kneeboard with write-on surface

A little less than two years ago, I wrote about creating a combination pilot operations handbook (POH) and kneeboard.

One aspect of the implementation bothered me from the very start – the metal front and back covers could be hazardous in an accident. The military use a polyethylene plastic material which is somewhat flexible and less likely to injure.

A separate problem surfaced when I used the kneeboard – my scratch paper would move around and curl. A fellow pilot had described using an arm band – like [US] football quarterbacks use – and a grease pencil.

I decided I’d address both issues with an update to the kneeboard.

The flexible translucent PE plastic is 1/16″ thick. It has a smooth side and a slightly textured side. Normally the smooth side would be considered back. Since I plan to write directly on the cover, I used the smooth side as the face. This makes it easy to wipe it clean.

Garmin understands amateur aircraft builders

For anyone who has worked with Garmin’s prior generation of aircraft avionics, they are all too aware of the challenges of wiring high density D-Sub pin connectors, threading back-shells, and conforming to old standards. So I keep being amazed by the small changes Garmin has made with their latest generation of avionics targeting the amateur home built aircraft community.

I’m very grateful for the switch to standard D-Sub pins and the open top connectors makes the assembly much easier. And here is another example of Garmin thinking like a builder rather than an engineer – mounts which can be switched from the ends to the sides of their new remote mounted radio.

When building a kit plane, everything is up to the builder and this means every airplane is a bit different with hundreds of decisions.

In my RV-8, finding a location for the remote radio was becoming a challenge of compromises. I finally located a suitable space but the radio mounting tabs were in the wrong place to make it work. I was about to concede and build new mounting tabs but when I removed the factory tabs I discovered Garmin had anticipated my need!

With the factory installed mounting tabs at each end of the radio, it can be mounted horizontally or vertically with ease. In my case, the problem was that I needed to mount it across between the RV-8’s forward baggage bulkhead and the Z-brace. Ideally, I wanted those tabs to be on the sides of the radio rather than the ends. Thankfully, Garmin attached the mounting tabs with screws. When I unscrewed the tabs I was delighted to see that Garmin had designed the tabs’ screw locations and the radio’s screw holes (two extra ones hidden under the tabs in their original locations) to rotate 90 degrees and re-attach! All I had to do was unscrew the tabs, turn them 90 degrees and there were nut plates already installed for the alternate orientation.

Garmin had designed the radio to give the builder multiple choices for how to install their radio.

This truly is an example of designing for their end user!

GTR-20 with adjustable mounting rails
GTR-20 with adjustable mounting rails

Size is relative for the iPhone 6 Plus

big phone in a big hand vs small hand
big phone in a big hand vs small hand

A friend posted a link to Monday’s “Live with Kelly and Michael” where they are talking about the iPhone 6 Plus.

The interesting visual from the segment is the size of the phone appears to change. With Michael Strahan the phone looks completely normal but with Kelly Ripa, the phone looks huge!

Think before you CSS

execution order of CSS affects usability
execution order of CSS affects usability

Modern websites are a rich combination of content, behavior, and style. The behavior has traditionally been implemented in JavaScript and the style has been achieved with CSS.

Ten years ago, browsers were simple and so were web pages. Developers didn’t have a lot of tools. Java in the browser was one solution JavaScript was another. Both had their usefulness, both had their issues. Most Java in the browser has gone the way of the Dodo Bird … thankfully.

JavaScript hasn’t been perfect. It’s biggest strength has also lead to it’s biggest challenge – it’s very easy to learn and use which has lead to it being used A LOT! This make websites heavy and slow, especially for those with slow internet connections such as DSL connections and mobile cellular internet.

Web developers – good web developers – understand not only what JavaScript can do but also HOW it it is handled by the browser. Their testing covers transmission, loading, and execution – not just functionality.

HTML5 and CSS3 are enabling more and more behavior without JavaScript. Modern browsers are really “web execution engines”. Look at the size (install and runtime footprint) of a modern browser and it’s clear it has been built to be a runtime system. They are capable of performing image manipulation from real time scaling and drop shadow to 3D transformations.

The shift from JavaScript to HTML5 and CSS3 for these capabilities brings with it the same developer concerns.

The image in this post is of a website which took approximately 30 seconds to render. It makes heavy use of CSS. As you can see, the developers didn’t consider what happens when their CSS loads slowly. The site is unusable – even confusing – until everything gets loaded and executed.

A good web experience requires a “progressing experience” – one where the user can get value very early and gets additional capability and options as more of the content is loaded. It’s bad design when the “content” is loaded but unusable because the “style” is slow. This type of experience suggests the developers and the owners believe “style over substance”. I doubt they want that to be their slogan.