Category Archives: Process

Using Keynote during your design process

keynote screen design

Using keynote as an organizer for your thoughts during the design process:

  • Create an outline or screen inventory towards the story I’d like to tell.
  • As I’m working through the wireframes, I’ll record my thoughts as bullets into the keynote
  • Formatting your thoughts – keep it simple, go high level then break out specific UI elements.
  • Most importantly – always be ready to present your ideas, at any stage in the process.

Formalizing designs in a presentation has it’s advantages:

  • Keeps you focused
  • Keeps the audience focused
  • Is portable – can be emailed later w/out lengthy explanation
  • Is progressive – once begun, you can simply layer increasing information on top of the first presentation.
  • Is repeatable – once done, you can leverage the same presentation style for other projects.

 

Pro-tip: I work almost exclusively in Adobe Illustrator when wire-framing. It works great for layering increasing detail/resolution on the design from functional wireframes to final designs. Since the most recent Keynote software update, Keynote has issues copying vector designs from Illustrator directly to the page. Before you copy an element from Adobe Illustrator, outline the text (Command + Shift + “O”) in Adobe Illustrator, then copy to Keynote. It adds a step in the process, but is quicker than going between Illustrator > Photoshop, and the Keynote/PDF you result with is high quality with a smaller file size. Small file size is key if you’re uploading multiple version to Basecamp or sharing in email. 

 

The career of a modern designer.

finding direction

Sitting in a kick-off meeting, little tedious, sometimes steals your energy. Simultaneously reading email, IMing, listening to the client, giving feedback. Occasionally thinking how lucky I am to be in this room, in this conversation, & what/who we’re designing the software we’re creating.

Don Draper now builds software for a living.

Clicking through the email subscriptions and discovering a conversation about why they’re doing software vs. advertising. nice. These are the small points of validation when you think your life/career works more like a series of winding rivers, and less like a decision.

http://www.fastcodesign.com/3025950/why-i-left-advertising-to-become-a-software-designer

There are some great gems in this article about WHY software needs design. & how people with creative backgrounds can influence in a positive (designed) way that people interact with software. Smaller software tailored to the user, not enterprise. Making it technically “work” is no longer the need, making it usable is now the hard part.

“…Charles Phillips, puts it: “using enterprise software sucks.” It’s ugly. Cumbersome. Difficult to use. And impossible to love. “When engineers started to build these incredibly complex systems in the early ’90s, their biggest concern was: how are we going to make it work?” …. Now that business technology can deliver those basic user needs, it’s time to ask: How can we make business software work beautifully?”

Great food for thought for those of us who get up in the morning sometimes not knowing what the day brings, but feel purpose & drive towards a longer goal. Making things work beautify is the same in User Experience as it was in Advertising. When it works, you know it.

Creating an “Architecture of Participation”

design team tabletime at sparc

This past Thursday I was fortunate to hear Bill Taylor of Fast Company speak at the Charleston Chamber of Commerce annual event. There were a lot of components to his talk that sounded like the culture we’ve created Sparc. The phrase that caught my attention was the “Architecture of Participation“. There have been many times that I’ve thought of gathering the right people in a room as being an “architect” of people. My friend Taylor seems to be an expert at that. Or when my developer buddy Josh “architects” a solution by knowing what technologies play well together & essentially get shit done. This type of “architect” means as a leader, you facilitate problem solving by leveraging your team for the solution. That’s why we have a team, right? I think we were already doing this well, but sometimes having a word for it helps bring these quiet practices to light; formalizes them.

What interests me in the Architecture of Participation is how it calls out a leadership style I’m very comfortable. Traditional leadership has relied on the leader to identify & solve a problem on his own, then project the solution onto the people below them. The concept of leadership through participation means that rather than working in a vacuum, I can leverage the smart people around me. In the end, they’re typically the ones implementing the solution – this helps them “own it” as well. The Architecture of Participation simply means I facilitate the conversation & then let people be good at what they are already good at. Coming from a creative background, we (my team) is already skilled at working as a team – nothing new here. Learning & creative process intentionally leverages diverse skillsets, so why not problem solving on a leadership level?

I moved forward w/ a plan this past week to create “advocates” within our design team. Motivated individuals who can help lead the team in one aspect of design. This scales me, and offers the opportunity for these smart people to own a focused element that we need as a team. The advocates focus on aspects such as design quality, user experience or front-end development. Things our team need, but I can’t always facilitate the conversation 100% of the time on.

It’s a great thing to work with talented people. By creating an Architecture of Participation, we enable more creative solution & allow the smart people we work with to scale the team as a whole.

 

 

 

 

What are we designing?

One recurring theme as I watch the way our team works: the fine balance of  design philosophy (why) vs. Get-Shit-Done attitude (how):

blah

Are we just copying what we see? As designers, are we more often emulating what we see around us rather than “designing” or creating something new. Is it the job of the Artist to be “original” and the designer to emulate? or does the designer constantly look for opportunity and create smaller shifts as they observe. If an artist is large jumps, is “design” a series of smaller responses and shifts over time? Would a client understand something they’d never seen before… something without visual roots or a comparison… “Microsoft is using flat design, so can we”? or to truly change the landscape, it it a series of small moves, tied to a known history that allows designers to be original… And do we really understand what we’re doing?

In some ways this conversation is half in my head, and fragmented between many good conversations on our team. A little bigger than the response to skeuomorphism in the current design trend in flat design. The internet makes it too easy to borrow when convenient and trendy. Guess it’s a good thing I like most things (except the color-blind colors :/ ) about the current design trends. No one trend or concept stands alone without perspective.

One thought that brought me back to this subject this morning while reading an article by John Maeda:

Ultimately, good design will be born from consideration of multiple perspectives. It should be something we haven’t even dreamed of yet.

Always be ready to present

I think part of being a good designer is to constantly look back and analyze your habits: where or from whom they came from. Think back to the art director who taught me to do one more iteration. Or when I learned to create one more design that makes you uncomfortable. Most often I trace many things I do well back to my first year of architecture studio and the design habits that I carried forward from there.

architecture-studio2

Always be ready to present.

One of the habit instilled early on was to always be ready to present. period. A teacher will walk by your desk after you’ve been up all night, and in a casual manner, ask you what you’re working on. easy right? Not always. Sometimes it hardest to explain what’s seems to work in your head, much less have the “work” in a state where you can show it to others. There is always a very messy series of iterations before the final design starts to emerge. Failures are great to learn from, even if you suddenly need to present your failures to others.

These days, our design team works in an Agile software development environment. It’s loud and chaotic. And priorities shift daily, sometimes hourly. Staying focused is hard. Being able to switch gears and talk about a design to co-workers or a client is essential. Sometimes it’s a keynote presentation, or PDF post to basecamp. More often then not it’s walking a client or developers through a raw illustrator artboard. The process & the failures & where the final work is starting to emerge. I’ve been able to observe in our junior designers: it’s these agile, micro presentations that get you comfortable talking about your ideas in any audience.

Encourage feedback through presenting.

Showing your work should always have a goal – some question you’re looking to have answered a little more complex than “do you like it”. A goal to present “something” by close of business with the client/team helps keep you accountable. We use basecamp a lot for this. It keeps the process of presenting work informal & conversational. It also gets the designer out of their heads-down mode and forces communication. Most often designers would be happier without feedback. The simple act of posting a design is huge for both parties: For the client, it adds transparency and let’s them participate in the design process. For the designer, if gives them pause to collect their thoughts; A chance to articulate thoughts & “finish” something, if only for the day.

In the end, it doesn’t matter the state of the project, the size of the audience or how you deliver your thoughts. As you design, you should always be ready to present.