The interesting common element in this thread is handoffs. It looks like these tools enforce handoffs. If you are doing Agile it should be about collaboratingMessage 1 of 31 , Feb 20, 2011View SourceThe interesting common element in this thread is handoffs. It looks
like these tools enforce handoffs. If you are doing Agile it should be
about collaborating to build a great site or application. UI designs
handed off are often full of assumptions, or are templates. Neither
leverage the full intelligence of the team for the UI's benefit.
How about finding ways to utilize all the brains on the team to create
a great experience instead of just one brain that doesn't have all the
On 2/18/11, Gene Arch <garch@...> wrote:
> At my workplace we just started using Balsamiq in the past few months
> and everyone loves it. Before that, our graphics department would
> create high-fidelity photoshop comps of website layouts before we'd even
> had a chance to review the site structure. Using Balsamiq, a Web
> Designer can mockup the layout quickly and easily and when it comes time
> to design, they hand that off to the graphics people to make it pretty.
> Much better process.
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Marius van Dam
> Sent: Friday, February 18, 2011 5:26 AM
> To: email@example.com
> Cc: uxforhulk
> Subject: Re: [agile-usability] Prototype tools - the pros and cons...
> May i suggest balsamiq? It is very quick and lightweight.
> Good luck.
> Regards, marius
Sent from my mobile device
Robin Dymond, CST
Managing Partner, Innovel, LLC.
Americas: (804) 239-4329
Europe: +32 489 674 366
I disagree with you about the role of tools. For example, if I am collaborating with someone on a complicated budget, I want us to work together not in frontMessage 31 of 31 , Mar 10, 2011View SourceI disagree with you about the role of tools. For example, if I am collaborating with
someone on a complicated budget, I want us to work together not in front of a whiteboard,
but with a computerized spreadsheet on a large screen. I think it would be great to make a more collaborative
kind of spreadsheet, but I certainly want it computerized.
It also puzzles me why you (and Robin) are critical of tools like Balsamiq, calling them "specialist" and saying
they encourage handoffs, but say nothing about programming languages or environments.
I agree that sometimes UI designers want to do too much up front, and sometimes use unhelpful tools. But I might say the same thing about programmers.
In XP especially, I think there is a lot of good concrete advice about how programmers can work differently. I think we
need to discuss what the equivalent advice is for UI designers.
I think people like Jeff Patton and Lynn Miller made a good start some years ago.
And I think much about UI design was on the "agile" track years before that: cross-discipline teams, contextual research,
iterative design, low-fidelity prototypes, and so on. But with the wider acceptance of agile software development,
I now think we have to work out how everything fits together.
I appreciate, and share, your enthusiasm for agile software development. But I think agile-usability still needs work.
On 11-03-09 6:55 PM, William Pietri wrote:
I was definitely not suggesting that low-fi sketching was the best way to work on the design. I don't think there's necessarily a "the design", let alone a "best way" that can be abstracted from local conditions.
The main point I was making in this thread was agreeing with Robin's point that specialist tools like Balsamiq encourage handoffs, and I added that they are less collaborative than, say, whiteboards. I stand by that.
If I were to make some sort of broader point, which is what you seem to be looking for, it's that the places I've seen have less and less use for those tools as they get more Agile. Just last week I visited a place that's releasing daily, has a lot of small collocated teams, and is incredibly productive. They have no use for building up large inventories of design ideas, because they know they can't effectively test a batch of hypotheses that large.
As you might have seen, I think a lot of what people are calling "Agile" these days is bullshit:
It's perfectly plausible to me that in a place where people are building up months of hypotheses (designs, unreleased code, whatever), have poor communication (e.g., distributed teams, large corporate environments), have a lot of stakeholders with the power to say no, pay little attention to the effects of releases, etc, then fancy tools are a big improvement over the status quo. I just wouldn't call it "Agile". It strikes me as akin to the Wall-E scooters for the morbidly obese: great tech, and surely a big improvement, but solving the wrong problem, and doing so in a way that allows the system to get worse.
On 03/09/2011 02:46 PM, Robert Biddle wrote:
By "released", I didn't many any specific one: I would include any that made it out to the users.
You seemed to be suggesting that low-fi sketching on the whiteboard was the best way to work
on the design, and I was just wondering how you thought it should progress from there to shipping software.
On 11-03-09 12:53 PM, William Pietri wrote:
Hi! I don't think I'm suggesting anything. The right process is dependent on local conditions.
I'm having trouble with the phrase "the released design", in the same way I'm having trouble with "final UI design". If we consider Google's search results pages from 1996 to the present, which one is "the released design"?
On 03/09/2011 05:29 AM, Robert Biddle wrote:
The choice of the words "final UI design" was perhaps unfortunate. And even the word "design" has a range of meanings
which can hamper discussion.
But if instead of "final UI design", we consider the UI as it will be released, knowing that later releases will happen, I would be interested in knowing how
you suggest the released design comes about. Do you suggest even that it be done in a team discussion? How does it then get into the software?
With UI designers pairing with each other using UI development tools? Or with a UI designer pairing with a programmer?
This is a practical concern I have seen like discussion about, so I would like to hear what people are doing.
William: how do you do this?
On 11-03-03 2:00 PM, William Pietri wrote:
I'm entirely in favor of the right tool for the job. I agree that all tools have limitations. I'm entirely in favor of spending the time necessary to do a good job.
I also agree that if you have chosen to drastically reduce collaboration by putting physical distance between people, then you may be able to gain a small fraction of that back through tools.
I'm definitely not glossing over the issue that whiteboards aren't final UI designs. However, I do deny that "final UI design" is a notion fully compatible with Agile methods.
A design is our attempt to serve a particular purpose with particular tools based on the knowledge we have. A design can only be final if those things are static. Each release is an opportunity to increase our knowledge, improve our tools, and sharpen our skills. If you are releasing frequently (and for me frequently now means multiple times per week, and often multiple times per day) then if you aren't learning anything, you're missing an awful lot of opportunities.
On 03/03/2011 09:23 AM, Jon Innes wrote:Let me jump in here. You need to use the best tool for the job. Group white boarding sessions serve a purpose. But they have their limitations.
As noted they are less effective with distributed teams unless you hold a non-virtual meeting to do them. As you all know Agile assumes co-location. So do a significant amount of interaction design techniques. The challenge is that many companies no longer operate under that assumption.
I think another issue being glossed over is that a whiteboard sketch does not constitute a final UI design. Part of the job of designing a UI is figuring out the exact details of the appearance (and behavior)and that is impossible to do on a whiteboard, and it's not typically even possible in a wireframe like what Axure or Balsamiq produce.
I've designed a lot of mobile stuff, and there you become keenly aware of the need to spend time doing detailed layout work. As I tell my clients you always have a fixed pixel budget, know what it is and accept it. You can't buy more pixels.
Teams that ignore the above tend to fail pretty quickly. If they are in a big company or an IT dept, they may get a second shot at things. If they aren't they'll have to find other jobs.
Sent from my iPhone
On Mar 3, 2011, at 1:56 AM, "Miinalainen, Petteri" <petteri.miinalainen@...> wrote:
Sorry, if it sounded i argued with that you didn't say. It was reply / my comments to thread - not just you.I did argue that using software can be collaborative. And now i feel that you deliberately missed the point of distributed locations in delivery model. There you really can't use just pen and paper very effectively, but can use some software...Facilitator and all collaborators work around digital sketch. Digital scribe moves things around as requested by participants ("Move this here, we don't need this, could we move this to next screen" etc.).What part of the previous scenario is not collaborative?Facilitation and single "pen" removes certain ambiquities. If you just draw box and arrow and say something that nobody else catches while they are concentrating on something that someone else is drawing. Nobody besides you will know what your marking on whiteboard meant after two days. If you drag and drop table symbol and few second write headers, everybody will understand that.To be succesful with whiteboard, you have to facilitate and manage the situation as well, right? If everyone is doing their own thing it doesn't really matter if it's on whiteboard or in digital form...I'm not saying that digital sketching is the best and only way. I'm saying that sometimes it is only feasible alternative and most of the times it's not so bad when compared to normal whiteboarding.that's my two euro cents,Petteri
From: firstname.lastname@example.org [email@example.com] On Behalf Of William Pietri [william@...]
Sent: Monday, February 28, 2011 11:31 PM
Subject: Re: [agile-usability] Prototype tools - the pros and cons...
On 02/28/2011 05:06 AM, Miinalainen, Petteri wrote:
As to William’s argument that specialized tools are not meant to be used collaboratively, I have to partially disagree. Balsamiq can be used in very collaborative matter. More so than tools that are used for coding. Balsamiq doesn’t require special skills from business side to use, it can be integrated to shared repositories and helps commenting etc especially in distributed projects. Some specialized tools require basic working knowledge of application, but on the other hand help communication. That is one their selling points and I’ve seen many times that interpretation of user story is different until flow of screen is visualized. I could argue that coding should be done on whiteboard, because xyz IDE is not collaborative. Most tools are used alone for the actual execution of work. Planning, alignment and review are done together – that’s why you have scrum meetings, right?
This seems to be arguing with a lot of things I didn't say.
Balsamiq is made for one person to sit in front of a computer made for one person looking at a screen made for one person. It requires you to spend some time getting to know how to use it and its library of stuff. If you think otherwise, you are probably a person who knows how to use it, or who has learned a bunch of similar tools and so considers the effort trivial.
On the other hand, anybody who has made it past 4th grade can join me at the whiteboard and sketch things.
Therefore, compared with a whiteboard, Balsamiq encourages handoffs. Which is all I said.
I am not saying Balsamiq is bad and that people who use it will end up in Agile Jail. I am not saying that all work should be done in massive company-wide simultaneous collaboration as we sing Kumbaya. I am not saying that there is no purpose in ever doing something in higher fidelity.
I just said that special-purpose prototyping tools encourage handoffs and discourage collaboration, which strikes me as such an obvious application of HCI thinking that I don't quite understand why it's so controversial here.
Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini Finland Oy, a company registered in Finland (number 1628142-5) whose registered office is at Niittymaentie 9 – 02200 Espoo.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.