RE: [agile-usability] business reqs and ucd
- Age old problem - cost. You can either do eveything that is needed at variable cost. Or then you can do what you can with fixed (low) costs. Your just can't have them both.I can offer only some practical advice on how to keep your workload/ cost as low as possible - and you should take with a grain of salt!Things to consider:-explain that you cannot fully take responsibility on usability of the finished product without necessary steps-explain that fixed cost must be based on your estimate (otherwise you can only do as much as the money lasts, unless this is strategically important client)-explain that you want them to sign-off on some draft of the IA design. *And that things not included in the draft are not included without extra cost/ TnM-ask your client to select major features that you would prototype to full extent. Create only wireframes of the less important features. Use the 20 /80 rule:-ask your stakeholders to name the 3 most important things a visitor should be able to do with the service.(some priorization is necessary)-test these features with your co-workers and then have a walk-through with (some of) your stakeholders.(some form of testing is necessary)In situations like this, I then try to use UI design patterns that have worked in similar situations /designs. I'd make a draft of the overall design, navigation design, IA etc. Then i'd try to make the client sign-off on that. Only after that i would create an extensive prototype and only from agreed on features. Otherwise, you'll end up redoing the prototype quite a few times :-)Hope this gives some ideas. Cheers,Petteri
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Colette Elisa Buscarini
Sent: 23. toukokuuta 2006 13:44
Subject: RE: [agile-usability] business reqs and ucdMy other issue here cost. When your client (private or government) expect you to deliver an on-line solution under a pre-defined budget/time, you find yourself having to create an information architecture/UI prototype based on thin air. As the lead IA and usability consultant, I find myself having to create a full site architecture based upon marketing and branding requirements...there is no time/money to to do the right thing...interviewing users and stakeholders, defining business strategy, defining business processes, providing use cases...and put together a user requirement document. As part of the digital team, WE seem to re-invent the wheel each time!What is the best approach when business reqs and UCD do not apply and the company (who is a London, UK, leading branding and marketing agency) runs their digital projects as their print/campaign based work?Thank you.Colette
Be a chatter box. Enjoy free PC-to-PC calls with Yahoo! Messenger with Voice.
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.
- Alexander Johannesen wrote:
> If you can hide your work from them,Which, honestly, I don't think is unreasonable. From the perspective of
> then great, but there is this notion of teamwork going on here that
> requires a certain ... mediation to old progroms.
the waterfall person, all problems can be solved with a little more
planning, and failing to plan it all up front looks dangerous and the
fast route to failure. Until you have seen it work, it's easy to believe
that agile processes are impossible. I sure did.
When dealing with people like that I'll generally try one of two
approaches. The first is "Well, let's try an experiment." We find some
level of risk that they are comfortable with and try out agile methods
in that context. If the experiment is a success, we try a bigger experiment.
The other is, "You do what you think it takes." If they want a big spec,
then sure, they can write one up as we have our discussions around the
product. If they think a continuously updated spec is important, then
great, they should keep updating it. If they want a big MS Project
thingy, fine, we'll make sure all the necessary data is on our wall of
I don't know if those are helpful to you, but they've worked for me.