The importance of early feedback

The importance of early feedback

Matt Shanks

Matt Shanks

Principal Product Designer & Author/Illustrator for children. I'm out to improve the quality of life for everyone who uses the things that I make.

Or valuable research on a shoe-string budget

Let’s start with a hypothetical question. If you had a piece of blueberry stuck on your front tooth after finishing your morning breakfast, when would you like to know?

  • [A] Never
  • [B] ASAP, so you can clean it off before you leave the house
  • [C] After your first important meeting of the day
  • [D] When you look in the mirror during your first bathroom break at work

If you answered B, congratulations, you love early feedback and we at Cogent do too. If you didn’t, you probably have something in your teeth and you should look in to that.

Early feedback in software design and development is critical to making sure we’re building the right thing at the right time. There are many ways to get feedback and to answer key questions along the way, so we’ve compiled a few of our favourite ways of working to help get small businesses there.

Test with sketches

You’d be surprised at how valuable a few sketches can be. If you’ve got an idea for a desktop app or mobile app, chances are you’ve got a pretty good idea of how you want it to work. Well, it’s lucky that websites and mobile apps work a bit like paper… they’re organised and presented as pages. So, we like to start without building software. We’ve had great success from sketching ideas out on multiple bits of paper and then running lightweight Q&A sessions with other people or potential customers of that software. The ‘official’ designer’s terms for this is called “Paper Prototyping”. It’s a proven way of getting great feedback when your idea doesn’t exist yet and you’re just thinking of building something. It takes very little time (and therefore money) to create a set of screens that mimic your app but the best part of it is it also takes very little time and money to change anything based on what customers say.

We’ve tested this way across a number of projects like Covidence, Eliminate Dengue and Rate My Agent and we’ve always had tremendous value and results from them.

Avoid lengthy documentation

As I said, paper prototyping is not a new or unique thing that we do at Cogent. You’ll probably find a few other companies that use it on a regular basis like us. But, as we know, time is money when you’re a start up. We’re different in that we won’t default to giving you a lengthy write-up of the ‘findings’ of any research that we do. We work closely with our clients on a on a day-to-day basis. Each client can have a desk in our office to work from so that anything we (or they) discover can be shared with the whole team immediately. Once everyone in the team (including the client) knows what parts of the sketches worked well, and what parts didn’t, we put our heads together to understand and unpack the impact of those findings and then re-sketch the designs to incorporate that feedback. The difference between the old and new sketches become the ‘documentation’.

It’s tempting to want to have all of these findings ‘documented’ for the future. You know what I mean, a bullet list or nice looking presentation with quotes and screen captures and so on. But in our experience, the product evolves so much in the early stages that any documentation becomes out of date quickly (and therefore pretty useless). Sure, there have been instances where we’ve written up a presentation to provide to investors or other stakeholders like business partners, but we often suggest that the client does this themselves, in consultation with us. Again, when you’re building a business, spending money on having your partnering agency or consultancy put together a Powerpoint presentation is often not the best use of your experts’ time. It’s powerpoint after all, chances are you know how that works.

Iterate quickly and ask customers again

Early feedback from sketches leads to early design updates. And every time you update a design, it may be worth checking that the solutions the team have generated do in fact solve the problems you saw in the early sketches. So, guess what? We sketch again to make another prototype. Now, this iteration part might take the form of a paper prototype, but sometimes the updates are so minor that we can start building some basic software. If we do, we think of it as no more than a ‘digital sketch’ rather than the start of a ‘finished product’ or ‘final design’. We’ll code up the bare bones and make it interactive so we’ve got working software in a matter of days. Then, we’ll put it in front of people, again. These might be the same people who saw the paper prototype, or it might be different ones. That really depends on what we want feedback on. Either way, it’s important for us to make sure that we don’t build too much on a hunch because sometimes, the cost of changing something down the line can be far larger than making tweaks early. It’s like leaving that piece of blueberry on your tooth for a week… it will eventually lead to an expensive dentist bill down the track as the sugar erodes your enamel because it doesn’t belong there. Instead, our sketch and iterate approach is like brushing our teeth twice daily with a cheap toothbrush and toothpaste, it prevents a lot of pain later on for a relatively low upfront cost.

Use a variety of methods

There’s a whole bunch of recognised tools and techniques for testing ideas and software. If I listed them here, you’d probably be quite bored and I don’t want to get in to “UX Bingo”. At Cogent, we draw from a toolbox of well-understood methods to make sure that we get the answers we need. Sometimes that’s having direct, one-on-one conversations with people. Designer-types call these user interviews. They help us unpack motivations, customer wants and needs at a deep level. Sometimes we use surveys; they’re great for getting a large number of people to respond (also known as ‘large sample size’) but often don’t give you good depth of insight. They’re good for asking high level questions though. There’s also ‘analytics’ like A/B and Multi-variate testing which is all about testing different alternatives and are great for testing ideas on a live website or app. Focus groups on the other hand aim to facilitate conversations between customers so they trigger thoughts and ideas between each other. With this method you tend to get more truthful or unexpected insight. Sometimes we just go out and watch people (the fancy name is “Contextual Inquiry”), like we did with the Eliminate Dengue project because often people can’t see their own inefficiencies or opportunities where software might be able to help them. It’s great for generating or validating new ideas.

See, the reality is there’s no silver bullet that’ll give you every answer you need but by using a mixture of different methods as fit for purpose (and importantly, when the research is conducted by an expert), you’re covering your bases and reducing your risk of getting your next feature or business idea wrong. It’s important to know which method to use when based on what you’re trying to solve and how much money or time you have and the best way to know this is to get some experienced help.

And finally…

Getting to the bottom of a problem and finding some answers needn’t take a long time or huge budget. There’s a lot of established methods, all with their own pros and cons. Having worked with start ups for a number of years, these are the 4 ways that I’ve personally found the most useful and because of this, we use them most often. Through their repetitive use, we continue to learn about how to improve them and how we can continue to expand upon our own methods so that our clients can benefit because really, that’s our goal. We want to give small digital business in Melbourne the best chance of success. It just so happens that time and money are precious materials for that. We’ll continue to challenge our own ways of working so that others can benefit, and we’ll share it as we go, just like this.

Related posts

Matt Shanks

Design and Development Empathy – Covidence Case Study

It’s been interesting to watch the ways in which software companies are trying to bridge the conceptual and language gaps of designers and developers. There are frameworks, design systems, collaboration tools and so on that are ‘trying to connect designers and developers in a better way’. And, whilst I use these tools regularly, none of them come close to doing the actual work of listening and understanding the needs of ‘the other’.

Read More
Will Rockel

Aligning design tools with design practices – Part 2

In Part 2 of this series, I’ll step through a practical process for assessing the nature and value of the tools you’re currently using, and your organisation’s design maturity, before suggesting some next steps to help you create a roadmap for a better design culture.

Read More