MMP5: Rapid Iterative Design: A Minimalist Approach to Requirements Gathering and Interface Design

Beth Snapp: And so as I mentioned, my name is Beth Snapp. I'm the director of Web and Data Solutions and Technology Services in the College of Arts and Sciences at Ohio State University.

Just a little bit about myself... My team manages a portfolio of 200 websites for the College of Arts and Sciences. We also do custom app work and we also do data analysis and reporting of the university data sources.

Today, I'm going to talk a little bit about our experiences as related to custom app development, and I'll use one of our systems as a case study for today's presentation.

I've been in application development for about 15 years, 10 of those years at Ohio State. I started off as a developer, then I moved into database administration, and now I am a project manager.

For the past couple of years, my team has been transitioning to Agile software development, and I want to share a little bit about our experiences today.

So I'm not sure what I was thinking when I came up with this title. It's probably the longest title of the conference, and it's not very excited, but I'm not the most creative person, so I'm glad you're here.

[Laughter]

What I'd like you to focus on is four key words in the title, and that's 'rapid', 'iterative', 'minimalist' and 'agile'.

I want to talk about a method that I'm calling 'rapid iterative design'. It's something that my team has come up with over the past couple of years. It's great if you are an Agile software developer or you're striving to be an Agile software developer: your goal is to define a product, you want to work very quickly, you want simple methods, and your project is iteration-friendly.

In other words, you want to spend more time writing software and less time writing documentation.

So here is the model. I believe this is an excellent way to gather requirements in an Agile way. It's based on my own team's experience, as I mentioned, but the techniques are not new.

They are actually well-established techniques from user interface engineering, and also a bit of Agile software development thrown in. But what I think is unique is the way our team has mashed them up into a simple method to speed up the requirements-gathering phase.

So why is this important? Have you ever felt this way when you were starting a project, especially developers? Did you feel overwhelmed by the amount of requirements-documentation?

Which would you rather be doing: writing code or writing documents? Definitely writing code, if you're a developer. I can relate to that. But now as a project manager, I also understand the value of documentation. I'm not anti-documentation. I don't want you to go away from this presentation today saying, "Beth told me to quit writing documentation." That's not what this is about.

What I'm going to argue today is there is something not quite right when you're writing documentation just for the sake of writing documentation, because you think that's what you're supposed to be doing. What the issue is is when you're writing documentation as an end in and of itself. That's the issue that I have with our traditional software development processes.

I think the danger of that approach--and we'll talk a minute here about traditional development--is that the customer becomes lost in the shuffle, the shuffle of papers. What the customer really needs gets lost.

I think the most important thing that we should remember as developers, as project managers, is that we're evaluating on whether we have delivered something that helps our customers meet their goals. That's actually our legacy, not the requirements documentation, not our use cases. It's our software.

I think my philosophy is very consistent with Agile software development. How many of you read the Agile manifesto? If not, I very much encourage you to go out, agilemanifesto.org, and read about that.

An important value of Agile software development is listed here: "Working software over comprehensive documentation." That doesn't mean 'no documentation'. That means that working software is more highly valued than documentation.

So here's our dilemma. How much is enough documentation? How much is enough planning? How much is enough design?

On one side, we have too much documentation, and that results in analysis paralysis. And then on the other side we have cowboy coding, which is kind of rogue developers shut up in their room coding whatever they think is best for the user, which is usually meaning best for them.

So I want to talk today about having just enough, just-in-time documentation, and that's what I mean by a minimalist approach.

I'm sure you're all familiar with the waterfall methodology. How many of you practice this methodology? Or have in your past? Yes.

I think this is what we're taught in our CIS programs. It's what we learn in the PMI certification process. And many of us who are starting out our careers, this is what we're learning on the job as well.

And the outcome of the first two phases just tends to be a linear process. The requirements in design phases tends to be a big old stack of technical specification documents that the developers were not involved in writing. The documents are handed over to the developer, and the message from the business analyst is, "Build this product."

I think that this model probably would work well on big projects--I don't have experience with ERP projects but I suspect that might be the case where traditional software development might be appropriate--big ERP-like projects with 100-person teams.

But for us, we have small teams. Our projects are smaller- to medium-size. They have limited complexity. And I think that's when Agile methods really stand out and are really most useful.

So on Agile projects, there is less need to write stuff down, and the reason why is because collaboration is so highly valued, especially face-to-face conversations, face-to-face communication.

So if you're truly collaborating with a customer, if you've established a relationship with them over time, for example in Daily Standups, in Scrum or XP, if you feel comfortable enough to call them up on the phone and ask them a question, and you get a response relatively quickly because they respect you and want to provide input, I don't think there is so much a need to abstract requirements into documentation.

This is a quote from one of my favorite books, "Rework" by Jason Fried and DHH from 37Signals: "The problem with abstractions, like reports and documents, is that they create illusions of agreement."

A hundred people can read the same words but they're imagining a hundred different things. That's why you want to get to something real right away. And that something real right away is what this model is about, rapid iterative design.

Of course, with all successful projects, we're going to start with a very clear vision for the system, and that feeds into the requirements-gathering and the analysis and design processes.

Today I'm going to talk a little bit about personas, scenarios, user stories and paper prototyping. Again, these are not new. I did not invent these. I think that the way we are applying them in our projects is unique, and that's what I want to talk about, and hopefully you'll come away with some practical tips to add to your toolbox.

Note that this is a cycle that is not linear. It's not phased like the diagram I just showed you a little bit ago, the diagram representing traditional software development.

What we're doing is we're packaging up all of these into one big iterative process. And, actually, this diagram, probably all of the arrows should be bidirectional and pointing in every which way because this is a process of discovery, essentially.

Sometimes when you're writing user stories, you think, 'Oh, we forgot about that persona.' Or when you're paper prototyping, you think, 'Oh, we forgot about that.' And so it's going back and forth among these different techniques that I think leads to a successful project. 

So a little bit of detail about each of these techniques. First, personas.

And what you see here is a snippet from schwab.com. This is a pretty extensive persona. It's not necessarily what I'm recommending, but it's a good example. Here is Jason, a typical user of schwab.com. And that's what a persona is. It's a composite of your users. And an important thing about personas is they become virtual members of your team.

Personas generally capture behaviors, motivations, background, demographics with the idea that you want to create a real person, a person that you can relate to as you are developing the product.

And so I think it's especially important for developers to feel empathy for their users, and I think this is a place to start. It's also a good way to identify different types of users and their goals.

Let me shift over to a real persona. This is from a project, a system that my team built over the past couple of years, and we continue to iterate through it. It's called University Notes. It's been re-branded now, Advise and Connect. University Notes was a partnership between the OCIO CFO's office of the University, Office of Undergraduate Education and Arts and Sciences, with my team providing the application development resources.

Academic advisers at Ohio State. In Arts and Sciences, their audience is 16,000 undergraduate students. For the entire university, it's 38,000. Students come in, they schedule appointments with their academic advisers, and the topics range from, for example, ensuring that they are meeting the requirements of the general education curriculum, applying to graduate. They also talk about personal issues. There are many, many, hundreds of reasons that a student might come in to visit an academic adviser.

So the system was designed to be electronic note-taking for the advisers. With that kind of load, they needed essentially a case management system that would allow them to record their interactions with the students after their appointments.

With that kind of load--and a student might not necessarily see the same adviser every time they come in, unfortunately, and so this provides a continuity of service. So when a student shows up at an adviser's office, they don't have to start over with their entire history, their entire career at Ohio State.

So here's a real persona from our project. This is Jen. She's a GEC academic adviser--that's General Education Curriculum--at Ohio State. She's an experienced adviser. She's been working for Ohio State for 10 years. She's technically savvy. She's very knowledgeable of GEC requirements. And she specializes in more challenging cases, which could be reinstatement to the university after a dismissal.

And you'll notice this is a much shorter persona than the schwab.com example, and I think for us this was enough. It's just a matter of identifying those different types of people.

Other personas for us were administrators, career counselors, advisers counseling honor students, athlete advisers, so a range of users that have different types of goals, different needs for the system.

You can imagine that advising honor students is very different than advising undecided majors. So that is the point of having a persona is to capture that range.

OK, so we've got personas.

The next thing we work on is scenarios. Scenarios are narratives of real situations for our personas. So it's putting a persona into the context of their day-to-day activities. The idea is to capture the typical behaviors of the users.

And it's important to do this for a couple of reasons. One, we found it's a very good way to test our assumptions and also to discover lots of stuff that we didn't think about. And it's also time to start thinking about what the system needs to do for the user.

Here's a real scenario. Jen has a one-hour appointment earlier today with a student who had been dismissed from the university a couple of years ago due to poor academic performance. The student asked Jen to help her file a petition for reinstatement to the university. The student was also visibly upset about some personal issues. Jen wants to record what they talked about for future reference.

And I forgot to mention this earlier with the persona but Jen's goal, she's busy, she has a lot of advising notes to enter, and she wants to do it very fast. That's her goal.

So as I mentioned, good scenarios result in a lot of 'what if?' questions that test our assumptions and get us thinking about things that we didn't think about before.

And in this example, for example--sorry. This example, a couple of questions that came up: does a note need to be categorized for the advisers? If there are hundreds of reasons, do we need to keep track of those? How will we find the student in the system if they've been dismissed? Are there FERPA and security issues? Yes, definitely.

Does the adviser need to save drafts of notes? If they have back-to-back appointments, are they going to actually have time to write the full note or do they need to be able to write a little snippet of the note and come back earlier?

So these are the kinds of questions that we needed to address both technically and also some business decisions needed to be made around this. Should the advisers be documenting personal issues? No, probably not.

OK. User stories. This is a technique from extreme programming originally. Mike Cohn has done a lot of work on this topic and I would recommend his books, if you have a chance to read them.

User stories are where we put together our personas and our scenarios, and we start thinking about tasks. What are the specific tasks that users need to accomplish in the system to meet their goals?

So user stories are short statements of functionality. They are written by the user in the language of the user. This is very important. They are not technical. They focus on the 'what' of the system, not 'how'. This is not about interface at this point.

Why we do it. Well, first of all, I should mention the format. It's as a persona. I want to task so that...business goal--and I'll give you some real examples here in a second, but the reason we do it, we found it very useful is it's a very fast way to generate requirements. Very fast.

We hold story-writing workshops, and those are timeboxed-structured brainstorming sessions. The end users, the customers sit on one side of the table, the developers, the tech team sits on the other side of the table, and there's a facilitator who encourages the user to just do a brain dump of everything that they want to see in the system, the things that they need to do.

There's no censorship in these sessions. It's just 'throw it all out there on the table'. And we ask the users to write each one user story per sticky note. Sticky notes is what we use. Very technical. And those sticky notes then become placeholders for the later conversations.

So this is the 'just in time' that I was talking about. Just in time: we'll put on hold those details until later, closer to the implementation phase.

User stories are also, I think, importantly, a collaboration and communication tool.

As I mentioned, the developers are sitting at the table, which can be a new experience for them. I think I alluded to this earlier--if you don't want to write requirements down, you need the developers to be listening to the end user from Day 1. It's a given.

So the user stories sessions, the story-writing workshops, it's an opportunity for the developers to listen to the language the user is using, also to ask clarifying questions--"What do you mean by that?"--and it's the opportunity for the developers to start establishing a relationship with the customer or the end users.

So this is kind of the 80/20 rule. I want to make that point. You have to kind of let go of perfection in Agile software development. It's all about iterating.

And so when you come out of that story-writing workshop, you should have no expectation that you have all of the requirements. You are probably going to have the big ones, and it's going to be enough to get started, but you can guarantee that you're going to discover new things as you go along.

OK. As promised, here's some real user stories. This is actually a photo from one of our story-writing workshops. John Wander, sitting at the table, and he's a dean. And so this is very interesting to have our dean generating tasks. It was a great experience for the developers who were on the other side of the table and I'm attempting to facilitate. This is a very special opportunity for a developer to actually interact with the dean at the University, and I thought it was a very important experience.

Here are a couple of the user stories that came out. We had, I don't know, probably 50 user stories.

As an academic adviser--so as a persona--I want to enter a note after an appointment with the student--so that's the task--so that there is a written summary of what we've discussed--so that's the goal. That's the business goal, that's the goal of the end user.

The second one, as an academic adviser, I want to see a student's entire history of notes so that I can prepare ahead of time for my appointment with the student. So again, as a persona, I want to do something so that I can accomplish something else.

OK. So I talked about three techniques: personas, scenarios, and user stories. Persona is about identifying the goals of the users. Scenarios are about context. They are narratives that capture the typical behaviors of day-to-day activities of those personas. And then user stories are where we put the goals and the behaviors together and we start to think about tasks. 

And put all those together and the next step is probably the most fun: paper prototyping. I'm in love with paper prototyping. I fully believe in it. I would encourage you to try it.

Paper prototypes, I think--and a misconception on my part when we first started doing paper prototyping was it's just a sketch, it's a sketch of the system, it's about the interface.

It's not at all about the interface. It's about building the system on paper using paper. So get out your sharpies and your scissors and your glue stick and you're going to be cutting up a paper into buttons and drawing on that paper. That's the point of this exercise is to take those prototypes and have the user sit down, give them a task, and ask them to simulate completing that task with your paper system.

How this works is I'll show you a video in a second. It's really excellent. The user is sitting on one side of the table using their finger as the cursor or the mouse, or they can use a pencil. And then the developer is sitting on the other side of the table acting as the computer.

And then we have the facilitator that assigns a task and also encourages the user to think aloud. That's very important for the user to talk about what they're experiencing. If they can't find something, it's not where it's supposed to be, they don't understand something, these are good indications that your system is not very intuitive.

So I'm going to attempt to play a video here.

Sorry about that. Looks like I'm going to have to bring it up.

I'm logged out. Do you guys remember what the password...?

What is it?

I don't think you'll be able to hear this.

OK, so this is a paper prototype of an HR system. I found this online, and I think it's exceptional.

So the user's task is to apply for vacation leave. So he's going to write his start date.

OK. Select a calendar. The calendar pops up. And selects the end date. OK.

Once the C had dropped down all the leave types we've got to drop down. Fixed annual leave.

Beth Snapp: Submit. Error.

[Laughter]

Beth Snapp: "You have entered invalid dates." Very friendly error message. And if you heard the audio, the end user is really tripped up right now because the message did not give him any feedback about what's wrong.

OK. So he doesn't know what to do, so he goes back to the start date.

We've got our calendar. Selects another date. Well, I'm going to leave at the 18th, he decides. Now let's try it again. Submit.

Error. "You have exceeded your leave balance."

I'm going to stop here, but just to summarize... As the end user or the user goes through that video--by the way, we had a video of a real paper prototyping session from University Notes but there were some technical difficulties with that, so I picked this one from YouTube which I thought was excellent.

If you watched the entire video, the user realizes he has only three days left of vacation time. So what would have been more intuitive for the system to do?

Audience 3: Can it read it?

Beth Snapp: Absolutely. And at the end, he does all this work and he doesn't know what to do next because he says, "How do I exit?" There was no exit. There was no indicator of how to exit the system. So he was like, "Oh, I see 'log out' at the top."

So that is the value of paper prototyping right there. You know instantly if your system is intuitive.

So this seems very low-tech, and it is, but that's the point. It doesn't look finished. The danger when--and developers love to do this, jump into the interface way before the requirements are even defined, you get a really spiffy-looking system and you sit a user down, and what does it tell them?

Audience 4: Did you like the artistic development more than developing a product that's going to work for you?

Beth Snapp: Absolutely. There's also another reason, I think, related to what you are saying, and that's, if you sit me down in front of a system and it looks done, then why am I there? Obviously, my opinion is not valuable. You've already got it done.

So having something that doesn't look finished communicates to the user, "Hey, we really think your feedback is important. We want to hear it. So help us design this system."

It's also very easy to create and change. You haven't invested any programming time, so it's almost a form of risk management. And it's a good way, as I mentioned, to validate your design and also to test usability at the same time.

Something that I found also is, it's an informal way to collect sign-off. And sign-off is actually more meaningful than a pile of documentation.

As I showed you in an earlier photo, we had the dean there, the product owner of the system. He saw what the system was going to be. He saw what we were going to deliver to him. And he knew what he was getting into, what we were going to deliver. And he felt good about that. So he knew what he was paying for, essentially.

And, again, I think when you abstract too much, there can be a lot of surprises, and that relates to those illusions of agreement. And I think paper prototyping is a way to avoid those illusions of agreement.

So I mentioned that this is an iterative cycle, and the way I've presented it today is linear. But I think you should know that in our systems that we're building, it's very iterative in the sense that we'll take on a couple of the big features, go through the process, have a paper prototype of those big features, send the paper prototype over to the developers, and start the cycle all over again with other features. And that's currently what we're doing with the second version of this product.

So right now, with University Notes, we're building student access to their notes and we're also building a new way to enter notes for advisers. However, those weren't all the features that we proposed.

So we're going to start with those two, we'll go through the cycle, have those defined in a paper prototype, and then we're going to start all over with the other features that we proposed, so you get a sense of when I say 'iterations'. And this is very supportive of the Agile approach, key being 'iterate'.

Oh, there's another thing I should mention. With paper prototyping, the way we do it is we experimented with having a couple of users there at the table at the same time. Does not work. One user tends to shut down and let the other user start talking.

So what we find is we like to do single-user feedback sessions. And because it's on paper, we actually have edited the paper during the session. For example, this is crazy, but we forgot a 'save' button, so we wrote 'save' on the paper and said, "OK, try it now."

[Laughter]

Beth Snapp: It's true. And also, by the way, the computer can be very slow in these sessions. It's fun to see developers shuffling paper all around and trying to figure out what's next.

But my point is, it's incremental in the sense that one user steps away, we refine the prototype, we have another user come in, they tell us different things, we refine the prototype. Another user, refine the prototype. We keep doing this until we're not hearing anything new.

And when we stop hearing anything new, then we know we've got a solid paper system, at least. And that's when we can move into the development phase.

OK, here's some real paper prototypes from the University Notes project.

Audience 5: What if you get...from different users?

Beth Snapp: I'm sorry?

Audience 5: What if you get the requirements of the design from different users?

Beth Snapp: Yes. That obviously happens. What we do is, we had a customer proxy on our project who made decisions on behalf of the dean who was the product owner. So sometimes really minor comments and you can use your best judgment based on best practices of usability, but when it's a key feature that's being debated, it's time for the customer to step in and make the decision. I hope that addresses your question.

Audience 6: Did you ever get a group?Did you ever get a group, especially since this is internal?

Beth Snapp: I can't hear you, I'm sorry.

Audience 6: Do you do group sign-off?

Beth Snapp: No, we don't. Actually, we try to avoid sign-off as much as possible because it can be a negative experience. It becomes more a contract. And we try to avoid those as much as possible by collaborating from the beginning and also having a single product owner. When you have multiple product owners, you are in trouble. So we insist on having a single product owner before we start a project. So the sign-off is with one person.

OK. I just want to buzz through this pretty quickly. Some screenshots of a real prototype.

And by the way, this whole side, this whole right-hand side--right for you, yeah--all this fancy filtering and tag clouds, that didn't make it in the real system. This is about an ideal system on paper that didn't end up in actually what we coded.

This is the real system, Advise and Connect. And this is where the advisers enter their notes. This is our student details page. So we're pulling in people's soft data, displaying it to the advisers.

And so I want to wrap up here, as I see that I'm almost out of time.

So let's return to the original question, which was, how much is enough documentation? How much is enough planning? How much is enough design? And we found that we have achieved a balance, we believe--just enough, just in time--through the four techniques that I've described today.

This might sound a little bit radical, but paper prototypes, that's all of our documentation. That's it.

Paper prototypes, they're a visualization of your requirements. They're not words. It's your system. And that's what the developers code against. Because of the sign-off that you received, the buy-in that you've gotten from the users, we don't need any more than that.

And we've also had the developers, they're sitting at the table from Day 1, they know the customers, they know the end users. If they need a question answered, they call them up on the phone.

And so I guess my key point here is collaboration and communication. That's what leads to a successful project. And these are techniques that we've used to encourage collaboration and communication.

So here are my final thoughts: if you're striving to be an Agile software developer, I think these are three things that you need to keep in mind. Three very important things.

And it doesn't matter what framework you use. You can use Scrum or XP. We've experimented with Scrum. Any Agile framework, the values are important. The Agile values are important, not the framework.

You want to value your working software over documentation. Remember that the software is your legacy. Get to something real, real quick. And stay focused on your customers' goals.

So, thank you. Does anybody have any questions?

Yes?

Audience 7: [37:45 Unintelligible]

Beth Snapp: That was a bell and whistle.

Audience 7: Yeah.

Beth Snapp: We probably will never add it because we simply don't have time and resources. But it was really cool. We loved it. But we just don't--we have to focus on the core features. And, again, that just didn't make it.

Audience 8: Have you or anyone else experienced a bit of tagging on site development than, say...

Beth Snapp: Websites?

Audience 8: Yeah.

Beth Snapp: It didn't work for us, we tried it. I think because, in our case, our sites don't have a lot of functionality, so I'm not sure what we would test with a paper prototype, because a paper prototype is more about interaction. So we thought we could do it, and it just didn't work. It wasn't comfortable. But as we add more and more functionality to our websites, I think, yes, it will become more and more important.

Audience 9: [39:04 Unintelligible]

Beth Snapp: Right.

Audience 9: [39:22 Unintelligible]

Beth Snapp: How did we get into paper prototyping? Diane Daggerford, my manager, attended a conference--I believe it was one of the user interface conferences--and learned about paper prototyping and brought that back to us. And we decided to try it out, and we fell in love with it. So it was kind of we just stumbled upon it. Does that...? OK.

Anybody else? Sorry, I'm having trouble hearing.

Audience 10: How long did you prepare for the application?

Beth Snapp: Well, as I mentioned, we had started experimenting with Scrum on our team, and the value of Scrum is very short iterations. We were doing two-week iterations with a potential of releasing the production after the end of two weeks. I'm not doing that so much anymore, I think, because currently our customers are a little less involved than in the past.

So I think right now I can be honest with you, our issue with our system right now is political, not technical. So technically, I am very confident that we could release something every two weeks.

However, our product owner needs to sign off on that and be OK about that, and there's also their business decisions that of course need to be made along the way that can hold up the process.

Thank you.

[Applause]