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.
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.
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.
The Clash’s experiments with dub and raggae are some of the most perfect work songs ever. You can shout along with Mick Jones as he breaks down the divide between rich and poor, or just nod your head to the wacked out beat while you push pixels. I played this track a ton after digging up my copy of “Sandanista!” while we were finishing the production cycle for Plinky.
Wolf Like Me by TV on the Radio
The driving back-beat is perfect for getting fired up and rolling up your sleeves. After the fourteenth hour at the office, taking energy from whatever sources you can find is kind of essential. TV on the Radio provides the best and most necessary hit of adrenalin when I absolutely need it most.
As a fan of Rocket From the Crypt/The Sultans/Night Marchers, I’m aware that I’ve got a huge love for a very specific variety of fuzzed out Garage Rock. The Marked Men provide Ramones-fast, bottom heavy and lyrically complex odes to girls, money and other f-ed up situations that I seriously can’t get enough of. This song is off a new EP that I’m still trying to find on vinyl. So. Damn. Good.
Plinky is about to launch. There’s a lot to say about what we built, but I figured I’d say a couple words about the music we actually built it to. Each of these songs are responsible for me spending at least a few more minutes banging on parts of the interface until they worked.
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.
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.
A little more than a year ago, I sat down with Mitch Kapor to talk about the legacy of his Software Design Manifesto. The conversation was part of some research I was doing on a larger topic, one which I don’t think I’ll have time to return to now that I’ve left Adaptive Path. Before my first day at Plinky, I wanted to clear the decks, and get the transcript of the conversation out into the world.
As always, Mitch has plenty of wonderful things to say. There’s a significant history lesson, some pointers on entrepreneurialism, and some very frank perspectives on the principles of design. I’ve edited it a bit for focus (mostly mine, I’m a conversational interviewer, and tend to let topics wander) and broken it out over a couple posts, which I’ll publish in the next few days. I hope you find what Mitch has got to say as valuable as I do.
Interview with Mitch Kapor (part 1)
Mitch Kapor: By way of context, you know, there’s an upcoming conference or workshop being convened by Terry Winograd and people from d.school on sort of software design – they’re calling it technology design now – 15 years later. Do you know about this?
Ryan Freitas: I know that it’s happening. I don’t know all the details about it.
MK: It’s happening in I think the first weekend in June, bringing together many of the people who were there at the original conference. My sort of manifesto was one of the drivers for that conference.
RF: Esther Dyson’s – was it PC forum or –
MK: Well that’s why I gave the talk about the paper. Terry had independently been working on an approach to design that is shared a lot in its perspective and had some differences, but he was writing things, also. He organized this conference with NSF money. He was on his own track. That track became the d.school eventually –
RF: Right.
MK: – but my manifesto was an important stimulus. So I’ve been thinking some about this whole subject in preparation for this conference, and then I gave a talk just a week and a half ago for – what the hell were the name of those people – DSR, Design Science Research, which is another thing coming out of academia with some NSF funding for the Science of Design, that has some similarities and some profound differences, the main one being my approach in the manifesto – and since then – has been to look at things from a practitioner’s perspective. They’re looking at things from an academic perspective.
So… I’ve been thinking about these things. The timing of this interview is good because until I started thinking about things, I would have even less to say than what I have now. So I re-read the manifesto in preparation for all this, and I was struck by several things. The first is it really is of the form of a manifesto and a call to arms, and it’s intentionally provocative in that kind of way. If I were writing something today, I might not write it that way. That came out of my personality and my situation in the world and my history, and sort of my personal narrative as it came out of the situation itself. So that manifesto-ness of it – you could say, “Well was it necessary to write a manifesto?” No. There was a situation, and then there was my response to the situation.
The manifesto came out of a chemical reaction between the two. But in re-reading it, I think the situation that I was describing, the problem, is still very, very much present, which is that software is too hard to use. That is a symptom of a deep problem that has to do with the marginalization of design, then and now.
RF: So you think that trend persists?
MK: Yes. I think there’s been some interesting change and interesting progress, but in the main I don’t see a fundamental change.
*UPDATE* Welcome, VentureBeat readers! More details on Adaptive Path’s work on MySpace and Plazes can be found below. I’m excited to be joinging Jason Shellen and the Plinky team, and looking forward to the challenges ahead. Thanks for stopping by!
So, sometimes, coincidence conspires to provide us with rather tidy ends to the chapters of our lives. Threads come together, tying themselves into a proper bow (or tourniquet, in some cases).
I spent the first six months of this year splitting time between LA and SF, working to get the new MySpace redesign off the ground. The first piece of it launched last week, to a more positive response than I was actually anticipating (what can I say, I’m cautious). And following the successful rollout of the MySpace work, comes the announcement of some good news I’ve been sitting on for a bit: my friends at Plazes have been acquired by Nokia.
So. The biggest piece of client work I’ve ever lead launches to a strong positive response. Then my largest engagement for Adaptive Path’s New Ventures program gets acquired, providing nice validation for the work my team and I did. That acquisition plus AOL’s recent purchase of Sphere (another NV client I had the good fortune to work with) clearly demonstrate the value of the New Ventures program. It was risky and it was hard, but it worked, and I couldn’t be happier.
Every piece of work that I’ve put energy into over the last three years at Adaptive Path has payed out in the last week. I’m a lucky bastard – everything has come together rather neatly, and seemingly just in time.
Friday, June 27th will be my last day at Adaptive Path. I feel I can confidentally say that I have achieved more in my time at AP than I believed possible. I am endebted to the entire organization for their support and friendship over the years, and I will continue to play an active roll in events and the creative conversation as an AP Alum.
There will be more to say about what’s happening next very shortly. For the time being, I just would like to thank everyone I had the grand opportunity to work with at Adaptive Path. It has been an incredible three years, and I count myself lucky to have had the chance to experience it.
My slides from Adaptive Path’s Managing Experience [MX '08] conference are up over at Slideshare.
I’ve realized a couple things over the past year. The big one is that I like to use abstractions to make certain things make sense to myself – and then use them to explain things to others. I also tend to return frequently to my time as a line cook at Aqua here in San Francisco for inspiration. My talk at MX reflected both of these threads.
I took the Glushko and Tabbas paper as a starting point, and discussed service/customer experience design from the perspective of the restauranteur. The needs and capabilities of the front and back of the house must be managed and balanced to provide a complete and compelling experience for diners – something I think everyone struggling with getting front and back stage organizations to cooperate could learn from.
There will be MP3s available at some point, and I’ll link to them when they’re up. For the time being, enjoy the slides. [ed note - image credits are all at the end, Keynote builds all got flattened, and the
typography is Whitney and Archer, both from the inimitable Hoefler & Frere-Jones]
Really quickly, I want to put up a link to the whitepaper I referenced during my MX talk today. Sometime between now and getting back from New Orleans next week, I’ll try to get the slides up on SlideShare, and sort out when the video will be live.
Bridging the “Front Stage” and “Back Stage” in Service System Design
Robert J. Glushko, UC Berkeley
Lindsay Tabas, UC Berkeley
ABSTRACT:
Service management and design has thus far primarily focused on the interactions between employees and customers. This perspective holds that the quality of the “service experience” is determined by the customer during this final “service encounter” that takes place in the “front stage.” This emphasis discounts the contribution of the activities in the “back stage” of the service value chain where materials or information needed by the front stage are processed. However, the vast increase in web-driven consumer self-service applications and other automated services requires new thinking about service design and service quality. It is essential to consider the entire network of services that comprise the back and front stages as complementary parts of a “service system.” We need new concepts and methods in service design that recognize how back stage information and processes can improve the front stage experience. This paper envisions a methodology for designing service systems that synthesizes (front-stage-oriented) user-centered design techniques with (back-stage) methods for designing information-intensive applications.
-
About
My name's Ryan Freitas. More about me and this blog can be found here.
You can find me elsewhere:
My Tumblr image blog
My UX Week 2006 talk on Collaboration at ITC Conversations
My "User-Centered Design for Evolving Products" presentation from Future of Web Design 2007
