My company loves Photoshop comps. Way too much. I know this and yet, to some degree, I’ve enabled it.
It’s not original of me to say that static mockups are misleading and often unnecessary. 37 Signals fairly shouts it. It’s also deep in the agile spirit of conversations over contracts.
Still, in a company with design approvals and a history of handing down information architecture to developers it’s tempting (I’m tempted) to ward off complications by cooking up visuals that are irrelevant, obvious or subject to change, “pushing pixels that won’t even exist later.”
At first, you create formalities around your agile process to protect your team but with success you get opportunities to teach by doing — to demonstrate work is unnecessary by not doing it.
All this hit me today like it had never occurred to me before even though I’d read, thought and said some variation of it so many times I should have put music to it by now.
We’ve earned some trust. As my team starts building our first web products for our company, I think it’s time to end our infatuation with 800×600 jpegs.
Just posted a reply on the Scrum Developers Yahoo Group. Keeping up with that list would be more effort than becoming a certified scrum master.
What I am interested in is to find out how graphical and interaction designers can be eased into Scrum development.
In my previous team, our UX director, Bob Calvano, mixed in with the team: proposing UI elements in mockups but also pairing with developers to collaborate on implementations. The team and UX director shared decisions but the UX director retained authority over them.
The team and product owner learned to defer to him on thorny questions of emotion, aesthetic and interaction particularly where the product owner had no clear sense of how the decision impacted tangible customer value.
The team had to learn how to deliver constructive feedback on UX. They had to learn how to express personal opinion in that context.
The UX director needed incredible patience taking in well and poorly delivered feedback. He had to understand his own process well enough to use day to day input to enable his own creativity rather than shut it down.
We evolved this relationship in a small team in an environment of high trust and we took months getting there. He came from a more traditional agency approach but he did have a personality suited to collaboration.
He eventually left our team to become an Interaction Design Director at one of the top agencies. He did so because the high profile of the work and pay were irresistible, so this experience didn’t hurt his career progression or his ability to work other ways. Though I know for a fact he misses that team and is returning to a smaller environment where he can recapture that collaborative experience.
thoughts from people who have read Jeff Patton’s book and what they think about how his ideas fit with Scrum.
Haven’t read the book yet. Talked to Jeff about his ideas at Agile 2007 (He was my adviser on my presentation on product ownership) and at the Fall Scrum Gathering.
High praise for his thinking on user experience as a precursor in product development (why) not simply as part of execution (what).
We tend to focus on story writing as the first tangible step agile plays in product conception. There are whole worlds of collaboration in terms of understanding who the software is for and how it solves problems for human beings that should come first.
Jeff Sutherland says the vast majority of teams run Scrums without real backlogs. How many of those few product owners that have backlogs derive systems and features from a user-centered perspective?
Hoping Jeff Patton will give us practices to tackle that problem.
I am convinced it is the role of product owner or customer that needs the most work in our evolving agile practices.
Sponsors express their desires as feature requests. But, as Alan Cooper argues, there is no linear progression from what people need, what they perceive they need, and how they express that in language.
At the same time, supporting departments, customers and management want a commitment to a scope and schedule. And in response, the team wants methodical decomposition to estimatable stories.
And so product owners dive into story writing, decomposing software into smaller bits in order to grasp the whole from the details. But the resulting release backlog looks only slightly more nimble software requirements specification and only slightly better at describing what customer’s really want.
What if regardless of our initial input from customers, product owners took Jeff Patton’s advice and focused our initial backlogs on specific, desired and attainable end user goals — not on interactions but why they are valuable to users? What if themes were something other than a less granular stories?
Could we retain this focus through release planning by sizing these themes not by committing to a single path and simple decomposition but by a more complex matrix of possible implementations, classifying how effectively those implementations might meet the end user goal?