Dedicate each designer exclusively to one particular scrum team. They should feel like they are a part of their scrum team and feel connected to that team’s focus. In doing so, the designer’s priorities become clear. Their priorities are synonymous with the team’s, thus enabling them to clearly understand where to expend their energy.

I am completely in favor of dedicated UX folks on an agile team. This breaks dependencies and gives a greater sense of team.

If you are a kanban shop, I suggest adding two queues to the front of your board: "In Design" and 'Ready for Dev".

Also, remember that UX is not graphic design or even information architecture. The work has some overlap, but user experience design involves a lot of thinking, prototyping, and testing.

Don't try to shortcut UX work, or you will get bad results.

Simply imagine, that a customer calls and wants a new ‘take me to mars’ functionality, then wants to know how much will it cost and when can it be delivered, because time is of the essence.
We have never implemented a feature of such complexity (…and most probably never will), therefore I don’t have a clue on the effort needed.
What am I to say? Wait until we implement it and we’ll know when we get there?
Obviously I can not take the “approximate Disneyland wait time” as you call it.
I don’t see it.
Am I missing something?

In my opinion some initial problem analysis and rough estimation is still needed. At least to see if it is doable or not. And I don’t see anyone more competent to ask than development team.

SasHo asked this question about a year ago on Aaron Sanders' blog article on the waste of estimation.

I don't believe estimating something you've never done before has any merits. However, I also don't believe that in general, people come up to you and ask you to do things you have no business doing.

In either case, I'd sooner propose that we spend a month exploring the problem/solution space, and carving out a proof-of-concept that might fit the bill. Not a Minimal Viable Product by means, but a Minimal Approvable Product.

Just a thought.

But since the source is open and available from gitHub.com I simply pulled a version down and tried to debug the code.
And before long I found the solution. SpecFlow (now 2010-12-16) uses .NET framework 3.5, but my specifications were written using .NET 4.0. There are some reflection going on inside the step definition report code and that doesn’t work very well (loading assemblies from different framework versions).
OK – I simply change the .NET framework to 4.0 and compiled myself a local version and tried the command against that version. And ... it worked!

If, like me, you are using SpecFlow to do .Net-style BDD under .Net 4 Framework, you might have been scratching your head about why the Step Definition Report doesn't work.

Well, Marcus Hammarburg took the time to actually pull the source code and figure it out.

Thanks, Marcus!

A lightweight, modular JavaScript game engine to easily produce high quality games.

Includes a large variety of components such as animation, event management, redraw regions, collision detection, sprites and more.

//setup the Crafty game with an FPS of 50 and stage width
//and height
Crafty.init(50, 580, 225);

//create a player entity with premade components
var player = Crafty.e("2D, DOM, gravity, controls, twoway, image")
        .attr({x: Crafty.viewport.width / 2, w: 16, h: 16})
        .gravity("floor")
        .twoway(2)
        .image("favicon.png", "no-repeat");

//create an invisible floor entity
var floor = Crafty.e("2D, floor")
        .attr({x:0, y: 225, w: 580, h: 5});

Run Code

One to watch in 2011 if you're into Javascript game development. A great architecture has been designed, now just depth is needed. But I love the jQuery-like approach to components and extensions.

Hiring: We're looking for another web-app interface designer Jason F. Dec 06

13 comments Latest by Levi Figueira

We’re looking for another excellent web-app UI designer to join our team.

Besides having great visual taste and talent, you must code well-structured HTML/CSS. Basic Javascript or Rails skills are a plus, but not required. Great writing skills are required.

UI designers at 37signals are always working on different things. You may be working on polishing up an existing feature in Basecamp or designing the UI for a brand new feature in Highrise. You may be revamping Backpack or fundamentally rethinking some UI in Campfire. Or maybe you’re involved in designing a brand new product (we’d like to explore two in 2011). You may be asked to come up with something no one has ever seen before.

At 37signals you’ll be working on products that people rely on to get their job done. Your work will impact millions of interactions. You’ll be working with some of the best designers, programmers, dev ops folks, and customer support people in the industry. Our team is top notch and we want you to make it even better.

Our projects are always focused on solving real problems. When the problem goes away we know the design is right. Your job, as a designer at 37signals, is to make our customers’ problems go away.

At 37signals, designers lead the teams. Each development team is made of up three people – two programmers and one designer. The designer also manages the project. In addition to designing the screens/elements, you’ll keep the team focused and make calls about what’s important. You’ll be the go-to person on the project.

We’re not looking for a certain design style, we’re looking for a certain design approach. Simplicity isn’t enough – clarity is where it’s at. You think about how people interpret the objects on the screen. What they think about, what moves them, what frustrates them, what makes them happy. You know that the right design decision can make all the difference.

You’re excited to discover a better solution, even well into a project. You don’t mind throwing something out in favor of a better idea or implementation. Projects at 37signals start with real code. Feedback from an evolving prototype guides the team. While we’re very pragmatic about code, it is important that your design/code is easy to change in response to feedback.

Lastly, you understand that copywriting is design. The words matter as much as the pixels. Great visuals with weak words are poor designs. You should care about how things are phrased as much as you care about how they look.

CHICAGO PREFERRED: Since two of our dedicated UI designers are outside of Chicago, we’d prefer if you were in Chicago to balance things out. If you think you’re perfect for the job, and not in Chicago, we still want to hear from you. We want the best we can find. If you’re the right fit, we’re open to relocation as well. We have an open desk for you in our new office.

How to apply

Send relevant work samples, and anything else that will make you stand out, to jointheteam@37signals.com. Include [UI DESIGN] in the subject of the email.

It doesn’t matter where you went to school, or if you even graduated. It doesn’t matter if this is your first job or your fifth. Doing great work and being driven to improve yourself and everything you touch is what matters.

If we think you may be a good fit we’ll be back in touch with step two of the application process.

Application deadline

We’ll be accepting applications for this position until December 20, 2010.

We look forward to receiving yours.

Everyone should write job posts like this. Who wouldn't want to work for 37signals after reading this?

Job posts shouldn't be bullet lists. They should be love letters.