RE: [agile-usability] Seven habits of highly successful customers
- -- Alain Désilets wrote:
I like those guidelines, but many of them seem very code and developper centric.
I was thinking more about practices that someone acting in a customer role (either as the sole customer or as part of a customer team) can use to make sure that they guide the project properly.
On 16 Aug 2005, at 15:43, Desilets, Alain wrote:
> So here is my question to you U* folks. If you were to define a
> small (say less than 12) set of U* practices with similar
> properties (individually useful, provide immediate and visible
> benefit), what would those be?
/Good/ question :-)
My little list of guidelines includes:
* The UI is code
Don't treat the UI as separate from the code base. Having a good
clean simple UI is /just as important/ as having good clean code. Get
this across to the development team and most of your job is done.
* UI concepts should be reflected in the code
If your UI has a whole bunch of Wibble Buttons that look and behave
in the same way then there should be a WibbleButton abstraction in
the code somewhere.
* UI concepts should be reflected in the tests
You can't automate usability testing. You can automate some aspects
of it. Do so.
* Use persona
For those who've not come across them - little written sketches of
the expected users' personalities. Have them pinned up in the team
room. Encourage everybody to ask themselves "What would X do?" in any
given situation. For more info see <http://www.evolt.org/article/
* Code the UI first
Draft out the UI before you write the code. This does /not/ mean
design the entire UI of the application before you write the
application. I like doing it at the planning game stage: when the
stories are created or when the acceptance tests are being done.
Incrementally as the project progresses.
It also does not mean a glorious piece of Photoshop work that you
want to hang on the wall. Think Agile Modeling. Think paper
prototypes. Think sketches on the back of index cards. Simple HTML
pages. Just enough to get the job done.
* User advocate to the customer
There should be at least one person in the Customer role who
understands UI issues and can help shape the stories so they will
meet user expectations.
* User advocate to the developer
There should be at least one person in the Developer role who
understands UI issues and can help shape the code so it will meet
* Coding standards (extended XP practice, consequence of "UI is code")
Some sort of UI standards should form part of the coding standards.
Remember you don't have to define all your coding standards up front
before the project starts. It's a living document that should reflect
your learning as the project progresses. This applies much more to
the HIG since they tend to be more project specific and will change
as the team understands more about the project.
Also, be sure to create UI standards that people can actually /use/.
See <http://www.humanfactors.com/downloads/aug04.asp> for some tips.
Eight pages of single typed 8pt text bad. Pictures good. Big post-it
notes stuck on the wall - fantastic.
* Refactor mercilessly (extended XP practice, consequence of "UI is
You should treat inelegant UIs as harshly as you treat inelegant code.
* Collective code ownership (extended XP practice, concequence of "UI
Everybody owns the UI. It's everybody's responsibility to fix
problems with the UI.
* The customer is always available (existing XP practice)
Getting the programmers to guess about customer decisions affects the
UI just as badly as it does the code.
* Frequent small releases (existing XP practice)
Log gaps between feedback from real users affects the UI just as
badly than the code.
* User stories are written (existing XP practice)
Stories are much more user-centric than some more traditional
requirements gathering processes, and help everybody create a better UI.
* Pair programming (existing XP practice)
Spreading the knowledge about the UI is just as important as
spreading the knowledge about the code.
* Create spike solutions to reduce risk (existing XP practice)
Not sure which UI choice will work best? Throw together a prototype
and try it on some people.
Any more for any more?
Yahoo! Groups Links