What? Users in the development cycle? Blasphemy!
Is it? How many times have web and software developers had to cater to the whim of a client’s wish list at the last minute? How many times have project managers had to extend deadlines or budgets to include features to accommodate previously unmentioned functionality?
Users aren’t always available to provide feedback during development, so it’s the project manager’s responsibility to track down the necessary information and incorporate it into the project.Let’s say you are a project leader and tasked with implementing a large intranet-related project. No problem, right? It’s a project within your own company; you should be able to understand the basics and develop a workable solution…shouldn’t you? For months your team painstakingly maps out, designs, and codes a perfectly streamlined solution only to realize too late it lacks several secondary functionalities the users’ won’t touch the application without. Your project is pushed back, budgets are overrun and your effectiveness as a leader is in question. Users’ input in the development cycle is exactly what you were missing.
Where you’re going, and how to get there
Designing any application to target a specific user base requires effective planning and an ample amount of design time before any code is actually written. Too often the users the application is designed for have no say, or even realize they should have a say, in its overall design. Here’s a brief outline of the design steps:
- Application necessity: What is this project supposed to do? Determine the end results and know what a successful completion is going to look like.
- Intended audience: Who is going to be using this application? The public? Your co-workers? A client? What special needs do they have?
- Delivery: How is your audience going to be using this application? Web-interface? Desktop clients? Handheld/WAP?
- Technology: What are you going to use to design this? Decide languages, databases, client/server specifications, etc.
- Timeline: Balance your team’s capabilities with the project ahead and map out specific goals and deadlines. Understand every deadline is a critical one and staying on task is important at each step.
- Development: Get your hands dirty, stick to your application plan, and constantly report back to management about your progress. Determine if the application’s scope has changed and if project changes are necessary.
- Delivery: Determine how best to deliver the completed project. Will you roll it out over time, or all at once? Is interaction with the users required?
- Support: But I managed a perfect project! No you didn’t. No one is perfect; bugs will happen, users will break things. Make sure enough team members are accessible to provide adequate support for the application.
These are the major steps involved in the lifespan of most user-based projects. You can argue for less or more steps, but the principle is the same. Without these specific pieces of the project, it’s certainly doomed for failure. Keep in mind each of these steps should be considered before the project gets too far along. Just because delivery and support fall later in the timeline doesn’t mean you shouldn’t plan out their execution now.
Know everyone’s role
Members of the application team have responsibilities at each step of the process. This not only includes individual participants, but specific groups as well: project management, development, and end users. Here I describe a few of the steps in this process and the group’s general responsibilities within that step, taking into account interaction with the other groups. The focus of this evaluation is job function as it relates to user interaction.
- Application necessity
- Project management. The project managers’ responsibility is to ensure the proper direction of the project at all times. It’s their duty to keep all project members on track and make sure communication is taking place on all levels. They will have to communicate with upper management, with the development teams, and with the end users. They will also have to make sure relevant communication is had between development and end users. Isolating developers from the user’s wish lists is leaving too much to interpretation.
- Development. The developers are the heart of any successful project. Without a competent and ambitious development team, no project will fulfill its potential. That said, the development members have a responsibility to make sure they are communicating with project management and with the end users. Project management’s responsibility is to make sure communication is available and/or disseminated to the development team, but the developers should always make sure they have recent, and correct, information regarding the user’s needs.
- End users. The end user walks a fine line between providing too much and not enough information. They need to be effective when informing project management of their functionality requirements, but know when enough is enough. Corporate management usually dictates what a specific application will do, but the users have to live with it day to day. Attempting to make them happy from the start will help make the project successful in the end.
- Intended audience
- Project management. The users are going to have their hands on the application each day, and project management really must understand their needs and wishes well ahead of time. An efficient project manager will be able to interpret all types of user requests and know how to translate them into necessary project goals.
- Development. The developers must know how to accept information from the project manager, and be able to raise points they feel relevant. If the project manager missed something a developer feels is vital and/or will increase efficiency for the user, they have a duty to bring it up for analysis.
- End users. The users have to live with the application once complete, and need to know how to communicate their needs properly. Development teams aren’t mind-readers, and will need to know what’s necessary outside the scope of the original design specifications.
- Technology
- Project management. It’s important to understand most end users will have little to no knowledge of the complete application cycle, and their interaction is necessary to ensure successful usability. The project manager should understand how to let the users know their input is limited when it comes to choosing an effective platform for development.
- Development. Be mindful of the project goals, understand how decisions in this level will affect overall performance, and raise concerns about possible slowdowns or user-related problems.
- End user. Know your place in the development cycle! Give project management the raw data (wish lists, usability needs, priorities, etc.) and let them interpret how it will be implemented. Speak up when you believe critical user-related issues are being ignored or improperly interpreted.
- Delivery
- Project management. After coding and testing is complete and the application is ready for delivery, project management should be prepared to assume an instructor’s role. They shift from directing the development team to showing the users the details of the new application. Answering questions and demonstrating core functionality are necessary to communicate how the developers have implemented user wish lists.
- Development. Having completed the difficult task of completing the project, development should be prepared to regard any last minute requests or feature changes. Corporate (or the client) will often require modifications after a project has completed, and development should expect this ahead of time.
- End users. The users have a responsibility to thoroughly examine the application for each feature they required or requested. Not all wish list entries can be incorporated, but it’s not unreasonable to expect a good portion of them. Those features not incorporated should be mentioned, and missing essential ones should be questioned.
Users aren’t always available to provide feedback during development, so it’s the project manager’s responsibility to track down the necessary information and incorporate it into the project. When user input isn’t available, it’s corporate management’s (or the client’s) responsibility to make sure the necessary specifications are made available. Lack of user accessibility by the development team doesn’t preclude them from having to investigate user-related needs; quite the contrary. When users aren’t directly available for input, the development team must interpret what they have been given by project management to provide the best environment possible.
It’s important to note each member of the development team has an effect on each portion of the development cycle. Users aren’t only necessary at the beginning and again at the delivery/support level, they should be regarded throughout the life of the project.
Note that I say regarded, not completely involved and not completely isolated. The project manager must know how to balance the two while maintaining peak efficiency in the development cycle. This is not to say every user idea is going to be implemented, or even necessary. Poll five end users about color schemes and you’ll get six different answers.
Project management and development must know how to balance mission critical requirements, end-user efficiency, and potentially unnecessary items. It’s not practical to try to satisfy every single person who might come in contact with the application, but it’s in everyone’s best interest to be adequately represented in the development cycle.
Keep the communication lines open
Communication is the key. Isolating any one section from the other is harmful to a project at best. Each of the project management, development, and end user groups must learn effective communication before any can begin to work together. Even if the end users never meet the developers, both must know how to ask the proper questions so projects don’t go unused or used improperly.
An effective project manager will know how to assemble end users and get the proper details from them. They will be able to compile those details and disseminate them to the development team for incorporation into the project. They must know how to steer development in the right direction to balance efficient coding and necessary user request inclusions.
Development must in turn know their users; they have a duty to question if what they’re designing is going to meet the specific needs of the project as well as those who will use it. The end users must in turn realize the massive resources that go into a successful project and know how to communicate their needs to the project manager. They also must know their place in the cycle, respect the development team’s expertise, and believe their requests aren’t going completely unheeded.
Don’t let another project go unused. Don’t let another end user hate your applications. Don’t be another project manager who thinks end users have no place in the development cycle. Get the right information from the right people and make sure your team has everything they need to do their jobs properly. When your application is loved by all and you’re responsible for its success, your entire team will thank you for it.
 |
| Salvatore Palmisano spent nine years as a CIO for a small Tallahassee, Florida company, and currently is a business analyst for a Tallahassee software firm. He specializes in team-based solutions development, and maintains ‘all things underanalyzed’ at sienar.org. |
|
Wow. I’ve never seen responsibility for usability placed on the shoulders of the end users before. Is this wise, considering all the “Don’t listen to users” stuff on useit.com? And I didn’t know that project managers did usability.
This is a radically different view of the user-centered design cycle than all the stuff in books lately.
Salvatore, this is great.
First to Cecelia’s point. I don’t think that he was stating that Users do usability. It is more that you can’t make a usable product without end-users’ voice in the project. Also, I don’t think he was saying that project managers DO usability, but project managers can make sure that user studies are included in the project plan, and that UCD is a core part of the project lifecycle.
I liked this article a lot. It is missing one distinction that I have learned is very important for product creation and that is the difference between the end-users and the customers. Customers don’t always buy what will work best for users and quite honestly if customers don’t buy it, then users will never see it.
I call this the bell & whistle requirement. Why? Well b/c customers are humans and even the largest purchase has a little human impulsiveness around it. I work for an enterprise software company, and I am amazed at how “Ooo! & Ahhh!” makes people buy things even at this level of scalibility and robustness requirements. Why? b/c a fact sheet will never differentiate you from the competition. A “Wow!” will every time.
I have designed pieces of our software that I KNOW is completely unusable, but the sales staff say that it is a requirement as is, b/c it makes for a kick-butt demo.
Anyway, I don’t think this takes away at all from Salvatore’s overall theme. I just wanted to make sure that we remember many of us are in the business of design and have a higher calling than UCD theory … that is selling products.
— dave
Im more concerned with being cognizant of user needs than I am with placing ‘responsibility for usability’ onto end users. The more project managers know about their audience, the better they are going to be able to direct their project.
Why use another tier between project management and usability? Why not include user requests in project specs and eliminate the guess work?
This does NOT mean I call for users involved in every aspect of the project life. Users must know their place; they should be aware only they can get across what matters most to them about the application. Project management should interpret those requests and disseminate them to development. From there wish lists can be regarded and decisions can be made about what stays and what goes.
Dave, excellent point. Im overly left-brained sometimes and consider efficiency and usability over whats ‘pretty’. But you’re right about adding features that sales can use as a closer.
Thanks for the support.
.sal
Well, I read this
“The users have to live with the application once complete, and need to know how to communicate their needs properly. Development teams aren’t mind-readers, and will need to know what’s necessary outside the scope of the original design specifications.”
and I thought it said that it is the end user’s job to communicate their needs clearly to the development team. But in all the books I’ve read on this stuff, it says it’s the devlopment team’s job to observe and coax knowledge from the users, and that users *aren’t capable* of making their true needs known.
In fact, the books say it’s the development team’s job (in particular the usability engineer’s) to “read the user’s mind”
I do totally think it’s cool that PM’s do user research. I mean, why does it always have to be the IA/Designer if there is no usability engineer on staff?
Salvatore has presented a good overall theme, that users MUST be included at different points in the full lifecycle of a project.
However, there is an underlying idea that “Users must know their place.” Unfortunately, this seems like an IT-centric viewpoint. Users are generally unaware that software development is happening until software is released. It is up to the project manager or other facilitators of requirements/input to manage end-user input into a project.
Certainly, to Cecelia’s point, if you ask users “What do you want?” you will probably get answers from black to white and hot to cold. A good project manager/analyst/UX person should be able to understand the business well enough to see through the fog and turn those “pie-in-the-sky” ideas into as much reality as is feasible, using input mechanisms such as surveys and other tools of the UCD/UX trade.
Users should not have to “know their place.” Users should only have to know their job. It’s really up to us to turn that stream of desire into meaningful features that help them get that job done.
Cecelia,
To even attempt to ‘read the users mind’ or to get usability information solely from observation is a primary reason rifts exist between users and PM.
If you want to know the answer to a question, you have to ask it first.
Here’s one: Perhaps its time for new books?
Thanks for the comments,
.sal
Can you recommend some books for me? Thank you for helping me with my learning.
I have:
Designing Web Usability
Designing Easy to Use Websites
Back to the User
Don’t Make Me Think
About Face
Usability for the Web
User-centered Web Design
Contextual Design
Inmates are Running the Asylum
Usability Engineering (this one is very dull!)
I like the idea of just asking users what they think and to give input directly, for it seems much faster.
Cecelia … add customers.com to you list. It is more about direct communication than the others. Of course I would interpret Contextual Inquiry as a direct mode of interaction … It is basically a form of interview with users, and any good usability test should always include a place where users get to respond directly to their experience. What you do with that information is totally different.
— dave
OK, I’ve been holding off on commenting here, but seeing as we’re now getting someone – Cecelia – involved who is imbibing this as mothers’ milk, I felt like I had to speak up.
Sal, you say this: users should “respect the development team’s expertise, and believe their requests aren’t going completely unheeded,” right?
Try this. (This is just the very first example that occurs to me, BTW.) Go to this site: http://www.sonyadtv.com/index_e.html
If you were a user of this site, why in the world would you respect the development team, when that team obviously showed little respect for the user? As for “unheeded,” well, we might say that not only were the users unheeded, they were ignored. (Usability testing was performed on this site, and the results discarded as being politically inconvenient.)
Users are human beings, as I never tire of reminding people, and are therefore subject to all kinds of human foibles – including the occasional inability to put their requests in language that developers will readily understand. But this in no way justifies lecturing them that Father Knows Best.
He doesn’t, all too often.
Have I misunderstood you?
Adam, thank you for the comments. Yes you have misunderstood me.
The main ingredents of my article were communication and collaboration. Im calling for everyone to work together to make sure these types of applications arent built in the first place.
Im sure there are plenty of examples of this process gone wrong; bad web sites, unused intranet modules, et cetera. Im calling for a solid development process where each component (not just the users) know their place and what’s called for in that place. Development shouldnt run amok thinking they know whats best for the user, and the users shouldnt clam up thinking ‘the developers will do what they please so why should we even say anything?’
The expertise I meant users should respect is in respect to technological development of the application; it was not meant as a pat on the user’s head by the developers saying: We know what to do, trust us. I can understand how it might have been construed that way, but it was not my intention.
Most importantly, this was not meant as a lecture to any side of the cycle. It was a call to work together as efficiently as possible.
Again, thanks for the comments and I hope Cecilia (and others) are getting a better understanding of where this article is going.
.sal
Hello again,
I still don’t understand how you get users into your communications. They are not at the work place. How do they even know development is occuring? How can they get their feedback to the developers, if you are not using the observation techniques I have seen in the usability expert books? Or does the project manager inform them and collect their input? How do you deal with “self-reporting” issues?
Each project is going to require a different sort of communication. Whats important here is to make sure that communication happens on some level.
If users are completely unavailable, a higher level of interpretation is needed; if its an internal project and project management/development is on-site, it should be easier to get feedback.
.sal
Sal:
The requirements-gathering responsibilities in your article which the PM and users are to shoulder look to me just like what good analysts or designers are supposed to do. Would you consider the role of analyst/designer to possibly be a missing role in your list of PM/developer/user? It’s been my experience that a good PM and a good requirements analyst are not the same person.
Ralph,
You can always argue for more interaction and/or tiers in the design process. My intention was not to discount added levels or specific expertise in the ladder; rather to focus on the minimum requirements.
I imagine most medium-sized organizations dont have budgets for requirements analysts, so I didnt get into too much specialized detail.
You raise an excellent point, though. Thank you for the comments.
I completely understand Sal’s perspective here.
As an information architect/project manager for a major retailer’s e-commerce team, I am constantly striking a balance between business requirements and technical requirements. The challenge is to identify, and then to *reiterate* in a meaningful way, the business requirements, and then connect them to the technical requirements (IA is part of technical reqs in my case).
The key to this is to communicate back to the user/business partner what you have heard them asking for and *not* asking for. A couple of conversations like this will usually result in a bunch of requirements that were never articulated in the first pass. Then, of course, there is the negotiation phase – i.e., do you want all of these features, or do you want it by the original date?
In the end, the more conversations you have with users early on, the less likely you are to find out late in the process that something critical has been overlooked.
“In the end, the more conversations you have with users early on, the less likely you are to find out late in the process that something critical has been overlooked. ”
Lisa,
This is exactly my point. As the article title says: ‘Effective Project Communication’ is what’s needed, and often overlooked.
Thanks for posting.
.sal
Very good article – Plan, get the right people involved, define roles and responsibilities, communicate.
However, I think Mr. Palmisano confuses how to work and communicate with users (and customers) versus how to do so with clients. Assigning responsibilities to clients is appropriate, assigning them to users or customers is irresponsible.
Of course, in software and web development, irresponsibility is all too common. I doubt if there is anyone who wouldn’t benefit from following Mr. Palmisano’s advice.
Mr. Zeno,
Thank you for your encouragement and your comments.
I completely understand working with clients is often very different from working with user/customers. However, the main ‘responsibility’ of the article was communication in a variety of forms. I do not advocate assigning users tasks which will detract from their everyday workload, rather, those users expected to communicate their needs should know how to do so properly and effectively.
Indeed assigning tasks to customers, in almost any form, is a risk at best and should be left to a comments or feedback format.
Again, thank you for your comments.
.sal
Thanks for the clarification.
“those users expected to communicate their needs should know how to do so properly and effectively”
Still irresponsible and naive. Irresponsible because you are assigning responsibilities to people outside the project that are essential to project success. The more responsible approach is to assign someone within the team to be responsible for gathering the requirements from users.
Naive because in many cases the user cannot be expected to properly and effectively communicate their needs. Thus the need for methods to elicit user requirements.
A facinating article.
Perhaps some confusion is stemming from the ambiguities surrounding what KIND of project Mr. Palmisano is talking about. When discussing “End Users” it seems that he assigns a MUCH more active role to them in the development and design process than usual. While I could envision this kind of End User participation in an internal software development situation, I wonder how fully his vision of End User interaction could be implemented with a web project.
As for those who think the role of UI belongs to UI professionals: I couldn’t agree AND disagree with you more! I agree because technically, yes, UI professionals should be doing this kind of information gathering. I also disagree with you, because how many companies have one person fully dedicated to this task? Perhaps in larger companies they do, but not in mid-sized or smaller companies. Does that mean that this kind of research should be neglected? Absolutely not. But the question is WHO does it?
Perhaps what readers should take away from this article is that the general idea rings true: End Users do need to be involved in the development. How they are involved, and who’s responsible for managing such involvement, may be open to debate.
I think the largest point of mine missed (probably my fault) is: ‘end users giving information in application development’ refers to those employees/clients/people/et cetera TASKED with doing so. I never meant to imply everyone should have their hands in the mix, nor did I mean to take anything away from those who do this professionally.
Just as there are tasks for project leaders and developers, there are tasks for the end users expected to speak up about what’s needed in the project.
.sal