Gathering Requirements, And Rapidly Building Proof Of Concepts

To Jordan at UXDX Community: Dublin. Video: https://www.youtube.com/watch?v=le2AXfYUJQU

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why software projects still fail

[00:00:09] Thank you so much for your time, and thank you for choosing me over the beautiful sunshine and the canal. Here today I have to start with the legally mandated disclaimer that all these opinions are mine and not those of the parent company of Google. It's a big problem: software is still failing regularly, and it's failing too much as well.

[00:00:33] This data is from the CHAOS report. It says that two thirds of projects come in over time, over budget, or don't meet the initial requirements, and 20 percent of projects fail to be delivered altogether. Let's talk through a quick high-level overview of gathering requirements, grouping them, building prototypes from these requirements and delivering success to your customers.

[00:01:09] What is it not? This isn't an example of building a global app or the next big hit that's going to take over the world and be massively successful. In my previous role in Laconic [?] and in Google currently, I have focused mainly on building custom software for people with an idea, to scale it out to their customers. But it's very much a personal one-to-one process with individual clients: going on site, meeting them, talking to them, building something that satisfies their needs.

[00:01:45] The main thing I'm going to focus on today is having effective conversations with your customers, to discover what they actually need, not what they say they want; grouping all of the notes you get into requirements; and then iteratively improving and building prototypes from these requirements.

Common mistakes and a failed CRM project

[00:02:09] These are the mistakes I've made, and the common mistakes. I still make them, and one of the reasons I'm making this talk is to reinforce that with myself. I jump to solutions too quickly: when someone's talking, I'm like, "I think I can solve this," and you don't really effectively listen. I make unstated assumptions, which everyone does: "I know, I know what this says, I've seen something like this before." But everyone's different, everyone's unique. And trying to rush through and deliver something too quickly can be an issue.

[00:02:42] I'm going to start out telling you probably my worst mistake. It was actually the biggest learning experience of my career, so it worked out well; I think all mistakes should be learning experiences. I was working with a large insurance broker, and they had a simple ask. They wanted to build a lightweight CRM system. They said Salesforce was too much, they didn't have anything on the market, and all they wanted was a simple way to track their leads: really lightweight, really easy to use, powerful and customized for their needs.

[00:03:14] I said, "Hey, this can be a successful project. I can do this, this is fine, this is the greenfield project I've always wanted." And after four months, I think we were receiving 10 new feature requests a day. Everyone was unhappy, people were snapping at each other, we were assuming the worst intentions from our clients and stakeholders, and they thought we weren't delivering. There was just poor communication all around. We were feeling burned out; me and my coworker were working 15-hour days trying to deliver features on time. In the end the project was a complete and total failure. So what went wrong?

Building rapport and asking open questions

[00:04:06] The first thing we failed to do, and it's easily overlooked, is building rapport with your customer. It's super simple: just taking the time to actually talk to people, get to know them, make a bit of small talk. It avoids being seen as a transactional person; you become somebody who's there to help, who listens to their problems. Even just chatting about personal things: do a bit of research on the person, talk about football, talk about how the company is doing, are they meeting their targets, that kind of thing. Get to know them. If you're really desperate, you can talk about the weather.

[00:04:52] The next stage is to ensure you always ask open questions. It's too easy, especially when you have an idea in your head already, to ask yes or no questions to validate your idea, and you don't get the rich data and rich knowledge that comes from talking to your customer one-to-one. There are a couple of examples here. Why isn't it working for you right now? What goals do you have in general? What does success look like for you? There are lots of other ones that come naturally. It can be difficult to do this, and it's easy to slip back into really simple yes/no questions.

[00:05:28] Avoid closed questions. Even "Do you think it'll be useful?" is not a great question. You could just say, "What do you think could be useful about this product? What do you not think would be useful about this product?" Cover positives and negatives as best you can and work forward that way.

Active listening and asking why

[00:05:47] And finally, very trendy at the minute, but actively listen to the customer. Again, don't come up with solutions while they're talking. Really carefully listen to them, summarize what they've said, and repeat it back to them to confirm that you understood their needs correctly. Summarizing and confirming will be a common theme today. It's vital at all stages to ensure that you accurately understood what people actually need.

[00:06:12] Similar to earlier with the five whys: I'd vaguely heard of that before, but I hadn't used it that way. I generally find I deal with different kinds of stakeholders or clients. Some people are very detail focused, and it's very difficult to get them up out of that level, so I always ask why questions, like "Why is that important to you?", to raise them up and try to understand their high-level goals and their midterm tactical goals. Other people are very vague with what they want, and it's important to ask, "How exactly do you want this to work?" to get them down into details and get a better understanding of what that's going to look like.

[00:06:57] When do you use these skills? Dealing directly with customers, but they're also vital skills in dealing with internal stakeholders. I've used them when I've taken over projects midway through. Use them with your manager or the person handing it over: why did you make these decisions? Try to deeply understand the reasoning behind every decision. And even in large public-facing things, with lots of user research and other inputs, these are still vital skills to know for your stakeholder interviews and other parts.

From notes to stories and a vision statement

[00:07:27] Next, you have a ton of notes. I think some of my colleagues have referred to my notebooks as looking like a serial killer's notebook: random all caps scribbled around and crazy things around the place. To try to bring order to chaos, I generally lean on one of the oldest ways that people have brought order to chaos, through storytelling. You try to identify your main needs and group these together into narratives and general stories, which then define the users' problems and define different solutions we could have. It becomes user stories, which you'd be well used to.

[00:08:08] One extra step I like to take, from Alan Cooper, is to build an overarching problem statement that clearly defines the problem for the customer at a high level. This example here was taken from a recent project at work. It's an internal-facing product for our salespeople, and people were just finding it difficult: they want to create stuff for YouTube, but they've no idea what to create. There's so much out there, no way to tell what's popular, no way to tell if it's oversaturated.

[00:08:40] Again, it's essentially a very high-level story, which you can then confirm: is this actually a problem, and will my vision statement actually move me towards a solution? The vision statement is there to act as a guide for everything you do from then on. You think, "Okay, I'm going to add this feature. Does this align with my vision statement? Is this relevant to what I'm going to do?" I think this ended up just being a basic dashboard.

Paper prototypes and low-fidelity prototypes

[00:09:10] Now on to the fun stage, where you get to actually start building the prototypes. It depends on different projects; I skip many of these stages. Obviously, if there's no UI, if I'm building an ETL pipeline or a standard data processing workflow, you don't really need to be showing people mocked-up UI of something that doesn't exist.

[00:09:35] The first one I always start with, if the project has a UI, is quick and basic paper prototypes. I didn't draw this one, because my drawings are similar to my notebooks; they're a bit of a mess. I personally prefer almost a whiteboard iteration. If I have a chance to sit in the room with my colleagues or with my stakeholders, I actually sit there and draw my solution freehand, explain what I'm doing at each step, really communicate that through, and ensure again it's what they actually need and what they want.

[00:10:08] I then like to move on to low-fidelity prototypes. Personally, I do these using spreadsheets or PowerPoint-style software; I've used all three of these. I should probably be pimping Google Slides, but to be fair, all are good for this. In this case, master slides are your friend. Create a master slide of your basic UI navigation, and you can just reuse that for all your different application states. By that stage you're already grouping your application into components; you can identify reusable components, and it's very powerful.

[00:10:45] It depends on your stakeholder and on your client. Some people, if you give them a low-fidelity prototype, will look at it like, "What is this?" But even if you don't share it directly with your client, it's a really good way to validate your ideas and ensure that what you're planning is actually going to work well.

Interactive and functional prototypes

[00:11:09] This is just a short sample; I haven't even used half of these. You have Sketch, InVision, and I think Adobe XD. They're all perfectly fine. My favorite is Figma. I don't know if any of you have used it; I think it's fantastic. It lets you collaborate in real time, people can comment on it, you can bring in other people to get direct feedback, and you can generate really cool, really powerful interactive prototypes. I am going to pimp it out even though I don't work for them.

[00:11:45] Finally, I like to build a functional prototype. I'm not even sure if that's a real term or the accepted term, but essentially I like to start building the UI in the front end, if applicable, and I usually use a framework. I personally really liked AngularJS. I don't like Angular now, which is a bit awkward. React seems really cool, but the first time I saw the whole JSX, HTML and JavaScript mixed, I was not going near that. And I really like Vue, so I stick with Vue.

[00:12:19] One of my last major UI projects in Laconic [?] was built in it: a large meeting planner, check-in kind of application. The really cool thing is you can build your entire front end just using dummy JSON objects at the back end, and changes are really quick. You don't have to touch the server, you don't have to touch any data layer, and you can give fully functional applications to people, which will then form the basis of the app. Once you've iterated through user feedback and got a front end that works well, all you have to do is implement the back-end services, and you've developed a fully featured proof of concept, hopefully in record time.

Conclusion

[00:13:02] That would be my conclusion. The key elements I'd like you to take away: always listen really carefully to what your customers are saying, summarize what they said and repeat it back to them, and make sure that what you think and what they think are perfectly aligned. Then rapidly iterate and test everything as best you can. That way I hope you'll build products that your customers want and need, instead of building products with such reservations [?].