Archive

Archive for the ‘work’ Category

Show & Prove

March 9, 2010 Leave a comment

I did a very fast 5 minute presentation at Adaptive Path’s Managing Experience (MX) event yesterday on the importance of incorporating data-driven design into how design teams handle tactical problems. Video should be coming soon to the MX ’10 site, but here’s the slides:

Categories: bigidea, work

Registration: Step One

February 10, 2010 Leave a comment

An image gallery of the first step in eight new-ish sites’ registration processes: The Hype Machine, The Sixty One, Later Bro, Foodspotting, Quora, Typekit, Glitch, and Times People.

Categories: interface design, links

GigaOm Redesign Launches

November 24, 2009 Leave a comment

Om announced the launch of the GigaOm network redesign last night. Congratulations to Om, Paul, Jaime, Shane and Peter, and the whole GigaOm team! I was delighted to help out with the redesign, and I’m even happier to see it live.

GigaOm redesign

The redesign gave me a chance to work closely with friends old (Jaime Chen) and new (Shane Pearlman). Starting with some up front research, we solicited and consolidated feedback from editors, the ad sales team, and Om and then translated it into achievable goals for the redesign. We worked to hammer out the universal elements of the interface that we could distribute across network properties, prioritized functionality, and laid out content in a way that presented it in the most readable, attractive and engaging manner.

The redesign looks sharp, and that is entirely due to the heroic efforts of Jaime and the sheer talent of Shane and Peter. It was a real pleasure to work with such a dedicated and capable team. I’m very happy to see all their hard work pay off.

Categories: launch, work

The Empty Box Problem

January 22, 2009 8 comments

In 2008 I left Adaptive Path to help Jason Shellen design and build Plinky. As our launch approached, a few people have asked me what I’m trying to accomplish with this little web app we’ve built. My answer is that we’ve got a few goals. But mostly, I wanted to try and solve what I call the Empty Box Problem.

To me, the modern web feels like a collection of empty boxes:

“Write a blog post – here’s an empty box.”
“A comment? Have an empty box.”
“A status message? An email? A tag? Your box, sir or madam.”

For writers with plenty to say, the empty box is no real obstacle… most of the time. I’m of the opinion, however, that there are a wealth of people who don’t write as much as they’d like, or at all. Perhaps they’ve hit a creative rut, or they are stymied by the complexity of even the simplest of blogging services. In designing Plinky, I was attempting to help writers get over this hump by providing the inspiration and motivation to create content.

The idea was to give people a prompt to respond to (a question, challenge, or poll of some kind). The Plinky team wanted to switch up how content generation is elicited, and see what impact it could have on those who wanted to share their voice online, but maybe needed more impetus to do so.

When we did our initial test run back in November, we found that prompts and answers are weirdly social – people have a really strong interest in how friends and strangers responded to the same prompt they did. Our preview audience made a list of demands: reduce steps here, make this thing over here more straightforward, and absolutely make it easier to see what other people are doing.

This proved a challenge, because our emphasis was always on production, rather than consumption. This is evident in the logged in user home page – where many dashboards are moving towards activity streams, we want to keep the emphasis on the day’s fresh prompt, and encouraging users to respond to it.

Exposing more of the activity on the site will be part of Plinky’s evolution – which I already know will be significant. There are a ton of things I want to do, even before people’s feature requests start coming. Encouraging users to create more by giving them informatics of their own writing behaviors, harnessing group behaviors, integrating with more services – there are many potential directions to explore, and I’m really looking forward to the challenges involved with bringing them to Plinky.

plinky

Building Plinky, and working with this team, has been a fantastic experience. I’m hoping our hard work shows through in what we’ve launched today, and that people are down to see where we can take this new idea.

Categories: plinky, work

The Credit Reel

January 22, 2009 Leave a comment

I’m a fan of giving credit where it’s due, and so I’m happy to proclaim my gratitude to the following people for everything they did to make today’s launch of Plinky possible. The last few months would have been a hell of a lot more difficult without their help, support, kind words and advice.

The style council: Mike Monteiro, Erika Hall, Rebecca Bortman, Lori Chambers & Ryan Hoguet at Mule Design

Huge thanks to the gang at Mule for creating the unique and wonderful look of Plinky. You guys were the first to really get enthusiastic about what we were trying to accomplish. Thank you for all your help.

The muscle: Chris Wetherell, Ryan King, Dave Le and Matthew Levine

Three cheers for the guys who lent a hand during our crazy production cycle to beef up the team and get things from design to built in short order. You each did a hell of a job, and we were glad to have your assistance.

The advisors: Biz Stone, Maggie Mason, and Vanessa Fox

You couldn’t ask for better advice on product, content, audience and intelligent SEO. I especially want to thank Maggie for her sharp eye and commitment to the core idea – she provided a valuable perspective as our ideas around audience and offering evolved.

The Plinky team: Jason, Wes, Grant, Corinna, Michael, Zack, and Sim

East Bay represent. I hope y’all already know, but you rock. Nice work.

The support system: My (amazingly patient and lovely) wife Kristen, my brother Richard, my mom and dad, the guys at Small Batch, old colleagues at Adaptive Path (esp. Rae, Brandon, Henning & Dan H.), Jody, Dan and Jen at Kicker Studio, Liz Danzico, Adam Greenfield, Kristina Halvorson, Brian Oberkirch, Ryan McCormack, Matt Jones, Laura & Tej and everyone who agreed to take part in the preview in November (but didn’t agree to get follow-spammed by He Who Must Not Be Named – my bad) *

Each of you did or said something that helped me keep my shit together (or gather it back once I lost it) over the past few months. I’m in your debt. Thanks.

* If I forgot anyone, I apologize – please recall I’ve been up since last Thursday.

Categories: plinky, work

kirby comics and myspace

August 28, 2008 3 comments

So, I got some good news today:

MySpace’s June redesign is proving to be a turning point in the social network’s effort to monetize its 118 million eyeballs. National brands are flocking to new advertising opportunities on the home page, making MySpace the top site in online ad views last month, according to Comscore.

The June redesign streamlined the home page and placed a large ad space at the top of the page. It offers splashier video ad placements with interactive elements that can move throughout the site.

As I announced two months back, I’m no longer doing client design work, focusing instead on my role as Director of Product design at Plinky. But the Myspace redesign (which includes work that hasn’t launched yet) was my last major engagement as an experience designer at Adaptive Path, and I’m very happy to see the success its had with users and now advertisers.

So that wide ad unit at the top, that spans all the way to the gutters? The one that affords a whole bunch of different ways to present ads (for tasty, tasty bacon) and marketing messages?

My rationale for the design decisions on the home page included making efficient use of screen geography, reducing the amount/increasing the impact of advertising, and providing opportunities for feature marketing and discovery… but really, the whole time I was thinking about this:

Jack Kirby’s use of double page spreads in his comics blew me away as a kid. Huge panoramics of New Genesis, amazing action shots of Capt. America taking out what appeared to be hundreds of Nazis singlehandedly, or the above assault on Camelot from the Demon origin [image borrowed from the Kirby Comics blog] – the sheer impact of those scenes have stayed with me as an adult.

Effective design work is full of unexpected influences. When I proposed what I termed the “widescreen” element at the top of the MySpace home page, I was thinking of double page spreads, and how effectively they’ve been used by artists like Jack Kirby (and more recently Mark Millar in Marvel Comics’ Ultimates) – they capture the attention, communicate volumes, and ultimately (heh) stand out far more than your average 9 panel page.

I need to thank the MySpace team for taking a chance, and my friends at AP and Sequence for turning my simple descriptions of how it worked into something awesome.

I’m just chuffed that it actually worked.

a (very long) conversation with mitch kapor (part 2)

July 8, 2008 1 comment

Find Part 1 here.

RF:    Within some of the analysis that I’ve read of the manifesto, there is discussion around the natural disinclination (or the natural distrust) of people in the engineering field towards those in the design field. This trend persists, obviously, but has it gotten worse?

MK:    I don’t know if it’s gotten worse.  Based on just my experiences, I don’t think it’s gotten better.  I mean, except insofar as there is a recognition, albeit sometimes a grudging one, that it is regular people who use the stuff, and that the more self-aware engineers understand that their preferences as to how to do things are not the ones that should be automatically applied.

RF:    Right.

MK:    You used to fight that all, “What’s the matter with this?  I like this just fine.”  I think you hear less of that but you don’t – I think there’s still a distrust because the engineers will go, “Well these people just don’t understand how things work.”  Then there’s also problems just of communication, of designers and engineers not speaking each other’s language, not having kind of a common framework.  So even when there’s a good designer and making valid points, if there isn’t a common language they won’t be understood and they’ll be disregarded.

RF:    Have you seen examples of teams that are able to communicate appropriately?

MK:    Well yeah.  Well the ones that I’ve been involved with, it’s hard but I’ve seen some successes.  Some really great engineers have much more of a design sense and an openness to it, and others don’t.

RF:    In the manifesto you said computing professionals themselves should take responsibility for creating a positive user experience.  Once again we’re back to the user experience not being –

MK:    Right.

RF:    – but you were seemingly not just advocating for the software designer, but for engineers to step up.

MK:    Yeah, because what they do is part of a larger whole.  An over-focus on their particular specialization actually hurts the greater undertaking.
I mean, it’s just sort of a standard thing in business, like the purpose of the sales force is to sell stuff.  It’s a problem of a local maximum.  The sales force needs to understand why it’s selling things and how much, and don’t oversell.  Well, don’t over-engineer and understand that you’re part of a team where it’s the value being delivered to the customer that is the important criteria, so there’s a kind of an insularity in engineering.  Look, some engineers, they just have great development skills and low social skills.  They shouldn’t be asked to do what doesn’t come naturally and they don’t want to do, but they also should understand that they’re yielding power and responsibility for certain things.  They’ll have less power as a result of that.

RF:    And that’s probably best understood on both sides of the equation, on design equation as well.

MK:    Right.  Yes.  That’s right.  You know, the other thing I would say is that in most software development organizations and projects I’ve seen, the power relations that are always very implicit.  I mean, there’s an org chart but the decisions that actually get made never happen by an org chart.  But they’re also just not very explicit, things sort of happen.  Unless you’re in the project day to day, you can’t even tell.  The problem is that that tends to – those systems, when there are these implicit power relations, there’s a fragility of the organization’s functionality that results because if there’s a problem, or a dispute or a disagreement, because everything is implicit people don’t have the tools to actually talk about engaging a good process for resolution.  This is a subject I don’t remember talking much about in the manifesto, but part of the issue of producing good software is – good software is produced by good organizations.  By organization I mean everything from the initial corporation to an open-source movement.  They have very different organizational structures, more centralized, less centralized, you know, and so on and so forth.  But they all have power relations, they all have governance, they all have –

RF:    In a sense, maybe not explicitly within the manifesto you’re not arguing for organization but you are implying your vision at the time of that alignment between the sole author –

MK:    Yeah, I mean, when I was talking about the heroic.  But there’s a deep mystery which is great things get done when there’s highly productive collaboration, and great breakthroughs in innovations tend to come from individuals or very small groups.  How do those things fit together?  That’s a deep mystery.  I think that that’s something that gets wrestled with but never solved.

RF:    So there’s no formula, it just happens somehow?

MK:    I certainly believe there’s no formula.  Whether there are even principles that you can rely on, even though the principles may sometimes be in conflict with each other, is itself I’m not sure.

RF:    You, as an entrepreneur, have dealt in situations where you’ve got huge wide distributed teams working on things, and also very focused, very small teams.  Where do you feel more comfortable?

MK:    I like the small teams better but I think it’s also good to work outside of one’s comfort zone.  Look, software is hard to do, still, and seeing the OSAF team and me being delicately pinned like a butterfly to the – you know – and dreaming in code was really quite painful at times because I look at that and go, “Oh yeah.  Didn’t really know what I was doing there.” and had paid the price.
Do I like small teams or large things?  Right sizing ambition is incredibly important.  That was one of the major problems with OSAF.  This is in this sort of organizational leg of the software tripod, if there’s design and development and then how you organize the whole thing.  Because we were simultaneously trying to innovate very dramatically, and also do something that could replace a product in a mainstream category.  It was just too much to try to do all at once.  It was sort of like – and this only became apparent to me and us in hindsight.  Knowing what I know now – of course it was different, there was a real learning – I haven’t done any real hands-on guiding of projects in rather a long time and so my eyes were bigger than my stomach.  One of the lessons there is if you want to do something that is highly innovative, don’t also try to assemble a large team to do a big thing.  That’s a very bad mixture, almost doomed to failure.  I’ve been running into people that used to work at General Magic, that was a similar experience for them.

RF:    In terms of kind of self-representation in the manifesto and your experience since then, do you see yourself in your role on larger teams or smaller teams as something resembling a software designer, or trying to –

MK:    I hope so.  If not that, I’m not sure what.

MK:    Really?

MK:    I mean it’s a product design.  I’m an entrepreneur so I have the responsibility for the undertaking as an enterprise or project either for-profit or non-profit.  I’m also typically the financier because, although not necessarily the sole financier, I’m in the fortunate position of being able to do that.  The thing I love to do the most and my very significant value-add is in the overall conception of the product design.  I have found that actually products other than very little ones – like the Foxmarks extension – are sufficiently complicated and I’m sufficiently busy that things come out much better if I delegate very heavily to keep people I work with to do the details of the design and to work it out.  So I’m probably reinventing what other people have done all along.  I’m trying to figure out how to leverage myself.  You know, the Foxmarks extension, Todd and I designed it.  But I not only had what the concept should be but there were a lot of discussions about, “Well what’s the overall experience?”  So the idea that it becomes invisible once you install it is one of its principal affordances.  I was just incredibly insistent that as a bookmark synchronizer it should just get out of your way; you shouldn’t even know that it’s there.  We did a lot of things to –there were a lot of decisions that followed from that, both in terms of how it actually worked in the background, and its visual appearance.  I was driving that so if that’s not design, I don’t know what is.
That was the role that I had in Lotus 1-2-3.  That was the back-story – and I don’t remember how much of the back-story is in the manifesto.  Probably not.  It’s probably elsewhere.

RF:    From your collaboration with Jonathan Sachs?

MK:    Yeah.  The back-story is Sachs and I did this product, not in an introspective kind of way.  He did what he did, and I did what I did but it was like words and music.  I mean there was a very distinct separation of roles there.  I was the designer. So the problem I had was after Lotus became very successful, people didn’t understand what I did.  Not in my role as the entrepreneur or CEO but in the conception of the product.  They thought, “Oh, so you did the marketing?” because there wasn’t a pigeonhole for what I did.  I’d say, “No, I didn’t write any of the code.  No, I didn’t do any of the technical architecture.  In fact, I never looked at any of the code.  I don’t know what data structure Sachs uses to represent the formula change.  I have no clue.”  People were just not – they could get as far as product marketing where you wrote what the customer requirements were.  I said, “No.  That was part of it.”  But I actually said, “It’s very important that there be very tightly integrated graphic because people have their spreadsheets, they got the numbers, they got the graphs.”

In the previous generation with VisiCalc and VisiPlot, it was two separate products, a very laborious process that actually involved writing out an external file and rebooting your computer for the VisiCalc’s copy protection to load up VisiPlot, and then exporting the external file and making the graph.  I said, “This is nuts.”
I said, “The opportunity is here’s the spreadsheet, make the graph.”  But then, I mean a lot of things, I didn’t just leave it there.  It was, “Well, okay.  How do you do that?”
So the genesis of the design manifesto was really an attempt to legitimize myself and to explain to people what I actually did in the product.  I was doing it in 1983 and 1982.

RF:    You’d been doing it for a decade by the time you wrote it and –

MK:    That’s right, and now I’ve come back to it.  In fact, it goes back even further than that.  So Lotus was like 1982 – was when we were developing the thing.  I first put my hands on a computer 15 years before in high school, 1965, 1966.  It was immediately apparent because I was very good at math and I loved numbers, and had tons of facility.  But I really sucked as a programmer in comparison with people that were good programmers.
I knew that.  It was just evident to me.  But I sort of felt like this affinity and that I had something to offer.  It wasn’t until PC’s came out, so it was the mid-1970’s – that I began figuring that out.  But it was the being talented at things computer-ish but not in the act and art of actually writing code.  That’s what essentially gave rise to all this.

RF:    One of the questions you ask yourself in the manifesto is what makes something a design problem, and in doing so you refer to that intersection between technology and human purpose.

MK:    Yeah.  Yeah.

RF:    Do those things still hold?  Are those still kind of the two qualifiers for whether or not a design is really where that’s going to get solved?

MK:    As far as I can tell.  That’s kind of like a postulant.  You evaluate its utility based on assessing the consequences of holding that postulant.  It’s not true in and of itself.  It is true or it has value insofar as what you conclude from that postulant and everything else you believe kind of accords with things.  So I just did a generalization.  I asked myself.  I looked at industrial design, graphic design and the then other forms of design, and architecture and software design.  I said, “What do they have in common?”  It seemed to me, obvious on inspection, as they say in mathematics, that in each case there were some material or immaterial substrate stuff – bits, atoms – that were the media within which creations were being realize of some kind.  But they were all directed and driven by what it is people wanted and needed.  I mean it just seems so obvious.  So the answer is how could it not be true?  I guess the only thing to be said is, well there could be another perspective that is so much more relevant that you would say, “Well that’s true but not very interesting.”
It’s axiomatic is what I’m saying.

RF:    We had a gentleman come in last week, a guy by the name of Brett Victor.  He contends there’s actually no such thing as interaction design, that there are matters of input, which is industrial design, and there’s a representation, which is graphical design.  Everything else should be – those two should take care of everything else.

MK:    He sounds like he should meet B.F. Skinner or converse with the ghost of B.F. Skinner.  It’s all inputs and outputs.  There’s nothing going on in the middle.  It’s sort of neo-behaviorism.

RF:    Right.

MK:    So what I would say is that’s not even worth a cup of coffee.  The other interesting thing is that when it comes to – I mean, maybe he’s saying something more interesting than that.

RF:    Another point you make in the Manifesto: software is hard.  It’s hard to build and it’s hard to use. There is a certain vogue for simplicity for making things smaller, like you said, curtailing – not ambition maybe, but –

MK:    Small pieces loosely joined.  Yeah.  Right.  That’s good.

RF:    Do you see that as potentially solving some of the issues around –

MK:    Just for a while.  I mean the fact of the matter is that operating systems are big however you build them, or don’t build them.  I mean, you know, some needs are just large.  But if you can satisfy a human need by doing something small, or connecting a few small things, that’s great.  That will solve a bunch of things.  But there are some needs, like cities and big public civic works and power distribution, and how we’re gonna manage climate change.  I mean there are big problems and issues, the vogue for simplicity can be overdone.  I mean, small is beautiful but fine – Einstein said, “Theory should be as simple as possible but no simpler.”  So that’s probably the operative wisdom about that.