Concrete Fence Posts

Since moving back to Indiana in April, I’ve done a lot of cycling. It turns out, even though Hoosier drivers aren’t the most amenable folks to having bikes on their roads, there is so much space in-between everything that riding is pretty good. It doesn’t take long to get out to gravel county roads, and away from most cars. Riding through a lot of areas that time seems to have forgotten has really engaged a standing interest in Indiana history.

One of the things in particular that has interested me as I’ve been putting on the gravel road miles are all the old farm fence posts still left intact.  They are an interesting artifact of a time when (I assume) roads, as such, didn’t exist, and the fences held up by these posts were the divider between farmers fields. This dovetails with some longstanding field-based Indiana location names – Westfield, Greenfield, Bloomfield, Chesterfield, Plainfield, Wheatfield, Winfield.. And probably several more defunct ones.

I’ve snapped pictures of a few of these posts haphazardly. Most are concrete, but there are a swath of weathered lumber, with various forms of bracing, both wood and steel. Continue reading

Skills to help you land a UX job.

This past weekend I had the chance to attend the IDSA (Industrial Design Society of America) Western district conference.  I’ve been to several IDSA events in the past, but skipped last years. It was good to get back and hang out with the Industrial Design “tribe”. (The idea of tribes were one of the themes of this years event) I met a lot of nice people, learned a lot of new things, and had the opportunity to participate in a collaborative “design swarm”.

On the flip side, as a UX designer, I was one of a minority. It’s not a huge difference – much of the methodology of the two disciplines is the same, and many Industrial Designers are taking work in UX as of late. Still, I felt like a bit of a representative of the UX side of things, and people were asking me questions.

Two of the most common questions I heard were: “How do I get a job in UX?” and “What goes in a UX portfolio?” These are both particularly salient areas of thought since UX as a field is still relatively new. Trying to come up with answers on the spot got my mind working, and I put together a short list of things that I think should go into a UX portfolio. I think these things are really representative of the work that happens in industry (at least as far as I’ve seen) and also the stuff that really provides value – whether that’s to clients, or development teams or project managers.

Situational Awareness / Presentation skills

This is not as much a portfolio piece as it is a factor in how the portfolio is presented. And this is a tough one to demonstrate. There are two main factors here:

  1. UX folks should be dealing with people who use, or will use whatever it is that’s being designed. We could pawn that off onto a researcher, but throwing this kind of stuff over the wall is a waste of opportunity. That said, a designer has to be sensitive to those being interviewed/observed and understand their needs; even if it’s just in the context of the interview.
  2. You have to present your work to someone at the end of the project. If you’re just presenting it to your design director, maybe it doesn’t matter as much how you approach the presentation, but there is real value in being able to talk to a dev team, a PM or even the C suite. You have to know what drives them, and address it as you talk about your work.

Structured Research

I’ve seen a lot of really nice student projects with absolutely no basis in research. (or reality) Make sure you’re showing that you can do the science to prove to your audience that you made the right design decisions.

Sometimes just having research isn’t enough. It has to be structured. What was your plan going into the research? Did you have key questions that you asked all respondents? How did you choose them? What did the results statistically tell you?

Insights

Insights are kind of easy. Most designers have these throughout. But as in the above, can you tie the insights to real data and real users?

Process

Industrial design has really provided us a lot of structure in terms of documentation. Any ID process book is a good starting point. It’s important to talk about all of the design activities you did, but maybe more importantly, you should tell why you did them.

Wireframes / Prototyping

This is a gimmie. Everyone should know how to do basic wireframes. But go further – make sure they’re annotated and explain the functionality and the reasons that design decisions were made.

Detailed Design

It’s the next step after wireframes. Know how to specify visual style in a “pixel perfect” way, and be able to show and explain design patterns.

Information Visualization

As we move further into a “big data” world, it’s important to be able to use visuals to help users make sense of statistical data. It’s one thing to come up with a flashy, novel idea, but another to make something that is easy for a user to get use out of.

Strategy

Strategy is emerging as an important part of the UX package as more businesses are using UX to drive sales. The idea is to understand the business goals, design for them, and explain why your design helps the company achieve them. You could say that this is designing with an eye to the business, but it should be more holistic – How does this impact the dev team? How can the marketing team make use of your work?

 

 

 

There are surely many other things I could put in here, but these are the things that guide my work. I think it’s easy to get wrapped up in flashy presentation, which is great in it’s own right, but the real value is giving your clients a good return on their investment, and I think the above list does that.

Generative modeling – grasshopper

In the past week, I’ve been doing some early explorations of generative modeling. In my case, I’m using Rhino 5 with Grasshopper. I have to admit that I’m still a bit stymied in terms of finding a _good_ use for it beyond adding some weird detail to surfaces.

If you want to see some examples, check here.

For whatever reason, I set out to build surfaces from joined spheres. It makes an interesting surface.. kind of like lizard skin or some such. Initially I was assigning a random 3D pointfield to a cube (which is the default shape for Grasshopper’s 3D populate) and then using those as the center point of a sphere of random size. It’s pretty, but limited in usefulness.

gen

Sphere-ish object generation with Grasshopper.

I really couldn’t wrap my head around a way to limit the point field to a non cube object, (I suspect I need to use “inside” and then “cull”) so I decided to do it by surface, which seemed like it would limit the number of spheres. (good for processing time)

Sphere surface

Sphere surface

Next I started putting in whole objects. I ran into a problem where the random generator started making the same number a lot, but with the help of my prof, it now works reasonably.

Input and Output

Input and Output

It’s not perfect, but it’s pretty close to what I want. The next step is using this for another project – I’m doing a bronze casting, and thought that this kind of form would be perfect for it. These kind of shapes aren’t great for a lot of manufacturing techniques, but casting should work well.. the only problem will be cleaning up my initial model. It will be a 3D print of this form, and in the nature of the prints from the 3D printer at school, it will be very grainy. I’ve really not come up with a good way to sand a sphere yet…

Anyhow, I think the object I make is going to be a drum lug – a part of a percussion drum that allows the head to be tightened down. see illustration.

Drum Lug

Drum Lug

I figure I can have 8 or 10 of them cast and build a drum with them as a good way to show off the casting design. We’ll see how it turns out. If you’d like to play with this yourself, here’s the setup I’m currently using.

Grasshopper script

Grasshopper script

hueristic evaluations.. beyond the screen and ergonomics

Since beginning my foray into Industrial Design and Interaction design, there are a few common threads that keep popping up in my projects and annoying me. Today I want to write about one that came up in a recent project where I was designing a ubiquitous computing/ambient weather forecasting device. As is usually the case, we were required to plan a heuristic evaluation.. for a physical device.

Bonsai weather forecaster

Bonsai weather forecaster

This shouldn’t be a big deal, but the problem is, everyone immediately jumps to Neilsen for the heuristics they’ll be using. This is all well and good; they’re a pretty good set, but they are intended for 2D screen based interfaces, especially web, where it’s automatically assumed that the interface will have the user’s full attention; ie: staring at a computer. I’ve googled “heuristic evaluation” +”physical device” about a hundred times over the past two years and always get the same sad results. Usually, the only things remotely worthwhile are various archives of this IxDA forum thread from 2008. The gist is that a guy is looking for heuristics for physical device  testing, and the IxD folk tell him to look up ergonomics.

In my own practice, I take Neilsen’s 10, ditch the ones that really don’t apply, alter some, or grab some from other limited sources. One of these other sources that I’ve used before is a list from a consulting company called Tristream. I used these in the evaluation of a piece home/industrial automation back-channel management software. It wasn’t totally ideal, but it got the job done.

Neilsen's Heuristics vs AmbientHeuristics (Markoff et al, 2003, p.172)

Neilsen's Heuristics vs AmbientHeuristics (Markoff et al, 2003, p.172)

Back to my ambient weather forecasting project.. I was lucky enough to find a great paper titled “Heuristic Evaluation of Ambient Displays” from the ’03 CHI conference. In it, some folks from UC, Berkeley and Intel Research went through the heuristic selection/creation process I described above, in this case, especially for ambient displays. The paper discussed their test of these heuristics and found them to be significantly more useful in identifying major issues than the original set from Neilsen. In the test, “a single evaluator will only find about 13% of major issues” but “a single evaluator using the ambient heuristics finds 22% of known major problems on average”. (Markoff et al, 2003, p. 175)

Where am I going with this? I really think there should be a published set of heuristics for physical devices. I understand that the type of device greatly impacts the heuristics that should be used, but it would be nice to have a basic starting point that made more sense for 4D interaction than just the stock set from Neilsen. I’m hopping to draft such a paper over the summer. It’d be of tremendous use for myself, but I think the Industrial design community as a whole could benefit. If any of the designers out there have suggestions to this end, please let me know! I’d appreciate the input.