I heard a quote recounted by Garrett Dimon at a recent Refresh Dallas meeting:
If everything is important, then, nothing is.
This is the most relevant golden nugget of knowledge bestowed me as of late. The sentiment is relevant in many places, but is especially relevant in product/application/website design.
Prioritizing features is a must to ensure your user understands that one thing is important over another thing. For example, color coding items in a list of messages by severity, allows the user to sift through the things that require immediate attention, and leave the lesser important stuff to deal with later. Users need this prioritization and direction.
Before beginning development on any type of project you must know the projects goals, whether they be to make waves in your industry, to track bugs, to get people to buy your product, to monitor web traffic, to display your talents or to perform usability testing. Design your product, to do one thing and do it well, and prioritize its features so that it gives the user direction. Convoluting the goals of the product/application/website will only create a less usable and more clunky product.
For example, Adobe has perfected this sentiment with PhotoShop, Illustrator and FireWorks. PhotoShop’s purpose is to edit photos, while Illustrator is fantastic at creating vector graphics, and then there is FireWorks, whose purpose is to create phenomenal web graphics. Each product does their job, and does it beautiful, but what would happend, if these products were morphed into one large, clunky, and difficult to use product? People would probably move on to an easier program that just did what they needed it to do.
There are many other such examples- not to be cliche, but Apple does a great job of this, and Microsoft does not. Microsoft tries to make everyone happy all the time, rather than making simple, easy to use programs that do exactly what the person needs them to do and nothing more.
Instead of conquering a market giant, know your limitations and develop a complementary product, that adds value to the products people are already using. Value added products are usually more welcome faces on the market that competing products, which consumers/users have to wade between to find the right fit. Just something to think about….
So, first things first, develop a list of features, cross some off, and re-assess, repeat until you have a product, that does the exact thing it was designed to do, and leave the extras, to other products, who also do exactly what they were designed to do and nothing more. And, design your product to give users visual directions within the product.
I recently attended a Society for Technical Communications meeting where Kathryn Poe and Matt Stringfellow spoke about Agile Development. Kathryn and her Matt did a great job explaining how Agile development can impact those of us a the end of the waterfall, this is what I took away from their informational speech:
Agile Development allows us writers, and software documentation specialists to have roleswithin product development- especially in the realm of software development, rather than below or after development roles.
Documenting, writing Q.A. and developing basic marketing slicks or website text after a product is completed puts us in a bind. We are the last straw to getting a product to market, and as such in this role we are under the waterfall of the product deadline. If the development team falls short of meeting a deadline, whose time are they eating up? Most likely the person who’s job is put into the perspective of “just checking a checkbox”, or whose job is last on the to-do-list. The product documentation ends up being done in 2 weeks, for a product that took 2 years to develop- not cool!
I learned from a recent DFW-STC meeting, that Agile development allows the writers, documentation specialists, Q,A. people, and marketers alike to over come the waterfall effect that always seems to happen in a development schedule.
The key, it seems to overcoming such an obstacle, is to document, while the product is being developed, by breaking up the development cycle into chunks. By developing one feature at a time until it is finished (feature has been bug tested, wired up with the GUI, documented, Q.A.’d - finished) you can come out from under the development schedule and join it. Developing in this manner is supposed to help keep the team afloat as well, by encouraging the meeting of shorter more concise deadlines, as opposed to only thinking about the end- that huge looming deadline 2 years in the future, (or however long) that the entire product is supposed to be configured.
This type of development it seems, also causes less re-working, and re-configuring of features, because once a feature is finished it takes a lot more work to re-open it, and start over. It is much more work, and it makes a feature that was only supposed to get 2 weeks of development time, eat up 4.
All in all, I think Agile is a pretty good option, if you have a development team large enough to work on one feature at a time, and still meet the end product deadline. I’m not sure what happens when you work in a very small development environment.
If you are interested in learning more about Agile Development please check out Agile Alliance the Agile Community Website or the book The Art of Agile Development.
