quietAction blog feed

WORKSHOP: creative blogging at teahouse studio

2012-02-16T16:00:08Z

I thought it would be fun to catch you up with what I've been up to so far in 2012. I've been deep at work upgrading technology here in my studio and working with several startups doing product development but I've also been getting myself moving on building some new neurons by finding some cool spaces and communities to work in.

In January, I finally made it over to Teahouse Studios, located nearby in Berkeley. I had been seeing some great workshops coming up for the past year but couldn't make things work with last year's busy travel schedule. So, when I saw that Britt Bravo was doing an afternoon Tea, Cupcakes and Creative Blogging workshop I jumped at the chance to go see what kind of community these women (founders: stephanie, mati and tiffany) were creating while getting some ideas for my own writing.

Teahouse Studio is a wonderful, open and airy space. In the front is an open room that the bigger meetings and crafting work happen in. The large back room houses painting, computer and other crafting stations. In between is a kitchen space for the tea and the promised cupcakes for Britt's workshop.

Britt's workshop was set up to be a quick afternoon run at her wonderful juicy blogging material. It was really amazing to be in the same room with 20 other women - all with the purpose of supporting their creative blogging.

The afternoon progressed with a great get-to-know you icebreaker and then moved swiftly into talking specifics of how to keep things moving with your blog. My favorite exercise was a small-group brainstorm on topics for your blog. That was incredibly helpful as the women in my group were diverse and very intriguing

I came away with quite a lot to think about as it has become clear that my diverse interests are making things confusing for the people who read my blog. I'm even going to do a little coaching with Britt in the next couple of weeks to see if we can't shake out even more fun things to try - it's always good to have smart people to talk it out with, who can see the parts of the 360º you miss.

Be sure to catch Britt's Have Fun, Do Good blog, amazing podcasts, veggie cookbook blog and her lovely Instagram photos of the vegan meals she cooks! She frequently has online and in-person classes so if you'd like to keep up with her schedule, definitely sign up for her updates.

After the workshop, I really enjoyed staying and chatting with Tiffany, one of the co-founders of Teahouse Studios. She was telling me about some of the amazing classes they have coming up - including some last minute painting classes that fill up so quickly. Definitely sign up for their updates as well - these folks are doing some amazing work - and the community is really fun. I'll definitely be going back as soon as they have an open painting class.

Teahouse Studios (http://www.teahouseartstudio.com/)
1250 Addison St, Ste 208, Berkeley, CA 94702 (map)
Facebook Twitter: @teahousestudio

I'd be remiss if I didn't point out that the amazing cupcakes from our workshop were created by Suzy Brannon of batter & dough.

DIY: exploratorium AFTER DARK - heartworks

2012-02-15T04:00:33Z

I've been hot on the trail of finding new communities and places to start getting my DIY chops back into my life for the past few months. I was looking at the talented Erik Johnson's (@LEDsuit and artfuture vid) list of places he had shown his amazing wearable interlinked LED technology and saw Exploratorium: After Dark.

Clicking through I was delighted to see that one of my favorite places year's ago - The Exploratorium has found the perfect connection with grown-ups via their themed After Dark series. The February theme was Heartworks and had as its mascots a little figure of a rat tied to a rubber duckie, balanced on a tinker toy extension - obviously a part of some mysterious machine. Nice!

Intrigued to be let loose in the Exploratorium at night and enjoy the exhibits, I didn't hit the Buy Tickets button until the moment I saw the Tinkering Studio and their project - to create a perpetual motion Love Machines Chain Reaction. You mean I get to BUILD something? I'm in.

It was great to get a chance to wander through some of my old favorites upstairs in the sound exhibits and movement exhibits downstairs before my friend arrived.

Once Alexa arrived, we stocked up at the bar and cafe (nachos were awesome) and then had some fun in the color and light exhibits until we were to report for the 2nd building period at 7:30 pm.

One of the most fun exhibits was the interactive video wall. Here's the video that Alexa shot of me moving in front of it. And you can see a more abstract video that I shot while I was moving in front of the wall.

TINKERING STUDIO
We later learned that it would have been a better idea to check in as soon as we got there if we were really intent on doing a lot of building. When we got there the only table left was the very last one - with a duck and a rat. I saw a really thick rope on the goodies table and Alexa found a boot, a ladel and some tall wood. Because we started so late, we ended up simply creating a pendulum that would swing to hit the final two pieces of wood.

I was really stressing out on the last issue of getting the duck to sit on the piece of wood, when Alexa recognized one of the Tinkering Studio volunteers - none other than our old friend Michael Brown (Blue Rain and Playaflies) came to the rescue. It was so much fun to get it working even though it ended up sticking when it's turn came. We did too good a job holding up the duck! Ah well, the magic finger helped it through and on we went to the finale.

Enjoy the video of the entire run of the love machine complements of The Tinkering Studio!

Love Machines at After Dark: Heartworks from The Tinkering Studio on Vimeo.

All in all - it was an amazing evening of play. Thanks Exploratorium: AFTER DARK crew. You did a wonderful job. I certainly will be grateful when it's easier to get over to you via public transit in 2013!

Touch UI: Gestural and mobile prototyping

2011-12-06T06:16:00Z

Continuing on from interaction storyboards and animations, we now separate out a specialized form of protyping where we get the benefit of expressing our ideas for touch-based UI gestures that anyone can immediately grasp and engineer.

A lot of mobile development these days is about being able to iterate on your "here-and-now" product features but it's just as critical to be able to provide blue sky visioning of potential new directions for your product. I've been finding more and more reasons to activate my little tradition of doing animated gestural prototypes - particularly when we're going after money in some of the startups I've been involved in.

Where I might work over lowfi storyboards in some systems, mobile iOS projects in particular tend to move into high fidelity mockups quickly because of the amazing templates that people have provided to speed up our process (i.e. Photoshop, Illustrator, OmniGraffle). I rarely have to animate out ahead for iOS day-to-day feature sets as I've been lucky to work some amazing developers who could prototype directly. But for more risky development tasks such as highly customized components - working in animated form saves at least a few trips down blind alleys.

Below, I played with an alternate scenario for activating the undo action in a text field by drawing a "Z" gesture as a play on Command-Z - the undo command in a desktop environment. I did create a specialized undo gesture for an app that never went live that allowed the person to swipe their finger left for undo and right for redo. I think we should stay creative with non-iOS level system gestures while respecting user familiarity as new gestures catch on. NOTE: this was only created to show an example of this type of prototype with a fairly complex interaction rather than an actual suggestion that I hope will be implemented. After all - think of all those users who will have never related to a desktop computer in a few years :D.

Gestural Templates

I tend to customize and create my own visual language on the fly and thus use a wide variety of styles for these gestural prototypes. But there are some lovely people who provide pre-made templates and content that make the creation of this types of documentation a snap. All you have to do is lay them out so they relate correctly to your interface in your program of choice (i.e. Illustrator, OmniGraffle, Fireworks, Photoshop) and animate them (i.e. Flash, Keynote, Fireworks, After Effects) for a quick check-in on the exact gestures you want to adopt for your project.

Luke W's site: Touch Gesture Reference
A comprehensive document that covers a wide variety of touch interface environments. The page has a few different document types as well so it's easy to incorporate into your own interaction storyboards and animations.

Open Source Multitouch Gesture Library from gestureWorks
I've known this crew since back when they were based in San Francisco and working on exhibits with the Exploratorium. Now they're doing some spectacular work in their open source community driven efforts in the multitouch field.

After Effects Touch Gesture Templates - I haven't tried any of these but they looked kind of interesting. If any of you try them, tell me how they do.

And an oldie but a goodie - Kicker Studio's touchscreen stencils

ux toolbox: interaction animations

2011-11-17T16:00:47Z

As I mentioned in my previous post, if you set up your interaction storyboards correctly, it's a very short road from your static version to an animated one.

Typically my static work goes into some sort of an interaction script format that provides annotation and detail to the stories I'm trying to tell with those graphics. Then it's pretty simple to figure out what I need to animate. If I'm scenario planning, I tend to winnow down to one or two options before I move from static to animated content - saves time and makes decisions simpler with far less changeback as you prevent decision overwhelm. Good way to stay out of that lizard brain while keeping interest high in your feature stories.

My current workflow is using Illustrator to set up my wireframes, mockups and static interaction storyboards and then transferring into Flash or Fireworks to add animation. I may give Keynote a try one of these days as I see a lot of folks finding that an easy transition for presenting and design research. You can see @lukew's interesting write up about how that is becoming his favorite workflow. Personally, I'd miss creating my own graphics on the fly at the same time I'm animating.

Regardless of method, there's nothing like getting objects moving and increasing complexity in your data to shake out interaction questions and details.

Early and often
In touch-based design, prototyping early and often is critical. When your team is deep in coding it's helpful for someone on your team to be able to do quick animated prototypes to speed decision making with stakeholders and check-ins with users.

Using animation it takes far fewer annotations and arrows to communicate most gestures and interactions - particularly if they have complex outcomes. And, in products where it takes a long time to code and physically prototype your interactions, it can save months of programming iteration by allowing early testing of the gestures and actions that are critical to your user experience.

In a few projects I've even done away with complex static documentation - instead storing these animations in a directory for engineering to reference as they build. We even deconstructed a few of them to see how we might improve them when we got to the code environment. That's the first time I've gotten to pore over my animations on a code level in a long time and we all found it to be powerful way to collaborate. Being able to work over your algorithms via animation prototyping - priceless.

I remember a complex mobile project in which I ended up having to add a series of very elaborate video and audio inputs to simulate the complex functionality of the app. The behaviors we were testing were very new to users so it was critical to get into some detail so that the engineers and users understood the problem we were trying to solve - attracting attention for the most critical next action when interrupted mid-flow. A couple of quick design tests later - and the winning solution was immediately evident. Usually, to find this kind of data, you have to wait until you're far enough along to have some fairly complex features up and working. This saved us several weeks of Agile feature iterations. Yea!

Moving from static to animated

Below you can see 3 scenarios from the Nokia mobile product. We began with the static versions to quickly check viability with engineers, asking, "Is that possible" in our scenario planning workshops. Then when we had good directions (met our business goals and were technically feasible) we animated them quickly and threw them on the phone to see how they performed. If they provided good user and stakeholder feedback - the feature was added into an Agile cycle.

Open menu

Navigation carousel (scenario 1)

Close menu

ux toolbox: interaction storyboards

2011-11-09T21:44:50Z

This year I’ve started to show you some of the custom process that I’ve developed. So far we've talked about state of the product reviews, interaction outlines and flowframes (combined wireframes and interaction flows). I’m working on some other posts to fill in more detail on some of the interaction and communication strategies I use with stakeholders and developers but I couldn’t resist showing you some of the items that can be quickly generated throughout your interaction design workflow in design research, scenario planning, team buy in and even blue sky strategizing.

NON-LINEAR DESIGN THINKING
Before I drop you into interaction storyboarding, let’s take a little trip through some of the why and how I developed these offerings.

In the early 90’s I began teaching and working in multimedia. Teaching has always been the fastest and most efficient way to help me learn and organize information. It forces me to create focus, order and simplicity - to make up a structure - and then to find effective ways to communicate that to people that only “hear” information in certain ways. That in turn has been helpful for working in real world situations where a typical day has me collaborating with corporate stakeholders, engineering, user research and marketing - each with a need to quickly understand how the design works. And for me, the more ways I can look at, process and explore data the more nimble I become at coding in and designing for that system.

One of my early issues in teaching Director and then Flash was how to shift learners from linear thinking to interactive thinking. When we teach static graphic design, we’re looking at layout, clumping, white space, color - all issues we need to retain for interaction design but not our sole focus. Even when we move into 4D environments (over time) such as learning video or audio editing, we’re thinking and teaching ourselves how to create linear streams. When moving into creating software UI and/or interactive systems of any type, we need to acquire the ability to understand what static elements we need (2D or visual design), what architecture we need to support data and content flow (3D or information architecture) and how to create the behaviors that will make sense to the user so they can accomplish a task (4D or interaction design).

For 2D we have things like wireframes, storyboards and mockups that communicate and allow us to iterate the visual design. In designing the architecture we have things such as site maps, database diagramming and even code frameworks. In 4D we have scripts, flowcharts, outlines, animations and prototypes.

As I taught designers to code and coders to design it became clear that there had be better ways to communicate across those traditional divides. So I tinkered with some of my traditional documentation and came up with a way to communicate coding, layout and interaction behaviors visually, in a single document that I call an interaction storyboard.

SYMBOL KEYS
Each interaction storyboard has a unique key that contains the symbolic language for the system that you’re working in. Early in my web career I began to use X as shorthand for behaviors that happened on click of a link and XX for double-click. It certainly sped up my teaching. Now they work just beautifully for tap and double-tap. As I moved through different systems the language can shift right along with the actions and behaviors that are unique to the system.

The first example is from a sketchbook in my web/Flash days. Notice the specifics to those systems. The second is for a Nokia touch-based mobile product. It's most useful for showing touch gestures such as tapping, holding, scrolling and flicking the page.

TELLING INTERACTION STORIES
Next is an example of a type of interaction storyboard that I used for my Flash classes called a Go To Structure that allows you to create a simple, divided timeline that the user can press buttons to access. If you spend some time with the interaction storyboard (I used it as a teaching tool) you can see the timeline at the top with indications of labels and actions that create each “virtual” section on the timeline. Then down on the “stage” you can see 3 buttons with indications of what happens on rollover and on selection of each. In this case, when you select button one it tells the playback head to jump to a frame label called “anim1” and start playing. Up on the timeline you can see the label “anim1” and the action at the end of that section that tells the playback head to stop or loop that section.

Can you see it now? Cool, huh? You just read a full interaction ”story“ that explains how to create a non-linear experience on a linear timeline. This is a pretty powerful way to teach yourself to think, see and communicate ”interactions“ to others.

TOUCH-BASED INTERACTIONS
I've transitioned that original language over the years to the new areas I'm designing in. Currently I find it a powerful way to communicate in touch-based systems on mobile platforms such as iOS, Nokia, Android and Windows Mobile. I’ve dropped the coding details and focus on communicating the basic flow through individual actions or agile style feature stories broken down into their component parts.

Let's look at the tap and hold symbols we saw in the key above working in storyboards for a Nokia mobile product. I used these enhanced wireframes as a part of a scenario planning cycle with the product and engineering teams. We decided on feature sets, layouts and technical details, as this was the shift of the product from key interactions to touchscreen devices. It became great shorthand for communicating the new new interaction language for both stakeholders and engineers.

CLARITY IN COMPLEX FLOWS
In this final example we moved from high fidelity mockups in an interaction storyboard format directly into an iOS prototype. Normally, I wouldn’t need to go into this much detail in my mockups and interaction storyboards for iOS design but the team was working remotely and this cleared any confusion on what we wanted to achieve. Then the discussion could move immediately into the details and the best ways to code and create infrastructure to support the feature story.

In my next post I'll show you how easy it is to move immediately into the more powerful use of this type of symbolic language by animating and prototyping touch-based gestures and activities.

stepping into the unknown

2011-10-14T02:00:32Z

Do you ever stop and look around and realize how shut down by "I can't, I shouldn't, I couldn't, I'm not, they're not, it isn't" you've become?

It takes courage to step into the life that our lizard brain is screaming is unsafe, out-of-control and filled with dangerous and unloving people, places and things. And yet, as a designer and a human - it's what's required in every single moment.

My current stepping in is about my work life. I took care of family business this summer. That meant stepping out of my usual continuous practice of "talking to the nice people" in order to line up my next gig. I'm grateful I gave it my full attention and “put my whole self in.”

Now back, I've been out on quite a few interviews in the past two months. Worked a few small projects. Said "No." to a couple projects that didn’t fit. I've created a new resume and even started some great portfolio case studies to help clarify the broad set of skills I use on most of my projects.

That alone was a huge step as my brain was yelling that it was gonna be hard (23 years of experience) and take a long time. It didn't. I discovered a great format to start filling in and then I just chose to iterate. I tried all prose, all bullets, short, long, visual, and verbal (video coming soon). I had tons of plane rides to get it done. Perfect. Look at me still breathing and doing just great - even better for having blown out an unconscious block.

I'm writing and may even have more blog posts arrive here. In other words, I'm firing on all circuits.

But no new big projects. Seemingly no exciting new cultures to explore. No situations that make sense. Yet.

It would be easy to lose heart.

And this time, I've committed myself to really exploring and finding new possibilities. I'm trying and considering all kinds of things I had put into the no fly zone in past years. Full-time job? Maybe. Work for an agency? Probably not a traditional one but perhaps one of the newer "distributed" models might work. Several part-time consulting gigs? Sure. Developing my own products? Sure. Working for folks in other areas of interest? Yup. Finding individual iOS devs and working on projects with them. Yes. Doing DIY projects such as building my own multitouch table and designing software to run on it to see if there is somewhere to go with my whole software/hardware interaction romance. Yes. Speaking at conferences? Maybe. Writing another book? Maybe. Teaching again? Maybe. Acting? Voiceovers? Blogging? Relief cook? Choreographer and dancer? Imagineer? Artist selling my oil paintings?

As I've tweeted, it really does feel like I'm walking around on top of what I'm supposed to be doing. But I'm not "doing" anything I've traditionally thought of as work? So....???

The reality is that every single one of our work lives is changing. There are no guarantees in our jobs. The only recourse I can see is all of learning to step into the unknown and trying things.

DESIGNING INTO THE UNKNOWN
Working in product and UX design we rarely "know" what we'll be designing. We talk to stakeholders, users and experts. But we don't know for sure. We're always stepping into the unknown - and chancing failure with each move we make. Or at least this is what our reactive mind is saying.

Designing into the unknown is particularly true in mobile design. Not only do all of the platforms constantly change features and offerings, they often end up completely changing implementation details between one month and the next. I produced two significantly similar iOS apps with 2 months - and ended up having to do a 2-week crash course in research and deep prototyping to even know how I was going to solve the same issues with the new system - AND retain some level of backward compatibility. Now, I simply dive in and relearn the entire platform for every new project.

EMPTY CUP HEART FULL
The lovely thing is - by emptying my cup first - I learn so much more each time. By not having anything to defend and going to a beginners mind, everyone who has worked with the system is my teacher. I'm as smart as everyone I'm working with and am able to connect all that information. One big, juicy, exploring amoeba of connection. Gross. Awesome. Just like all the best things in life.

I find my job as an interaction and experience designer IS, at it's most basic, to continuously and courageously step into the unknown. To ask questions, be willing to fail, and to be deeply committed to continuing to try things - regardless of whether they "work."

Not for the faint of heart but rather those full of heart - no matter how many times they have to step into the unknown. Patience, persistence and practice.

It's what I'm taking the time to rediscover in my own life. Stepping out of habit and the stories I've grown attached to being so true that I don't have to change or move. Terrifying at times, it's also a total turn on as I slowly unravel years of suppressing what I really want to try - and simply try it.

Mudpies again. Love those.

No. Yes!

2011-07-07T03:45:00Z

Thank you, and no.
I'm confused right now, and until I get clear, no.
I hear you. I care about you, and no.
I don't know yet. Please ask me later.

ux details: co-designing database interactions

2011-06-23T03:10:00Z

A couple of weeks ago I had a developer friend ask me why I was so interested in the database design for a product that we were talking about developing together. That was a bit eyebrow raising for me until I realized most traditional "designers" might not even talk to my friend as they would assume there was no relevant conversation to be had.

Little decisions, big consequences
I first realized the importance of database design to an experience on the web a few years ago when interacting with my favorite nutritional supplement company. While I love their products, I was shocked to discover that they did not require and store (and still do not to this day) first names in their database, nor did they separate out and enable you to send your orders to a different shipping address.

This creates enormous amounts of little, prickly problems. My mom and I both have accounts - same last name, different first names. That was fun until they had usernames that made the accounts unique. She also sometimes ships me products - and this then alters her actual database record - every single time. It then has to be updated manually the next time she orders, every single time.

Be courageous - ask, discover, collaborate, integrate
Perhaps it is more peculiar to those of us that came up through the multimedia and early software years that we ended up having to deal with and learn all the parts of the business, design and engineering as we created products and services. As we're in another start-up boom time, I know many of the people coming into the industry now are experiencing the same collaborative and multiple hats training that we did.

I see that this type of work life provides a certain fearlessness of technical conversations and also asking questions of the programmers and technical folk that create the algorithms, database and middleware for the experiences we are creating. My favorite projects have been those where I get to design and develop simultaneously in tight circles. We work together to discover the best solutions using both the psychology we're aiming at and the technical expertise we have to implement and try iterations and solutions to be tested. Good geeky fun!

know thy database

There are very simple and specific reasons you should concern yourself as a UX and interaction designer with how your database and database communication is designed and functions. In mobile environments, the difference between a snappy and continuous experience of your data, particularly in list-driven applications, is hugely influenced by the push and pull dynamics with your database. Determining how to chunk and deliver the data is a task that is hugely important to the performance of mobile web and custom mobile OS apps in particular.

If you're doing cross-platform design, this is even more critical. I've never met a project that has succeeded across different platforms with a one-size fits all approach to data delivery. Desktop and tablet web experiences tend to require a much more interactive cycle of data exchange in order to appeal to a person's sense of timeliness and things happening safely and efficiently. But tablets in general cannot store as much information at one time - so how are you as the designer going to work with developers to create a strategy that fits your target devices?

Think of a Twitter app. Mostly just lists of data, right? But the difference in how each app delivers that information determines whether you experience them as "broken" or "slow" or if they retain functionality and a feeling of comfort and security even in situations where the data-stream is interrupted.

Data-less and loss use cases
And then there are the powerful use cases that are so often overlooked in database and interaction design - what is the experience like when I don't have data connectivity? Do things get stored locally until they are able to be sent? Where am I going to be storing these "drafts"? How do I best inform the person using the system that they can't get any new data right now?

It was a revelation to see how Twitter for iPhone began communicating breaks in the flow with a torn line graphic. Clicking that line provided immediate load of the missing data (if available). This was also where so many of were inspired to create pull down to get newer messages and pull up to get earlier messages interactions. These are at their core, solutions for database access interruptions peculiar to both the mobile and web in these largely data-driven applications.

Most Twitter apps also retain a fairly large set of on-board data that you can still peruse even if you don't have connectivity. Obviously you can't interact further, but there's something rather appealing to a data-driven app that can retain SOME functionality even when there is no network connectivity.

We can do better
Earlier in this post I spoke of a small company who obviously outsourced their database functionality and development. Even after I interacted with the company, as I really love their products, and wrote several emails to their developers - no changes were made. This just points out how important it is that we educate ourselves as designers on the details of how the shadowy and elusive "backend" works.

I'll keep this a bit shorter today, but other questions that are relevant to the experience are what events cue data being saved to or pulled from the database, how often is that taking place and are there fields to hold the relevant data. If you're going for extra points, discover how the middleware (the code that communicates from the front end to the database) works for your project.

The places that a designer can learn and contribute to the design and strategy of database development are huge. So, get in there and discover all the different ways that your designs and experiences are effected by database interactions and development.

channeling your inner 2YO - why?

2011-04-13T06:15:48Z

I've been reading Tony Hsieh's Delivering Happiness along with a book recommended by my friend Kate Rutter called Composing a Life about stitching together a rich, creative life in the midst of the stream.

Not surprisingly, considering my current reading topics, I've been thinking a lot about how I grow my own work culture - what kind of situations I'd like to be involved in, the people I'd like to work with and the values that I'd like to create and hold to in my life.

Last week, I began resetting a powerful work situation. Before that I took 9 days off and went inside. I realized that I was out of alignment and reacting as if I was a victim to my work life. I notice that I'm not. Climbing out of the reactive, lizard brain this past week I discovered two helpful 2YO behaviors that when applied kindly and asked for gently are helping me begin reshaping circumstances.

Losing connection
A few years ago I was in a volatile situation with a large company. I had designed a complex and vast change to the current system that was divided into stages. I went into a meeting and it was immediately communicated to me that this was too much (before I had even walked through the design) and we would instead do one small item that was on their list. Could I please get those graphics to the engineers?

Hm.

Then the company began reviewing all projects and assigning people to lead them. I was to support all of these new leaders in getting their project proposals put together. One project was handed off to a marketing intern. I went into a meeting and was provided a Word doc with all of the changes that he had. He had taken my design, ripped it apart and put in what he thought was best - basically taking the 4 pages I had and making them all into 1.

Huh.

I did ask if why he made the changes. He explained it. When I began to point out the business requirements and technology realities we were working with he felt they weren't important. Impasse. I was struck in that moment about how an opportunity for engagement was not really possible and I ended the meeting. I did also ask myself (as I became indignant and angry about things) why he would approach it that way. Realistically, with no clear direction and no culture to encourage collaboration and asking questions of your fellow humans - in his mind he was just doing what was asked. Fascinating.

Refinding listening
Later that same year I was working with another company that was shifting their product significantly. They had begun doing design testing and were failing on many levels. Instead of pulling out my arrogance and I know better I remembered how awful those experiences felt - not being asked, talked to or collaborated with but rather minimized and relegated to "just a cog."

I stopped. Contemplated how I wanted to proceed and then immediately began asking "Why?" each element was like it was. Why is this design this way? What problem were you trying to solve? Why isn't this form working the way you would like?

What I got back were amazing stories of how they had overcome problems and historical quirks produced by the people involved.

We laughed and cried. I'm not kidding - it was stunning how just slowing down and being curious about how they got to the current incarnation created a safe environment for all of the unspoken assumptions and story to be spoken, acknowledged and addressed. They had been supressing everything for so long it was like lancing a wound. And the creativity that emerged was stunning.

And most important to me - I was able, as a consultant, to be respectful and collaborative with all of them in making the changes.

It was a powerful lesson that I must say I have not been disciplined in continuing as I get swept up in "getting er done." Well, I remember now and am back with my gentle and persistent curiosity firmly in place.

We all have situations in which we feel belittled and shoved aside. What I'm beginning to look for in my work situations and in the people that I hire is the capacity to move beyond self-involvement and ask "Why?" things are done in a certain way. And after they hear why - do they move in to make their point immediately or are they thoughtful and creative in their response? Will they listen and allow it to change their response?

I've begun looking for the same capacity in the work environments I choose. Are they genuinely curious about me? Do they want to understand the way I think and how I work through things? These aren't required and it's always lovely to be engaged in this way.

I like to think of "why" as a quiet and peaceful way to explore new worlds. A discovery of what's going on that I'm not aware of and a climb out of my narrow assumptions.

Now, there's one other item that my journey needs - a good solid "No."

ux toolbox: flowframes

2011-02-07T05:54:28Z

Flowcharts and wireframes - not exactly the sexiest tools in our kit, are they?

Well most people don't think so, but I have a special affection for them ever since one of my early projects at (Collosal) Pictures required me to create an 18-page flowchart for a project. A Freehand addict, I won points for being able to make a multi-page doc but also for sheer stubbornness in simplifying the system. For me there is very little in my work as satisfying as communicating complexity via symbolic systems that you create from scratch.

Flowcharts have definitely been falling out of fashion in the tech world the past few years. Not only do I see them less and less often on projects, fewer people can actually read them. I ended up putting an audio recording with my flows as a last resort on a project that relied on them to communicate critical decision points for a product. The team and stakeholders were surprised but ended up carrying on the tradition in future projects as they realized that flows and wireframes really are rocking shorthand for communicating architecture and technical details.

Building on interaction outlines from my last post, flowcharts are really great for laying out an overview of a project or potential exploring decision trees within the details of a project. I should point out I don't consider flowcharts a good way to describe user decisions. I find most of the experiences I design these days are about making some good guesses at where to start with people interacting with you. This has made it less productive for my purposes to be able to create airtight user flows in the traditional form. I think visual flows are better for working out what paths you're providing, not necessarily what will actually happen.

Over the years one of my favorite hybrids has become combining flowcharts and wireframes - or "flowframes" as I've dubbed them.

Examples
Let's start a bit traditionally. Here's a flowchart for a fairly old, full mobile OS system I developed a few years back. It's based on a very extensive interactive outline - showing only the top-level items in the system - visually.

It's pretty easy to figure out what the system involves. And nothing you haven't seen before. It doesn't become really powerful until you see the key for the system and begin to understand the depth of what can be communicated via these little tools.

This is a really elaborate example for a huge system but I think it illustrates how powerful custom documentation can become for communicating details of technical design. For instance, the engineer could immediately know that we needed to create a new movie clip for this section or that we needed to make an object that could be accessed at any time from the system for our asynchronous components.

Next we move into the areas that flowcharts, wireframes and interaction outlines begin to meet. As I dive deeper into each layer of info and design on the phone top there's a corresponding wireframe that uses some of the symbols from the key. Then I deconstruct each interactive element on that screen even further.

Animations, button interactions, types of components, key interactions - it's a little nutty how much info is stuffed onto this screen. See how parts of the interaction outline sneak into the detail breakouts to help cement what is being discussed.

And, just because it was the most fun to create and the most intricate use case - dealing with multiple calls - you can see that now we're dealing with the flow and wireframes to communicate both the 2- and 4-D aspects of the design. I love this stuff.

Production
How do I create this style of documentation? For many years I used Freehand as it was the perfect mix of illustration tools and layout features. Now I'm appreciative to have Illustrator allowing me to use multiple pages in a single doc. For me it's critical to be able to create symbols (reusable elements) for my projects. it makes it faster for prototyping and allows me change once across the system speeding things up as I begin to skin and model the prototype. Eventually, I'd like to see a Freehand features such as the ability to make templated pages return - but I suspect I'll have to turn to a tool like Keynote for features like that.

I've tried a ton of other tools including Omnigraffle, Fireworks, etc. but I always come back to the tool where I can quickly collect pixel, vector and custom symbols into a mashup that also has the ability to move beyond a single page analogy easily.

Documentation, design or process?
So what am I trying to show here? As we get less and less time to create documentation, how on earth could something like this be relevant? Good question. I'm not sure what the answer is, beyond the fact that this set of documentation was a part of an iterative build process and communicated a pretty powerful level of detail that and allowed a large team of engineers to divvy up the work and conquer it much more quickly than if we hadn't done a more comprehensive design process.

And as with much of my process, I retain these old-school concepts because they allow me to keep working with large sets of data in different ways. The more ways I can express a system - the easier it is to communicate, build and ultimately to iterate. If you understand a system this deeply, just imagine how much faster you can evaluate whether new features, shifts or removal of features will affect it?

Currently, I still use flows as I design large or multi-modal systems...but they rarely leave the whiteboard and sketchpads or go beyond being used as reminders of what flows and details we're after as we build at high speed. Pictures of whiteboards have become my world of linked together collaborative self-documentation. I'm happy to move beyond documentation as the goal and instead make the creation of the product the goal.

That doesn't mean scribbling out a good flows and spending some time working details in wireframe mode does anything but help your project. And isn't that the purpose of all self-documenting process - to move the design and creation forward or to rule out the features and possibilities that are not currently viable.

This was my 1 sketch for 1 ride day...and yes, that is a flowframe sketch.