In 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.
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 !
Just last week I was explaining – to a friend – the importance of dog training.
Nick and I do training almost every day and on many things were getting quite good. However with this new cold snap that we’re having, our training regiment has had to change. Fortunately we found something new to work on.
You see,with this very cold weather, Nick’s outdoor water bowl freezes quickly. The problem is Nick will hardly ever drink out of an indoor water bowl. So we been working on a new exercise.
The training is almost complete!
There are two water bowls, one just inside the door and one out on the front porch. Anytime we go for a walk, play a game, or practice, I will take the indoor water bowl and place it outdoors and take the outdoor water bowl and place it indoors. By the time we finish, the outdoor water bowl is cold but not yet frozen. And by the time we go out again, the indoor water bowl is thawed.
Nick has worked very hard to train me in this new skill and I think he’s done an excellent job!
I recently completed an industrial design project. Sadly, I ignored or dismissed a very important step in any design project – prototyping.
The project was a new instrument panel for a tandem seat aircraft. (Readers may recognize this as a redux of a similar project 2 years ago.)
The panel cutting was done by a third party so the process began with a sketch by me. I then generated a high fidelity mockup from the sketch. It took about a week of "an hour here and an hour there" until I had a a mockup which I really liked.
The fabricator then worked with me on several iterations to create a CAD drawing of the new panel. Version #6 was the final drawing. I signed off on it and the panel was cut and shipped. During the iterations we addressed various physical requirements such as the width and height of the actual switches and breakers, the mounting bezels for the GPS and screens, etc.
Once the panel and all of the equipment was in my shop, I settled down to the task of wiring. This started by temporarily installing all of the equipment into the panel and then working from the back side to deal with all of the audio wiring, data & communications, and then all of the power connections.
After the basic system tests were completed, I disassembled everything and took the panel to the pain shop for base coat, labeling, and then clear coat finish (with a flattening agent to reduce reflections). I was very happy with the results.
I reassembled everything and then installed the new panel along with some new components in various locations in the airframe in support of the new panel.
All of the basic tests passed. The new panel was ready for flight testing, calibration, and training.
The first test flight exposed a fundamental user experience error. Do you see it in the last picture ?
Here is what happened …
- My sketch was done on paper.
- My high fidelity mockup was done on the computer screen.
- The layout and labeling was done on the cut panel.
- Initial testing was done on the bench
All of these were looking either on a flat representation or looking strait ahead at the panel.
When you sit in the airplane, the pilot’s eyes are approximately 20" from the panel and the pilot’s sight line is level 10" above the center of the panel. The pilot is looking down between 20 and 30 degrees at the panel. As you can see in the final picture, a portion of the labels are obscured because the center display’s bezel is 9/16" deep at the bottom.
A physical mockup would have detected the viewing angle and the label position could have been adjusted.
I’ve never been a big fan of canned cranberry jelly / sauce. It’s so easy to make your own. My recipe has just two ingredients – fresh cranberries and a bottle Port.
Place two 1 pound bags of fresh cranberries in a deep sauce pan. Add one 750 ml bottle of inexpensive ruby Port.
Bring to a light boil.Stir constantly as it reduces. Continue cooking until the cranberries are very soft and break up when stirred. Cook until the sauce is about 1/3rd of the original volume. You know you are starting to get close when the sauce will coat the back of a spoon crimson red. Be careful not to burn the sauce as it gets close to being fully reduced.
Once it has cooled somewhat, if it’s too tart for your liking, add a 1/4 cup of confectioners sugar and stir.
The result is a complex slightly tangy delicious homemade cranberry sauce! It’s great on muffins or county toast, roasted chicken, and so many other used. You can store it in the refrigerator like a jar of home made preserves!