“Goals are dreams with deadlines.”
When our team began to implement user-centered design practices at the hospital, it became apparent that we needed a plan. We couldn’t say we were going to start putting users first and then just go about our business. We needed to have documentation, from beginning to end, that would help us complete the entire process correctly.
We also needed to communicate our vision for what we were trying to achieve. Not just to the hospital but to ourselves: What was our purpose? Overall, what did we want to achieve as a team? How did we provide value to our users and the organization?
We decided that a template was needed to help us fill in the blanks and effectively walk through the user-centered design process.
Building line-of-business applications for an organization requires that you wear many hats. One minute you’re building an application to help the human resources department manage their employees and the next you’re developing something to assist the finance department with their invoices. By having a template to revisit, our team is able to keep all of our projects headed in the same direction.
For the nonenterprise developer, it’s equally important to have a plan in place before you start writing code. You should also spend time thinking about what you’re trying to achieve with your applications, even if you’re building them just for fun.
Essentially, having and documenting a strategic plan ensures that you’re creating applications in a standardized pattern. A plan protects you from forgetting important features or user requests.
For our team we have a documented process that starts with planning, moves to implementation and testing, and finalizes with deployment and maintenance.
When working on a team, this is vital, because at some point, you may be asked to help colleagues with their project. If they’re using the same standardized process to develop their application, it’s easier for you to review their documentation and immediately get started.
Our template has the following core components:
Team mission statement
Project details
User requirements
Functional requirements
Database/dataflow diagrams
Screenshots of prototypes
At the hospital we use the template to educate users about our process. They know that when working with a member of our team, there’s a standardized way in which we complete our projects. The more our users have worked within this structure, the more familiar they’ve become with what’s needed to complete an application. Effectively, the template helps us help them and vice versa!
There are several industry terms for this type of documentation. Our template is part of an overall Software Development Life Cycle; some firms call theirs a Request for Proposal or Letter of Intent. The specifics of these documents are outside the scope of our discussion. However, I would encourage you to look at how other software development teams document their process.
I understand that the template I’m proposing may not fit your work environment or project. That’s OK. What I want you to understand is that having a plan in place before you start writing code is a great way to ensure success.
I liken it to painting a room. If you’re doing it right, you don’t just walk in and start slathering paint all over the walls.
Let’s think about all the steps involved in planning to paint your living room:
Measure the room to get a sense of how big the space is and how much paint you’ll need.
Look at the furniture and lighting fixtures, and estimate how much natural light enters the room.
Go to the hardware store and look through many color swatches. Talk to the store clerk and ask about the different qualities of each brand.
Bring home a sample color and apply it to a small section of a wall. Wait for it to dry and make sure it’s the color you want.
Clean all the walls, tape the edges, fix any small holes and defects, and apply a priming coat.
All of this comes before you start the official project of painting the living room. Imagine if you applied this same type of commitment to your software projects before writing code. What if you spent most of your time researching the problem space and asking users about their needs? What if you explored the problem by building prototypes and quick mock-ups or screenshots?
My presumption is that you would spend less time writing unnecessary code or building features no one needs. That’s why having a plan should be a crucial part of your user-centered design process. It’s more than just collecting feedback from users; it’s stepping through a strategic process to make sure you’ve covered all your bases.
However, I’m not suggesting that it’s as simple as completing a plan and going off to write the code. Using our metaphor, building an application is like painting a room that changes its shape every day. With user-centered design, we continually gain new insights. Some of these insights are so significant that they change the course of development.
Software development is a dynamic process; it’s impossible to prescribe a specific workflow. Practicing user-centered design means you’ll be reacting to discoveries that were not included in your original plan. The software design team at EffectiveUI has a great way of looking at it:
No matter how well you think you understand the domain and no matter how earnestly you’ve thought through the requirements, there is still great uncertainty in the original facts and premises and a vast depth of the unknown still awaiting you. As with battle, the outcome will be determined at least as much by what comes during the course of the project as by what comes before it.
With that said, it doesn’t mean we shouldn’t keep a template or framework for the steps we intend to take. At the very least, you should be creating some form of roadmap so that you’re executing your user-centered design process in a meaningful way.
A team mission statement is a great way to set the tone of your template. Without having an understanding of what your team is trying to achieve, how can you proceed forward with any project? A mission statement has the power to remind the team of its purpose. Additionally, it gives you a fundamental understanding of the work you’re trying to complete. You can revisit your mission statement when making difficult decisions on a project.
We decided our team mission statement should be different from our organization’s mission statement. It’s not that we disagreed with the mission of the hospital, but we needed something more specific for what our team was trying to achieve. Therefore, we examined the organization’s mission statement and customized it to better reflect our team’s purpose. We decided our team was responsible for:
Developing simple innovative solutions to empower users in achieving the highest standards in patient care and service
The hospital’s mission is to provide the highest standards in patient care and service. The mission for our team is to provide simple and innovative solutions so they can achieve that.
Using this mission statement while evaluating our applications, we ask ourselves:
Is this application simple and easy to use?
Is this application innovative? Can we implement newer technology that makes it even better?
Is this application an impediment, or is it empowering staff to provide the best care for our patients?
Our project template has the team’s mission statement at the very beginning. It’s a reminder of the team’s commitment to the hospital and one another. If you work on a team in an organization of any size, consider what your mission statement might be.
In order to begin heading in the right direction, you have to be able to summarize what you’re trying to achieve with your application: What’s the point? Why are you building it? Who will the application serve? How will it provide value?
It seems obvious that your project should be able to answer these questions, but I find it valuable to take the time to document this information. The act of documenting what you want to accomplish can help you better understand your users’ needs. I also use this process as a point for users to give me feedback. Something as simple as the title of the project can have a dramatic effect on its outcome. An example of this was a project I worked on for our Rapid Response Team (RRT).
The RRT urgently responds to patients when their vitals (heart rate, respiratory rate, blood pressure, etc.) are in a “danger zone.” If an RRT nurse can respond before the situation becomes critical, he can provide proactive care and save a patient’s life, as well as increase his chances for a successful clinical outcome.
After the first few rounds of meetings with staff, I decided I was going to provide a database solution for RRT nurses to document their process. By collecting information about what happens during an RRT situation, we could look for ways to improve the process and help nurses respond in a timely manner.
I titled the project Rapid Response Team Database.
The lead physician involved with the project saw the title and asked me a question:
“Why are you calling this the Rapid Response Team Database?”
“Well,” I replied, “a database will allow the team to document their process. With this data, we can produce reports and look for ways to make response times faster.”
“That’s great,” he said, “however, I’m having a problem with that. This project should include more than just the Rapid Response Team. Really, it should be called the Rapid Response System. You see, in order for us to respond effectively, we need a system that involves all patient care providers, not just the Rapid Response Team. That’s how we’ll make a big difference.”
Correcting the title of the project uncovered a big insight. I realized that, in order for me to meet the needs of users (and hopefully save patients’ lives), I needed to expand the scope of the project to include members outside the RRT. I needed to start thinking of the project as an entire system, rather than just a small database for one specific team.
If I hadn’t taken the time to describe my understanding of the project’s goals, I would’ve grossly miscalculated when I began development. I would’ve created an application that was too small in scope, reducing the impact.
In this case, the title made a huge difference in my understanding of the project.
Our project template has a section Project Details that includes these subsections:
Title
Description
List of Stakeholders
Impact Assessment
The project title and description should reflect the entire scope of the project. While the title gives you a convenient way to refer to the project, the description should summarize what the project will achieve.
The section on stakeholders may or may not be necessary for your situation. If you were delivering an application to a specific group of people, then I would advise you to include a list of individuals who will share the responsibility of the project with you. If your project is for the mass market, you might consider revising this section to be “Potential Users.” Essentially, you should take a moment to consider the types of users you want to have an impact on.
If you do have stakeholders, then their job is to provide you with the information you need so you can create a successful application. By listing key stakeholders, you know whom you can count on when you have a question or need clarification. This helps everyone understand who’s involved in the user-centered design process.
Finally, the impact assessment describes the impact the application will make on the environment in which it will be deployed. In other words, the assessment should summarize whom or what will be affected as a result of the application (both positively and negatively). This is a great way to help keep your eyes on the prize.
Again, this may not work for your situation. In an enterprise development role, it’s always a good idea to consider how your application will impact the organization. This will help your team prioritize projects.
If you’re working on your own, you might consider the personal impact of the project: What do you hope to gain from working on this application? How will this project help you in advancing your craft? What would you like to gain from your work?
You might also consider reviewing the impact assessment after each project is completed. This way you can see if the application had the impact you were looking for. If possible, consider having users review the impact assessment before you start the project to make sure your vision matches theirs.
Collecting user requirements is the most important part of your user-centered strategy. The user requirements set the foundation for the remaining steps in the user-centered design process. Without properly defined user requirements, it’s impossible to move forward in the right direction.
The process of collecting user requirements demands that you take users’ abstract requests and convert them into meaningful needs. Documenting these needs requires you to summarize what’s needed. By showing requirements to your users, you can ensure you’ve correctly understood their needs.
There’s something powerful about showing users their requests in writing. Many times, I’ve been corrected when I show them my summarized list of their requirements. They’ll say, “Yeah, I see how you thought that’s what I needed, but actually I need something different.” Documenting user requirements has saved me countless hours of wasted development time and heartache.
To be clear, user requirements are not technical. In fact, this part of your Software Development Life Cycle (SDLC) should avoid technological solutions. User requirements are the users’ needs, not a specification sheet of what you’re going to deliver.
Collecting user requirements is so vital to a successful project that I often refuse to write a line of code until I’ve had several meetings with users to flesh out their requirements. Without proper communication and understanding between the developer and the user, it’s impossible to create an effective application. Documenting user requirements is the best way to encourage that kind of communication.
If you were not working with a direct client or user, then I would advise taking time to consider what potential users would require from your application. Coworkers, family, and friends can be a great resource for this. Consider showing them your requirements and get feedback on whether your user requirements match theirs.
During graduate school I worked on a proof-of-concept iPhone application for organizing potlucks. One of the first steps the team took was to brainstorm all the user requirements for planning a potluck. Things like contacting friends, organizing a list of meals, and keeping party attendees updated on the latest developments were requirements that began to surface. After our brainstorming concluded, I felt like we had the space pretty well covered.
However, when we went out and talked to our family and friends, we learned of several new requirements that we hadn’t considered. The fact was that I planned potlucks much differently than some of my friends. The things that I cared about weren’t as important to them and vice versa.
If you’ve spent months developing a project only to discover you built something your users didn’t need, it’s time to consider collecting and documenting user requirements.
You may be confused about the difference between user and functional requirements. A user requirement is what the user needs; a functional requirement is what the application needs. Essentially, functional requirements can be seen as the technical specifications of the project. These are the individual functions you plan to deliver through your application to meet the user’s request.
Our potluck application had a variety of user requirements for planning potluck parties. While collecting user requirements, it was difficult to remain focused on discussing requirements and not get sidetracked by trying to find solutions. We remained focused on understanding what users needed to plan a successful gathering. When we reached the stage of discussing functional requirements, we could finally brainstorm on how we might meet those needs with our application.
For instance, we observed that a consistent user requirement for planning a potluck was to have attendees notified when something had changed. For example, an attendee may change his mind and decide to bring a dessert instead of a side dish. If two other people were planning to bring desert, it would be important to let him know so he could consider revising his choice. It was also important for attendees to know who was planning on attending the event. They wanted to be notified if someone cancelled or did not plan on attending.
The team reviewed several technical solutions. We also reviewed other applications and how they dealt with similar situations. We asked users what technologies they were currently using to meet their needs and asked about the pros and cons of those services.
Eventually, we decided that iOS notifications were the best way to respond to users’ needs. Therefore, we ended up listing the ability for the application to send iOS notifications as a functional requirement, as shown in Figure 4-1.
In your template, consider connecting each functional requirement to the user requirement it meets.
At the hospital our template includes columns so we can number our user and functional requirements. This allows us to make connections between them. You might have one user requirement and several functional requirements that meet that need. By having these lists numbered, it makes it easy to quickly review them and make sure we’ve connected a functional requirement to each user requirement.
If you’re working for a specific group of users or client, then the list of functional requirements can help you communicate to users how your development process works. When they see their user requirements translated into a list of technological solutions, it becomes an effective tool for explaining your role in the process.
I find that this also helps with users who make last-minute requests. If a user changes his mind about what he needs, then the process has to start over. You’ll have to document his new request and convert it to a functional requirement. You can use this process to explain why extra time is required in adding the new request to the project. On more than one occasion, I’ve had users decide against adding a new feature once they saw how it affected the delivery of other functional requirements.
If the application you’re building relies on a dataset or multiple datasets, it’s a good idea to include diagrams of how that data is structured, retrieved, and transferred. Tools, like Microsoft Visio, provide templates for creating database and dataflow diagrams.
A database diagram depicting the structure and organization of your database can be a helpful tool. It allows you to see what data elements are available and how you might access them. I often keep a printed version of my database diagram at my desk. I realize this process is a bit analog, but I find it easier than hunting through my database software to look for a particular field. Obviously, if you have an extremely large database, printing a diagram of it would not be an option. If this is the case, you might consider a modified diagram that focuses on the elements you plan to use in your application.
Another helpful tool is the workflow diagram or dataflow diagram. I use workflow diagrams for projects that have a complex series of steps to complete an action or where multiple people are involved to achieve an outcome. Workflow diagrams allow you to consider all the steps required for a user or group of users to complete an action.
It can require some time to create this, but the diagram will free you from having to manage the entire application’s workflow from memory. Even something as simple as a vending machine can have several paths and conditions to consider, as depicted in Figure 4-2. It can be easy to miss a step or forget a critical path.
The database and dataflow diagrams can be as simple or as complex as you want them to be. Obviously, the more detail the better, but I’d prefer a limited diagram to nothing at all.
Prototypes can be useful tools in assisting the user-centered design process. Prototypes allow you to translate the user and functional requirements into something tangible. How can users know what you intend to deliver if they can’t see it?
I think the biggest challenge developers have with prototyping is that it takes away from the big reveal—that unmistakable high you get just before you show the user what you’ve been working on. In some ways this high is what keeps us motivated to continue developing our project in secrecy. If our motivation is to have a big unveiling, it causes us to hide our ideas from the user until we’re finished.
In the book Team Geek (O’Reilly), authors Brian Fitzpatrick and Ben Collins-Sussman describe this problem perfectly:
Deep down we all secretly wish to be geniuses. The ultimate geek fantasy is to be struck by an awesome new concept. You go into your Bat Cave for weeks or months, slaving away at a perfect implementation of your idea. You then “unleash” your software on the world, shocking everyone with your genius. Your peers are astonished by your cleverness. People line up to use your software. Fame and fortune follow naturally.
The problem with this approach is that if users haven’t been included in the development process, then there’s a greater chance they’ll be disappointed when you’re finished. The dramatic unveiling shouldn’t motivate us. Instead, we should be driven by the desire to get things right, and the best way to do this is by having users involved throughout the entire process.
We’ll talk more about prototyping in Chapter 8. For now, understand that your documentation should include screenshots and early mockups from your prototypes.
Another value of documenting the user-centered design process from the very beginning is you’ll have the ability to review it long after the project has been completed. It can be an interesting and reflective exercise to see how your application changed over time. Reviewing old templates and documentation allows you to see the entire process, from conception to reality. It’s a powerful tool to discover and gain insight into how your project changed over time.
Some of you may already have extensive contracts and specification sheets for your clients to sign. If you don’t work in that type of environment, I encourage you to enforce stakeholders to sign a project plan, even if it feels a little awkward.
I’ve found that our users don’t mind entering into this type of agreement. Most of them actually like to see a document that clearly states a plan to meet their needs—and they’re willing to sign off on it. It makes them feel more like a client and not just a coworker. In the enterprise development environment, I think that’s how users should feel. Of course, our team doesn’t consider this to be a legally binding document; it’s just a simple way to elevate the importance of the documented plan.
In Appendix A, you’ll find the project-planning template we use at the hospital. Feel free to use this as a guide to building your own. You may decide to rewrite our template to focus on other areas. That’s fine.
At the end of the day, your plan should meet the needs of your team and users. As long you design it as a tool for documenting and following a standardized methodology, it should prove invaluable.
Get User-Centered Design now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
