Bright Matrices

Writings & musings of Mike Zavarello (a.k.a. brightmatrix), a "red mage" web developer.

Category: UIE Web App Masters Tour

Crafting Your Project’s “Vision Quest”: Thoughts on Jared Spool’s “Turning Back to the Future” Presentation

The closing presentation at this month’s UIE Web App Masters Tour in Philadelphia was “Turning Back to the Future” by Jared Spool. In this session, Jared shared how “successful teams learn about what they should design from their future” by having a shared vision. He laid out several guidelines for crafting this vision: identify who’s involved (the “design agents”), conduct your research, craft your personas and scenarios, script and produce how the final product should appear and/or function, and, finally, impress upon the team the vision of the project itself.

One key point Jared made was that the true goal is not the product itself, which he calls the envisionment, but the overall vision of your product: a shared story and a unified perspective. You should be able to ask every member of your team about your project and have them give the same details of your project’s story: its purposes, aspirations, and triumphs. They should be able to describe the current experience of how your product or service is used, the “aspriational experience” (its next stage of evolution), and understand the research that supports both.

This concept of a shared vision, what I’ve been thinking of as a “vision quest” of sorts, has resonated with me the most since the Tour.  I’ve collected some thoughts, based both on my professional experiences and aspects of Jared’s presentation, on what a “vision quest” needs to succeed.

First, you need a knowledgeable and passionate leader. It could be a C-suite executive who serves as the sponsor of the project or the project team lead, but they must have both attributes. They have to be knowledgeable to indicate the overall direction the team needs to travel in, which milestones need to be achieved, and how to motivate the team to reach their destiny effectively and within a reasonable project schedule. They have to be passionate, so that when they rally, guide, instruct, approve, direct, or correct, they are doing so in a way that inspires the team to attack their work with gusto, learn from the challenges they experience along the way, and feel the surge of delight that accompanies a successful project launch. Oh, and they need to be honest; no buzzwords or business speak. Leaders who speak from the heart and are transparent about their efforts are far more compelling to me.

Second, you need a motivated and inspired team. As a team member for my own projects, I am far more compelled to complete a task with flair when it’s something I enjoy, believe in, and feel holds a higher purpose for the users (whoever they may be). Of course, not every facet of a project is going to be candy canes and sunbeams, but that’s where the aforementioned leader can lend their knowledge and passion to motivate and inspire. Keep rallying the team. Keep them informed of their goals. Congratulate them when they’ve achieved their milestones and counsel them through their inevitable challenges. Give each of them the opportunity to research and develop their own innovations by channeling their individual passions and strengths. Think Google and its policy of allowing their developers to pursue their own interests. By giving them the space to explore and expand their own skillsets, it gives them the ability to bring these feats back to the core project and apply their knowledge to the overall vision. Plus, it keeps them happy, which is always key.

Third, you need a clear and ambitious vision. I’m fully aware that most folks don’t think of the words “inspiration” or “destiny” when working on quarterly strategic objectives and their ilk. But they can and should. This is where the concept of a vision can be stilted or stunted. You hear about corporations issuing mission or vision statements that are supposed to outline their direction and their goals. They’re more fluff than fervor. You can say you want to a “leader” in your line of business, but that’s way too obvious. Of course you want to lead; that’s why you’re here in the first place, isn’t it? To me, it doesn’t serve any purpose to state what’s assumed; we should all strive for excellence. Think about it: you wouldn’t say, “Our mission is to never be mediocre, second-rate, or ordinary.” That’s assumed, too, but you don’t trumpet it to the world. Jared fully acknowledged this in his presentation by citing how specific, measureable goals in a vision stand a far higher chance of succeeding and inspiring the team to action than vague or generic ones. This is where the secret recipe of knowledge and passion come together to make the perfect menu. The specific goals cited in your vision should be crafted in equal parts knowledge (research, personas, etc.) and passion (the user’s experience and your envisionment). Be ambitious. Get it done, and do it right.

Jared had many other key pieces of advice and several clever examples in his presentation, but the “vision quest” is where I wanted to focus my attention with this entry. So, here’s my closing question: have you had a “vision quest” with any of your projects? What led you down the path of inspiration and brought you to victory? When have you seen just the opposite occur? Let’s share and discuss.

Update (6-20-10): Made a correction to one of my opening paragraphs to fix my paraphrasing of Jared’s vision/envisionment, which I had gotten backwards. See the comments for an excellent follow-up by Jared on how team visions can flourish and succeed at lower levels of management and in smaller chunks of an overall project lifecycle.

Some Lessons Learned from Live-Tweeting the UIE Web App Masters Tour

I was lucky to attend the User Interface Engineering Wep App Masters Tour in Philadelphia this week. The event, arranged by Jared Spool and his talented team at UIE, starred luminaries such as Stephen Anderson, Jason Fried, Luke Wroblewski, Hagan Rivers, and Bill Scott. Since I’m a prolific user of Twitter, I decided to tweet throughout the two-day event to share quotes and key points from the presentations with my followers.

I learned a lot during my tenure as “citizen journalist” and would like to share some of my experiences and a few “lessons learned” that I picked up along the way.

Folks familiar with on-the-ground Twitter reporting call it “live tweeting”. You’re basically giving your audience a taste of what’s happening at the event; this can be quite helpful for those who were unable to attend in person. You may also decide to share your own opinions on event proceedings, give instant feedback to the hosts, or share related topics and links with anyone else watching your feed. The critical piece that connects these posts together is a common hashtag. This is either issued by the event organizers or crowdsourced into existence by the attendees. In this case, the hashtag for the App Masters Tour was #uiewamt.

On Day 1 of the event, I hit the ground running as soon as I was seated and hooked up. I let my followers know I would be tweeting from the Tour and blazed ahead. There was a lot of really good stuff the presenters were sharing; I estimated that, at some points, I was tweeting as frequently as once every 40 seconds. I got some complements on my reporting, both from folks at the event and those watching from afar.

Before lunch on Day 2, though, I was made aware that it was getting to be too much for some. One of my followers made a helpful comment asking those live-tweeting from events to use the conference Twitter handle at the start of each post to “reduce noise” in his account. It was a simple solution to put into play and I started to use it immediately. Those already following the conference hashtag could continue to read what I was posting, but my followers were now freed from my Twitter frenzy if they weren’t interested in the Tour. It was a great compromise.

There are two key advantages I see for the “quiet approach” to live-tweeting:

  • You spare others from being bored. If you’ve been chatty on Twitter, you’ve probably accumulated a decent collection of individuals over time. Not everyone may be interested in reading a blow-by-blow transcript of something that isn’t as near and dear to their hearts as you. If you become too boring to them, even for a few days, you might get dropped.
  • You reduce noise pollution. If your followers include you among others they enjoy reading for a diverse source of news and information, suddenly seeing nothing but you in your timeline could become annoying very quickly. I’ve stopped following people who seem to do nothing but retweet all day, every day.

The only thing you stand to lose with this method is the “discoverability” that would be gained from your followers seeing something at random whenever they tune into your posts. That could be fixed, however, by giving them a heads-up on upcoming proceedings (see the third bullet below).

Besides the “quiet reporting” concept, here are some other thoughts and suggestions I came up with for live-tweeting at events:

  • Monitor your frequency. See how often you’re posting once the first presentation of the day is done. If you’re pushing out updates more frequently than once every five minutes, it may be too much for your stream. Consider toning it down, or, if the information is too good not to share, switch to “quiet” reporting.
  • Take feedback, and graciously. Look to your mentions to see what your followers or others are saying about your reporting style and adjust accordingly. If they love what you’re putting out, or getting annoyed by the chatter, they’ll let you know either way. Whatever you decide to do, be prompt and polite about it.
  • Remind your followers about your “quiet” reporting between breaks. If you decided to run “quiet”, give your followers a heads-up on the next session. Drop the event handle so the tweet shows up in their timelines and share some details about what’s coming up next. That way, if they’re interested in that topic or presenter, they can pick up the hashtag and follow along at their own pace.
  • Check in with the event hosts. I haven’t heard of a situation where you’d run afoul by posting comments at an event, but checking in is probably a good courtesy if you’ll be running at full speed. I realized halfway through the first morning’s proceedings at the UIE Tour that I was tweeting two to three times more frequently than another person who represented UIE. If that person had been designated as the “official” source of information at the event, I might have diluted their efforts. Thankfully, the good folks at UIE were very gracious about the added contributions.

I’m looking forward to the next opportunity to live-tweet an event, and hope my suggestions will make the experience pleasant and informative for everyone. I’d like to thank the folks at UIE for, as Jared Spool likes to say, encouraging my behavior.

Have you live-tweeted an event and have helpful suggestions to share as well? Let’s hear about them and discuss; I’m always up for alternate perspectives. I also welcome feedback on my thoughts as well.

Update (8-3-10): Since I wrote this post, I’ve done further experimentation with live tweeting. I followed the advice of either an article or tweet I read earlier this year (and for the life of me can’t remember which it was) and stood up a unique Twitter account to handle live tweets: @noisymatrix.

My strategy so far is as follows:

  • Prior to the event, I’ll announce on my primary account, @brightmatrix, some basic information about the event and when I plan to start posting.
  • Once the event is underway, I’ll shift over to @noisymatrix and start tweeting. My tweets use whatever hashtag has been chosen for the event or seminar.
  • When the session is over, I encourage folks who enjoyed my reporting to follow my primary account.
  • Finally, I compile all of my tweets into a blog post and publish them within a day or so of the event. This way, folks can read the entire recap at their leisure. I’ll announce the blog post on both accounts.

I’ve only done this once so far (for a July 30 Radian6 event on open leadership in social media), but I think this method will be more successful. Stay tuned!

I Had More in Common With 37signals Than I Realized

This week, I was fortunate enough to hear Jason Fried, founder of 37signals, talk from “behind the curtain” about his work philosophies at the Philadelphia UIE Web App Masters Tour.

The talented folks at the Chicago-based web application firm run a tight ship. They work in teams of three to five, depending on the nature of the project (two developers and one designer for standard projects; one extra each for “stack” projects). They work in iterations, with each lasting about two months; at the end of each iteration, the work is either finished, or it isn’t. The teams are reassigned after each iteration so everyone gets to know everyone else’s skillsets (avoiding the “hit by a bus” scenario). Many times, the teams get to choose how and on what they’d like to work. There’s no paper prototyping, sketching (beyond broad, simple strokes with Sharpies), or Photoshop mock-ups; they dive right into interactive wireframes using HTML. There’s no user testing before a new build is launched. 37signals accepts feature requests, but they typically scrap them; most times, it’s only when a specific request or complaint keeps popping up that it gets attention. Overall, it’s an amazing and eye-opening process, particularly for those of us working in larger organizations, where such a culture would be challenging, if not impossible, to institute.

But the true take-away for me that day was this: I had more in common with 37signals than I realized.

For seven years, I worked for a medical publishing firm. I was part of a four-person web team: a director, two database developers, and me: a web designer and front-end coder. We worked on online versions of medical journals and image databases. Our process was generally effective but very informal: no product documentation, no project management, no user testing, no multi-year projects, and maybe two to three formal meetings a year. We knew what was expected, came up with our own solutions, and make fixes and improvements organically. Since there was only four of us, we developed overlapping skillsets so there would be coverage for vacations, sick days, etc.

I never really gave the work philosophy at my old job much thought, but this week it hit me: I’ve had a similar experience to the 37signals model.

I’ve been here before. This was an interesting revelation.

The organization where I work now has a much larger workforce and stronger hierarchy than 37signals. Meetings and project management are part of daily life. Much of what Jason preaches resonates deeply with my colleagues, who can feel burdened by day-long kickoff meetings, rounds of conference calls, and chains of e-mails. They see an austere, agile, and geographically-agnostic workplace, with its stream of consciousness projects and “meetings suck” mentality, as Nirvana.

OK, so I had a variation of their experience at my old job, but I’ve since moved on. What about now? Is the 37signals philosophy scalable in large organizations like mine?

Yes and no.

Sure, meetings can and do suck, but in order to get things moved along at my office, it’s often a necessary evil. You have budgets that span several years and strict accounting rules to follow. You have to be wary of risks to security, reputation, and authenticity. You have to play well with multiple teams from varied disciplines and management structures. It’s not that these things don’t exist in some form or flavor in the 37signals plane of existence, but they’re magnified significantly when the people, roles, and responsibilities carry the weight borne by large businesses. My organization can’t run on 2-month iterations or release new features and services without user testing; there’s too much at stake.

The key word here is the “organization”. The business model we follow is too massive for the 37signals way of life, but not the individual teams within it. That’s where the fast-and-loose lifestyle of the agile development firm can take root. I’ll take one example from Jason’s presentation to show how some of their attributes could be applied effectively and painlessly.

During the 37signals session, one trait quickly became clear to me: there was no e-mail between his teams. None. The folks who work on iterations don’t use it during development. Instead, they use an in-house product called Campfire that allows for efficient and swift teamwork. It’s a threaded, collaborative interface, where comments and features for a unique project are posted in a chronology. Team members can upload images and give feedback; everything exists in a proper order and context. There’s no “hey, did you get my e-mail?” nonsense chatter, crossed wires from team members sending messages over one another, or overflowing inboxes (which people don’t often keep well organized anyway). It lets the 37signals team get changes done on-the-fly, in real time, and with great speed. If individual teams in my company were to adopt Campfire or something similar, it could save countless hours of time spent wondering where everyone was in the development, review, and release of our projects. It would help my boss stay on top of our projects and simplify approvals. It’s less burdensome and not as obnoxious as typical help desk ticket systems. And, since every post is captured and recorded, there’s an automatic paper trail created as you work (which should satisfy the auditors).

Think about it. Wouldn’t that make your day so much easier?

We can’t all be like Jason Fried or 37signals. Obviously, not everyone or every organization can or should work the same way. However, there are a gold mine of innovative and efficient practices in their philosophies that, taken in smaller chunks, can translate into your universe. Replacing e-mail with a system like Campfire, for example, could be an easy victory, and one that I hope to discuss with my peers.

Do you work at a mid-size or large company? What could you take from 37signals that would work for you, or have you already done so? I’d love to hear your thoughts, findings, and stories.

© 2023 Bright Matrices

Theme by Anders NorenUp ↑