#27574
Does a Good User Interface Obviate the Need for Documentation?
This question was raised on a programmer's group recently and I was intrigued. The programmer's point was that with many web applications these days there is no print documentation distributed to end users, and even if it existed, many users won't read it although this makes me wonder who's buying all those how-to books I see in the bookstore. The programmer suggested that applications should be designed without documentation and wondered about the impact that would have on design.
Sprezzatura Systems (2002). Articles>Documentation>User Interface>Software
#27572
eXtreme Documentation and Design
What quicker way can there be to find out if something is teachable than to write up task-oriented documentation? And as things are built or changed, the documentation is updated. I often update the documentation before the code!
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>Documentation>Agile>Extreme Documentation
#27575
Your requirements document needs to focus on the user’s goals. They should not be marketing’s list of features 'we’ve got to have' because the competition has these features. They should not be a list of things the programmers think ought to be included 'because we can add those things for very little cost.' Feature bloat does not benefit the user.
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>User Centered Design>Specifications>Software
#27576
Handheld Devices and the Flow of Functionality
Handheld devices and small appliances pose a unique challenge to the interface designer. The blur between user interface and functionality (interface vs. interaction) is even more pronounced in these environments. The interface of any small device is extremely important; yet, more than ever, the necessity to build in exactly (and only) what is required by the user is extremely important!
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>User Interface>Workflow>PDA
#27573
Software is sometimes poorly designed to begin with and the interface should be scrapped and rebuilt from scratch. But more often than not, I see software that started with a decent design and has since had features added onto it with each release, squeezed into the existing design rather than being designed in. People aren't in a design mindset but an 'enhancement' mindset somehow.
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>User Interface>Usability
#27577
Your requirements will assist you in delivering a software solution that meets your users' needs. You can find all sorts of templates and formal processes for requirements of various kinds, and while they are useful, the biggest problem I've found is that most people confuse defining the need with proposing a solution. As soon as a requirements document contains any part of 'how we're solving this', you've crossed the line into presupposing that you already know what the problem is and can stop listening.
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Careers>Consulting>Specifications
#27578
The Secret Ingredient of Every Methodology
In any software development methodology, there's a secret ingredient that doesn't get enough press. It doesn't matter whether you follow Cooper, Beck, McConnell, or anyone else on the long list of notables.
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>Software>Methods
#27579
Smart and Lazy Software Development
Smart and energetic people believe 'Never put off till tomorrow what you can do today.' Smart and lazy people say 'Never do today what you can put off till tomorrow!' This is, to me, one of the most useful tenets from the eXtreme Programming movement.
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>Management>Programming
#27580
Task Based Documentation and Good User Interface Go Hand in Hand
As I write the 'how to' documentation based upon the in-process design, the weaknesses of my original design become apparent and I go back and forth from writing text to designing the software until it all flows.
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>Documentation>User Interface>Usability
#27581
User Interface Should Be a Team Effort
Let's say you've got a clear set of requirements; the users have been defined, the features are associated with user tasks, marketing has done a competitive analysis and everything is good to go. Now what?
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>User Interface>Collaboration
#35621
From Drawing Board to Working Code: Software in the Real World 
Some of my designs never make it to market due to lack of funding prior to release and the company slips quietly away or gets bought and I lose contact. Other times by the time the software is released, the person who hired me has left the company and moved onto other pastures. So it's always a treat when someone calls me back to say "Would you like to come in and see the software? We're nearly done."
Sprezzatura Systems (2007). Articles>Project Management>Programming>Case Studies
#35622
It struck me while reading this that cultural blind spots are not limited to people who speak a different language, come from a different country, or have a different religious background—we have huge cultural blind spots between the various job functions in a single company!
#35623
Symphony or Jazz Band Metaphor for Software Development
One of the online lists I read frequently has been debating the proper metaphor for the software development environment. The building trade has been used quite often in the past. In fact, we use the term "architect" quite frequently, although ten software engineers will probably give you ten different definitions of what an architect actually should do. I think there is no single metaphor for software development roles because there is not a single software development environment.
Sprezzatura Systems (2007). Articles>Project Management>Programming
