What should our software do?

Alice Toth, Thursday, March 12, 2009 @ 5:50 am

The most difficult part about designing software is, well, where to begin? You have the account manager on the one hand who gives you the laundry list of items her client has been screaming about for the last n years; the marketing person who has his stack of post-it-notes listing features by competitors; and the tech lead with an itemized list of underlying functionality that must be refactored if the system stands any chance of continuing to work in the future.

Some teams combine all the lists into one main Feature List, assign a priority and tackle them one by one until either (a) all the items are completed or (b) the CEO decrees the product must be launched. On small projects with a limited set of functionality this may not be a bad approach since the overall Feature List will never be ungainly. The downside is that what you produce may not be what the user necessarily wants to use.

A better approach is to come at the problem from the user’s point of view, namely: What is it that the user wants to do or needs to do with the software — the goals. And, how will they accomplish it — the activities. Once you've figured this part out, you'll then have a better starting point to not only come up with a list of features but also to justify the necessity of those features.

For example, we recently worked with the client to develop the user model for their new software, which will be a web-based version of an existing application. Since they knew their existing user base, we ran through an exercise to confirm the user groups (a.k.a. personas) and their goals and then identified the activities they needed to reach those goals. For our Claims Specialist, the primary goal is to manage individual claims for her company with a secondary goal to report specific data from those claims. The various activities she’ll do to achieve this goal are:

• create claims
• edit claim
• manage supporting documentation
• create alerts
• create diary events
• run reports

From this list of activities, we can now create a list of features that are actually needed by the end-users. But we’re not ignoring the other folks in the company (more formally known as stakeholders). The features requested by marketing and others will be reviewed and filtered through the personas to determine if it’s something that they need in the software.

Ideally features aren't added to software unless they’ll actually be used by an end-user; the real world is rarely ideal, though, which is why creating feature lists can sometimes be an art, rather than a science. However, coming at the project from the point of view of the user gives you a touchpoint by which you can measure the validity of adding (or removing) features.

Related posts:

1. User Centric Design – the Who, What, Why and How of a Feature
2. Software Development and the Construction Analogy
3. Software Development: Importance Doesn’t Always Equal Effort
4. #*&)#*$)# Software.
5. It Starts with the User Story

Comments (2)

User Experience Design

Comments: 2 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. [...] more here: Custom Application bDevelopment/b » What should our bsoftware/b do b…/b Share and [...]

   Pingback by Custom Application bDevelopment/b » What should our bsoftware/b do b…/b « topsoft.us, Thursday, March 12, 2009 @ 5:41 pm

2. 

   I agree. Then creating products based on users’ experience leads to Usability, which I think is one of the elements of success for launching a software product. The other two are Quality and Predictability.

   Comment by Victor Velasquez, Thursday, March 12, 2009 @ 6:10 pm

Leave a comment