“So if a guy has a fast boat, he is going to be hard to beat.” - Dennis Conner, yachtsman, also known as Mr. America’s Cup
Imagine you could go faster. That thrilling feeling of being in that sweet spot where you are entirely in control, and yet you feel that, at the same time, you are being pushed by the sheer motion you have created. Imagine that the act of designing an app was stripped of most of its constraints, distractions, retractors, in such a way you could focus on—well, on creating the app.
Maybe you could go faster. No, you wouldn’t have to run the entire time but neither would you eliminate running completely. But, maybe if things were better organized, if everything that you needed was precisely where it was supposed to be beforehand, it could happen. If design didn’t always look like an extreme sport.
You can go faster. You can do it by mastering your tools or by skipping steps or by not sleeping. The latter two can do the trick for a while, but you will eventually crash.
More Haste, Less Speed
Imagine yourself in a boat during a storm. You get pounded by the waves, and you work a lot. But in the end, you are just trying to push yourself out of a situation that is not comfortable to you, one where outputs are usually barely positive. But, at the same time, you can’t just wait for the storm to pass. If you don’t take action when it is needed, you will end up drifting, abandoned to your luck, just waiting and hoping someone will notice your boat.
The same applies to your app designs. Whenever you are trying to rush out of a situation, you will probably end up with lots of hours in a project with minimal value.
When Apple launched iOS6, they were determined to kick Google Maps out of the iPhone home screen. They developed their own map application, and it was included in the new OS. But it was clearly not ready for general availability. Within minutes of launching, the App Store got flooded with negative feedback, and users were reporting some embarrassing bugs.
But, again, like being in a boat in a storm, you can’t afford to take too long to launch because you’re waiting for that perfect moment that never comes; you can even proudly launch but then vote your app to abandonment until it dies.
So in the middle of the storm, how do you balance business goals, user needs, and also development limitations with your craving to create an app that is better and greater than that of your competition or even your last work?
More than that, how do you design something significant for your users right now without compromising the experience after every meeting with stakeholders, developers, and everyone involved? How do you not succumb to the pressure of idleness, discredit, and habit or find yourself forever stuck on wishes for phase 2?
The answer is to go faster. Set sail and go. But know exactly where you are going.
Low-Code, Full Speed Ahead (in Design, Too)
If you are currently working in agile sprints, you think you’re already at full speed, right? Every other week you have a new challenge, you are on a multidisciplinary team, and you discuss your options with customers, users, and workmates. You follow a process and select your research and inspection methods according to the challenge at hand.
Someone asks you, “Why is this button here?” You answer with reasoning and test results. There is nothing that you’ve left solely to chance, assumption, or aesthetics. You’re doing solid work.
But then there comes the day when you find yourself working with a company that does things differently. Faster, too. Complex applications are being developed and delivered in a few months and people who claim to do what you do—UX, UI or both—have their white hats on and refuse to sacrifice quality and design when facing tight roadmaps.
It’s like their boat is faster than yours. Way faster.
The fact that everyone around you is doing rapid application development with a low-code platform is like they got up at 5 AM, and, instead of lying there looking at the ceiling, they went immediately to the deck and set sail before you even started your research. The platform includes a collection of pre-built blocks of common application patterns, which can be quickly dragged, dropped, and configured in templates.
This means that they’re playing with modular pieces: they go faster, and they’re probably having fun.
Rapid means rapid for all. How can you fit user experience and user Interface activities into the roadmap (or nautical chart as the case may be)? If you have a three-month project, how can you coordinate with users, customers, and developers so that you keep feeding the beast at every sprint without skipping steps or being disloyal to the gods of user-centered design? All while still sleeping at night, that is.
Changes in Latitudes, Changes in Attitudes: Get a Plan in Place
So you’ve got the technology to back you up; now you need to start sailing. Faster than before, just to catch up.
You first have to realize that most big decisions need to made upfront. You are expected to iterate, but there won’t be enough time to change course dramatically. Not in a three-month project. Moreover, the customer won’t forgive you if the app suffers from weak user adoption down the line or if there are productivity losses or lost business. And, you won’t forgive yourself if it is built without regard to how it will be used.
The decision-making process will have to be extremely pragmatic. It is a typical story that you are asked to design an app from scratch in a couple of weeks. In some crazy scenarios, you are asked to propose in a week or in three days. How do you achieve that feat without skipping steps?
Start by trying to understand what you’re being asked to do. Understanding always means kicking off with business analysis—you need to identify the crucial business goals and metrics so that you take well-informed design decisions. From there, you need to go and meet the users. Observe, interview, use whatever research methods you find appropriate to identify pain points and user needs. If this were a 2-week project, 2 to 3 days would be enough.
Proceed with exploring hypotheses to the problem. This is when you begin sketching or wireframing to be able to communicate the structure and the flow visually. Start with low fidelity so you can do it fast. You do this so that you can go back to the stakeholders for checkpoints and then to the users to test what you did. You don’t just do this once or twice; you do it until. The idea is that your design hypotheses change and evolve according to feedback from both stakeholders and users. In a two-week scenario? This would last from day 3 to 7.
End by materializing your proposal. As you’re making choices, testing, and refining, you’re already going somewhere. And as you resolve to go to high fidelity, there is a consensus that you’re taking the right direction. So, three days to visual design will suffice; since you’ve been working on crucial screens, your research is done and big decisions are made.
But remember, checkpoints are not optional. They’re like trying to sail with no wind. If your two-week project ends with a final presentation, what you present can only be a surprise for special guests, never for who’s paying the bill.
Faster Is Not Better: Better is Better
Designing faster is possible, even if you’re not coming from a low-code platform and you have to design everything from scratch, as long as you:
- Take control of your time, defining which activities are essential to your research.
- Spend more time with stakeholders and users and less playing alone in the artboard.
- Define a strict agenda with the people you need so that you are always getting feedback.
- Don’t get emotionally attached to your designs and understand that comments, reviews, and discussions will bring everyone on board.
- Don’t sacrifice the quality of your work just for the sake of being faster.
So let's go back to your boat. Even if you don’t really care about sailing and you never knew the difference between port and starboard, like me, bear with me and go back to the boat for one more second. Let’s focus on caring about the ride, how enjoyable it is, and how it will get you to where you want to be with ingenuity and intact integrity. The boat can be a car, a bicycle, or your own two feet. A low-code platform, a well-thought process, or the weight of your experience.
But since this is a boat, you are the freaking best yachtsman. No way you won’t win.