Tag: process

Nice. Lots of sage wisdom encapsulated here. It’s certainly way more instructive and useful than the UPA’s “Designing the User Experience“ poster.

The Etsy Team:

We deploy a lot of code. Deployinator is our creation to make that as easy and painless as possible. Deployinator is a one button web-based deployment app. Hit that button and code goes to our webservers and is serving requests in almost no time. Using Deployinator we’ve brought a typical web push from 3 developers, 1 operations engineer, everyone else on standby and over an hour (when things went smoothly) down to 1 person and under 2 minutes.

Even if you’re a designer, a process that allows you to push to prod anytime makes life and work so much better.

The single most important skill a product manager/designer/guy/girl can have…

Aaron Swartz:

There are three questions you have when you’re hiring a programmer (or anyone, for that matter): Are they smart? Can they get stuff done? Can you work with them? Someone who’s smart but doesn’t get stuff done should be your friend, not your employee. You can talk your problems over with them while they procrastinate on their actual job. Someone who gets stuff done but isn’t smart is inefficient: non-smart people get stuff done by doing it the hard way and working with them is slow and frustrating. Someone you can’t work with, you can’t work with.

Good advice to start, and he’s got more where that came from. Some of it would be different for designers, but a lot of it holds for any position, at least in our industry.

Amy Hoy on interface patterns and pattern libraries:

Consider creative writing, which is a much better parallel to interface design than architecture. When you write, you can do anything. You choose words, rhythms and structure to communicate your ideas, not just what you say. You still need to hold up a coherent thread, and help the reader to follow along, just like with a good interface design. But you have, as it were, endless possibilities when you face the blank page.

I think Amy’s spot-on here. Patterns are the fallback for interactions when you don’t have anything better, but shouldn’t be the initial go-to.

Oliver Reichenstein at Information Architects Japan seems to define the UX field as the generalist discipline I have been advocating.

Can’t say I’m necessarily inclined to disagree, but many of the UX professionals have a skillset in alignment with information architecture, which is more design-focused. In order to truly be at the center of the process, the person negotiating these concerns needs a background in all of them.

Still, in the end, Oliver takes a pragmatic approach:

On the other side, whether you perceive a job as dull or fun largely depends on your character. Some people love organizing, others, like me, love to create chaos. Some people, for instance, actually hate to think, and that doesn’t mean that they’re necessarily stupid. The trick is to create teams where everyone does what they like most. Making work fun seems to be the same challenge as making different people work together.

Benjamin Pollack, who works with Joel Spolsky and the StackOverflow team, responds to a Hacker News thread suggesting that SO could be copied in a week.

On the part where he’s suggesting that developers only think of sites as database schemata:

Even if I didn’t know better, I would guess that very little of what actually makes StackOverflow a continuing success has to do with the database schema—and having had a chance to read through StackOverflow’s source code, I know how little really does. There is a tremendous amount of spit and polish that goes into making a major website highly usable. A developer, asked how hard something will be to clone, simply does not think about the polish, because the polish is incidental to the implementation.

It’s the smart developers who realize that simple concepts often take a lot of work to implement well, even if they can be quickly implemented poorly. I’m glad I work with smart developers.

A beautiful article from Rands/Michael about getting it together in a crisis, and then making progress based on that experience. A little bit about communicating with employees, a little bit about running meetings, a little bit about staying same, and a lot about being a great manager.

Naresh Jain comes to similar conclusions to my talk about Agile last year, with a somewhat different angle. In the end, as he says:

Bottom line, Agile is not a Silver Bullet and don’t fall pray to marketing gimmicks. Question dogmatic claims. Adapt Agile to your needs and take baby steps.

I also like his line in the slides: “Agile coaches and project managers are becoming the process police.” Kinda the antithesis of the Agile notion of people over process, eh?

This Boston.com photoessay shows there’s often a lot of hard (and often boring) work that goes into making such a useful process seem so simple.

My friends up at Happy Cog are redesigning Mozilla.org, and like Mark Boulton’s Drupal Redesign, they and Mozilla are opening the process up to the public. Right now, you can see a pretty large body of work behind three general design directions.

I can’t wait until I have a project that calls for this kind of transparency during the process. It seems to me to be a win in at least two ways: everyone gets a say, and yet since it’s hundreds or thousands of people, it helps stakeholders keep perspective better than when it’s twelve people around a table.

This is an awesome look back at an epic skunkworks project at Apple, and reminds us what makes software really great: a good idea that “doesn’t suck,” motivation, late nights, talent, smart friends, a little bit of internal marketing, a good user feedback loop, and a bit of luck.

IDEO is working with BUG Labs on a fairly quick exploration of a redesign for their popular hardware prototyping tool. It’s always cool to get to see the work IDEO does.

The most interesting thing about this is that they’re blogging about their deliverables publicly as the process is underway. I’ve been hoping to land a project that would benefit from this kind of public exposure, getting feedback from real users throughout the course of the process.

I think that feedback could very successfully augment or replace many aspects of a big user research process, with a potential to do so with a much smaller budget and time commitment.

Jared Spool posts an interesting set of conclusions about how design teams work.

At Viget, we tend to focus on the latter three: genius design, activity-focused design, and user-focused design. Of course, unintended design probably happens in all projects to one extent or another. How those three types fit into the projects really depends on the needs, timeline, and budget of the project.

On my own, I hope most of it falls into the genius and activity-focused categories. I don’t really do user research to any real extent for personal projects, except for informal bits here or there, and it’s certainly all low/no-budget.