DesignAday

Lazy Genericism

Bootstrap is a beautiful piece of work, no doubt. It makes flexible and responsive grid-based layout a piece of cake. It provides transitions and dynamic behaviors without a sweat. It even provides clean, contemporary aesthetics in pre-made components. Add Glyphicons or Font Awesome and you have a web app that will satisfy the CEO built in no time flat.

Of course, you used an accordion panel instead of coming up with something better, because it was easy to do. And the select widgets aren’t exactly what you had in mind, but they were there. Add you used a non-descript document icon for “Add Properties” because there wasn’t a better icon in the set. Oh, and it looks like every other site built with Bootstrap because you started with one of their templates, and you just didn’t take the time to do much customization.

Yes, Bootstrap and its cousins are wonderful things. We should take advantage of them. But please, I beg you, don’t fall into the trap of quick and easy. Don’t forget that your user interface is your brand. Excellence will not be found in lazy genericism.

IxDA Pittsburgh Workshop Open for Resgistration

My workshop, Sitting in the Driver’s Seat: creating production-ready CSS, which I led at Interaction 13 in Toronto, is getting a second run in Pittsburgh. All proceeds, beyond the rental of the space, are going to IxDA Pittsburgh for use in future programming. Since this is the first event to which we are charging admission, we’re keeping it very accessible. It’s only $100 for professionals and $50 for students. Spots are limited, so register now through Eventbrite. After you register, RSVP on IxDA Pittsburgh’s Facebook event page to let everyone know you’re going.

CSS 3 has handed the keys back to designers. With a syntax and structure that speaks our language and a fine-grained level of control, it empowers designers to not only prototype in the actual medium, but to contribute production-ready code. The days of pointing at the screen over the developer’s shoulder and trying to explain how something needs to shift three pixels are over. In fact, much of the JavaScript currently employed for simple UI behaviors can be replaced with well-architected styles. Take the driver’s seat, and make the CSS your UI specification document.

This workshop is intended for intermediate designers interested in gaining more control over their team’s final product. Participants are expected to possess a working knowledge of CSS. They should be able to read a stylesheet and understand what it is doing in the HTML page that references it. They should be able to write CSS styles and apply them to HTML elements to achieve a desired layout on a page.

As a participant, you will:

• Familiarize yourself with the tools you’ll need to integrate with your development team.
• Learn how Object Oriented CSS (OOCSS) can lead to cleaner, more maintainable code.
• Discover how to replace heavy-handed, inefficient JavaScript with CSS-driven behavior.
• Get started on your own library of CSS components.

About Jack Moffett
With a BFA in Graphic Design from West Virginia University and a Masters in Interaction Design from Carnegie Mellon, Jack has been designing web, desktop, and mobile applications for over a decade. He has worked in both research and industry environments and has been teaching design part-time for more than eight years at WVU. As Senior Interaction Designer at Inmedius, a Boeing Company, Jack’s responsibilities cover the gamut from initial user research and product conceptualization through to implementation and testing. As such, his skill set includes visual design, information design, and front-end implementation. He has designed software tools for Lockheed Martin, Shell, DaimlerChrysler, Eaton, and many organizations within the U.S. military, including Joint Service Explosive Ordnance Disposal, Naval Reactors, and NCIS. Jack has spoken at conferences and led workshops to teach designers how to integrate with their development teams and participate in implementation. He writes about design on designaday.tumblr.com.

Unforeseen Benefits

It seems obvious now, but when I was working on my conference workshop of Interaction 13, I really wasn’t thinking about it being of particular benefit inside my company. I’ve been the sole interaction designer for so long, I don’t give as much thought to knowledge sharing as I probably should. Since the acquisition, however, we’ve had an influx of work, and due to a number of mostly unrelated circumstances, I’ve recently been charged with training a junior graphic designer to assist in front-end implementation. The exercises I developed for Sitting in the Driver’s Seat are perfect for this purpose, and she is quickly coming up to speed on OOCSS and the standards I employee.

On a related note, IxDA Pittsburgh is currently planning to put on my workshop in May. If you are in the area and interested in learning how you too can participate in implementation and contribute production-ready CSS, stay tuned for an official announcement.

Amnesia Fortnight

Every year, Double Fine Productions takes two weeks to prototype a handful of game concepts, throws them at the wall, and sees what sticks. They call the event Amnesia Fortnight.

This normally-secretive process is named “Amnesia” because the entire team at Double Fine forgets what they’re working on, and “Fortnight” because it lasts for two weeks. During this time the company is divided into smaller teams, and each team must make a game in those two weeks.

Amnesia Fortnight was held in December, and this year they opened it to the public. Each potential project leader pitched their idea not only to Double Fine, but to the internet. The internet then voted on the concepts, selecting five that would be developed over the two-week period:

• Hack ‘n’ Slash is a Zelda-style RPG that incorporates computer programming as a game mechanic. For example, you can jack into an enemy and edit their hit point attribute, killing them by setting it to zero.
• Spacebase DF-9 is a systems-based simulation game in which you build and manage a space station. Check up on the inhabitants by reading entries in their social networking platform, SpaceFace.
• The White Birch was inspired by Ico and Journey. Jump and climb through a beautiful environment.
• Autonomous presents you with a Tron-like junkyard full of robot parts. Combine parts to create automatons that will carry out tasks.
• Black Lake is a dark, but beautiful game world in which plants and animals are corrupted by nightmare.

The entire process was documented by 2 Player Productions in a series of 12 films, beginning with the pitches and following the teams as they turn the ideas into playable games. The films and the games are being sold through Humble Bundle. I didn’t actually find out about the whole thing until after the holidays, but I picked up the bundle in January, and I’ve been watching the films. They’re very well done, and I wish I had the time to show every one of them to my class. So many of the points made in Jesse Schell’s book, The Art of Game Design, are played out in front of the cameras. I haven’t played the games yet, as I want to finish watching the films first, but the more I see, the more anxious I am to try them out. I think there is a lot to be learned here about not just game development, but software development and general creative process and innovation.

If you have an interest in game design, I recommend checking it out. The downloadable version is only $9.99.

Fold

As a college senior, Sean Dooley has some issues with laundry. He set himself the task of designing a laundry bin that would be more space efficient for purposes of storage and travel. After a lot of research into existing products, he was most influenced by paper grocery bags. After initial brainstorming and sketching, he produced a tiny prototype from cardboard, paper, and masking tape.

It took many iterations to get the folds right, especially as he increased the size of each prototype. Eventually, he had one made out of fabric that was large enough to test with friends and family.

The final prototype utilized heavier materials and sturdier construction. A more comfortable grip was created on the handles. Not only does it fold up small enough to stash in a suitcase, it serves another function as well. Laying flat on a table, it serves as a folding station. The two ribs running vertical on the side of the bin are guides for folding shirts.

Sean fully embraced the iterative process, rapidly producing prototypes that helped him surmount obstacles. The result was a design that clearly solved the stated problem and a prototype good enough to use as a production model. I could easily see this product on the shelf at Bed, Bath, & Beyond.

Working with Developers: 12 and counting

One of the great benefits of having worked at the same company for 12 years is that I have developed an outstanding working relationship with the developers. Literally every developer I work with has an appreciation of my role in a project. They understand how my design tasks relate to their development tasks and how the whole process weaves together. They know what questions should be asked of me and which decisions I should be approving, and they actively seek me out of their own volition. More importantly, they recognize that my work makes the output of the team better, thus making us more competitive in the marketplace. Upon attending my talk, Working with Developers for Fun and Profit, a couple of my coworkers expressed dismay that our methods were not commonly practiced throughout the industry.

In a recent discussion, my manager pointed out that once upon a time, if the developers had been instructed to take our customer’s requirements document, develop a solution, and build it, they would have done so. The result would have been similar to any other programmer-designed UI, but they would have done it. If given that charge today, the same developers would likely throw up their hands and say, “Hold on! We can’t do that without Jack (or someone of my talents).” They know that the result would not be on par with our typical work.

I say this not to brag, though I do take pride in it, but to illustrate the value of putting in the time (years, in fact) and effort to learn to communicate, build the relationships, teach the process, and adapt to your development team.

My talk on working with developers was not accepted to Interaction 13, but there will be other opportunities to learn from my experience. Stay tuned. 

Ghosts and Echoes

It occurred to me today that I have changed focus in my unofficial role as a creative director for the annual haunted house we produce at my church. In past years, most of my effort went into the design of the house itself: the layout of the rooms, the decorations, the characters, the story that was being told. I’m still contributing in those areas, and I’m thinking a lot about flow, but my focus this year is designing the process and tools by which the house can be efficiently planned and produced. I’m creating inventories and punch lists. I’m putting policies in place and documenting best practices. I’m assembling a playbook that others would be able to use to run the house if I were no longer involved. I’m not surprised by this, but I’m amused at finding echoes of my career in a haunted house.

Design Studio ain’t a Method

method: A particular procedure for accomplishing or approaching something, esp. a systematic or established one.

I’ve been seeing and hearing a lot of people talk about “The Design Studio Method” recently, and it’s really sticking in my craw. Here are a few examples:

The Design Studio Method - Todd Zaki Warfel

Introduction to Design Studio Methodology - Will Evans

Collaboration through Design Studio and Critique - Adam Connor & Aaron Irizarry

I don’t have a problem with the methods that are being described, and I have a lot of respect for the people that are presenting them—my problem is with the name. “Design Studio” is not a process.

Well then, what is it? Design Studio can be defined as both a place and a culture. A design studio is a collaborative space in which multi-disciplinary teams work together to solve problems and create. The space may be divided into multiple areas, but it is typically open and malleable. It will have tack boards, white boards, computer projectors, and other tools and materials for visualizing and sharing ideas. It will allow for both individual and group work, though it is not concerned with privacy. It does not contain cubicles, and would prefer not to be referred to as an “office”. The space facilitates brainstorming, critiquing, presenting, prototyping, sketching, researching, synthesizing, and many other activities that figure within the design process. Sometimes it smells like pizza.

There are no rules about when it is used or how it is used. It is not limited to a single project. There is no sequence of events that must take place within it. There is not a list of products that must exist before it may be entered, any more than there are required results that must be had before it is left. There is no timeline dictating its usefulness. It doesn’t exist temporally as a phase within some larger entity, nor is it a conglomeration of phases. The design studio contains, facilitates, inspires, showcases, and remembers.

Illuminate, Generate, Present, Critique, Iterate (and variations on this) is a fine method, one that I was taught in my undergraduate Graphic Design program, but it isn’t the definition of a design studio.

Scenarios for Today AND Tomorrow

Jared Spool conducted a great interview with Kim Goodwin on scenario use as part of the design process. She had a lot of smart things to say that I wholly agree with, such as encouraging us to start out “solution agnostic” and at a high level, as well as her explanation of the differences between scenarios, user stories, and requirements documents. However, she made one statement that I take issue with.

One of the things I see people do a lot with scenarios is they document the current misery instead of imagining a better future. They’re really just saying, “Well, here’s how it works and what can we tweak?” They sort of use the present day as their starting point with a scenario instead of saying, “Look, imagine for a minute, and maybe it’s a big leap of imagination in some cases, imagine for a minute that we ruled the world, that we don’t have constraints. What would happen here?”

Now, I do agree with what she is saying here. If you are only writing the “Today” scenario, you are really missing the boat. But then she made a comment later on that took things too far.

Well, scenarios are not really about documenting what’s happening today, so I wouldn’t say that I ever use scenarios to explain today.

I use scenarios that explain today for two purposes. The first is to establish a common ground and ensure that I understand the users’ current context, tasks, processes, and tools. The “Today” scenario becomes a collaborative, communication tool that lets me tell my customer’s story back to them. A conversation ensues, during which we figure out what I got wrong and what they left out. In some cases, we even discover differences in the way people do things that the customer never realized.

The second purpose is simply as a point of comparison. Once you have a visionary scenario that inspires everyone, comparing it point for point with the “Today” scenario will bring to light any existing problems that were left out and emphasize the benefits of the new solution. It’s a technique I’ve been employing to great effect for fourteen years.

A Deep Bench

My band has a deep bench. We are all multi-faceted. I’m the drummer, but we have another guy that can play drums, and a third that will cover in a pinch. The two of them are both guitarists, electric and bass, respectively, but they can both play acoustic. Our lead guitarist can also play keys. We’re all better than average singers, each one able to sing lead or provide harmony. You can understand how important that is to a praise band that has to lead worship every Sunday. We each have to miss occasionally for business trips and family vacations, and the ability to cover for each other is invaluable. But more than that, it makes it more enjoyable. I’m happy for the opportunity to step out from behind my set and give my vocal chords some exercise.

Interaction designers often make the argument that they don’t need to know how to implement the UI, or they don’t have to be good at visual design, because they work in teams that include members with those skill sets. I would argue that your design team is going to be more efficient, more effective—more successful—if you have a deep bench. If every designer in your group can contribute to the visual design, help produce graphics, create wireframes, structure content, write HTML and CSS, lead customer meetings, and gather user research, you are going to have a much more flexible team capable of doing more than if each person focused on one of those activities.

At An Event Apart in 2010, Jared Spool stated:

“Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results.”

If you currently have a team of segmented roles, the good news is that that’s the perfect place to start. All you need to do now is cross-train. Build yourself a deep bench.