UX For Startups

The pressure of immediate success has driven countless startups to failure well within their first year of liftoff. These are organizations that are taking their first steps out into the world, wobbly as they may be, and are expected to emerge with a flagship product or service that they’re based around. The problem is, they’re new. They’re babies. Every startup begins on a buckling platform without the time or resources to spare.

Every extant business with skin in the game has already established a support system that startups lack to keep their projects moving at a pace they’re comfortable with. Money for startups, however, is inherently a scarce commodity that severely limits their chances of creating a successful business. Being strapped for cash, they need a winner that best utilizes the UX design practice.

UX (User Experience) fulfills the fundamental roles that dictate the value your product holds. UI (User Interface) may be important in how your user base interacts with it, but UX is what brings them back. Do they enjoy it? Does it serve a functional purpose? With so much riding on it, it’s important to start off with a high standard.

Take input from the customers’ experience so that you might act on it. Blindly thrashing in the dark and guessing at what your consumers want if a fool’s game. Mastering your UX game is the quickest way to push your startup off to a strong start, and doing so requires strategy. There are two primary strategies that are tailored toward designing UX for startups: Minimal Viable Product (MVP) and Lean UX. We’ll talk enough about both to get you underway.

Minimal Viable Product (MVP)

Everything has a first draft. Whatever field you’re in, the best advice you can ever be given is to stick to a project and, regardless of how you feel about its progress, see it through to completion. We have an innate desire to create a masterpiece on the first go-around, but are equally restrained by this non-permissive mindset. The only way to learn and make something better is to first find what should be changed.

Creating a Minimal Viable Product excels in exercising feedback and converting that into results. We said the most important thing is to finish the draft, and that’s how projects should be treated - as drafts. They’re not perfect, nor should they be. By creating a product that is the simplest, most basically functional version of an app, you then proceed to evolve it on the next draft.

All an MVP needs to do, at least for the first version, is work. It may not be pretty, but it should deliver customer value well enough to be considered an eligible app. It’s a smaller version of a full app, far and away from what it will eventually be, but working through it stage by stage, version by version, allows you to extrapolate on the feedback provided by the user base and roll out new and more features with each update.

There is no more perfect form of data collection than what can be provided by the test audience. The more they tell you, the more you’ll be able to understand what the user wants, needs, and how you can develop your app to meet those demands. Developing a series of MVPs as an evolutionary process is what allows for feedback from the users along the way, keeping costs low by being able to release the software early without having to develop the full project.

If you’re interested in more detail about MVPs, you can visit this “Minimum Viable Products (MVPs) - What Startup Weekend Taught US” resource page. It contains a greater depth of focus on MVPs in particular than this article will.

Now, let’s contrast this approach with its polar opposite: the Waterfall. Whereas creating MVP products is a cyclical process that incorporates user feedback as a major component, taking the Waterfall approach is extraordinarily linear. Rather than making several iterations of the same product, an entire program is procedurally worked on step by step before the final product is launched. It’s an approach that gets you from point A to point B, no detours.

While the Waterfall approach predates most modern developing cycles by a couple decades and still retains popular usage with 95% of companies, it has more than a few glaring drawbacks. For starters, the product is regarded as one complete piece for the entirety of the development cycle. Without working on it piece by piece, vis-a-vis MVP, the approach takes considerably longer to develop.

No product, prototype or otherwise, means that your organization isn’t making any money. Without test iterations to deliver to the public, every Waterfall project is a sink that absorbs funds and resources until it can be launched. Moreover, locking your development team into a project that’s insulated from outside feedback increases the risk of widespread failure once the project does finally reach the market. If the consumer is entirely ignored, then there’s no way of knowing for certain whether your work meets their needs and desires.

The Lean Loop

As you can see with this visual representation, there’s no established exit to the loop. It’s intentionally designed to replicate a constant process, endlessly creating and returning to a project on a fast and effective basis. Because it’s a constant process, and although these are individual steps that form its framework, it’s important to follow along all of it to enhance the product. Skipping any one of them at any point in the process can grind and slow your overall progress down unintentionally.

Ideas

While you can technically start the Lean Loop from any of the steps, it’s easiest to begin with something intangible. You might have already developed a project from the MVP method, or perhaps you’re starting completely fresh, but this is the section that regurgitates innovative plans for the future of the product.

Consider the ideas segment where you put your hypothesis, divining information gathered from previous iterations. The feedback you’ve learned from the user base can be put to use here, putting into motion changes to be made to the product. Anything that you learn from the previous iteration are molded into new ideas here, informing where and how you go about developing the next one.

Build

While this step may say imply that you’re building the app, we’re not quite there yet. You’re more accurately constructing the framework of what your next iteration will look like, designing a structured approach for the rest of the project. From here, you will elaborate on the idea you had from the previous step and turn it into a usable and viable feature for the project. Basically, you’ll be expanding on it and considering how it should be implemented to best suit the next steps of the cycle and the consumer.

Code

If the build step is the framework, then coding is the bricklaying. You’ll be turning your concepts into tangible code, filling in what the building segment laid out and creating a tangible solution to the proposed idea. By the end of this step, you’ll have a finished iteration of your product to be fully tested.

Measure

Once you have a coded product, you’ll need to test it. While testing itself is an assumed step within the circle, measuring is the portion that actively records everything relevant within the sphere of app usage. You’ll be gathering what was gained or lost throughout the development process with analytics or feedback.

For instance, you may want to track what people are or are not using, especially certain functions of the software. If you find that one of your new changes to the code resulted in consumers not interacting with newly included functions, or perhaps older functions were rendered obsolete by the reworking, you may derive new conclusions regarding what may need changing in the next iteration.

Making those deductions isn’t a part of this step, however. What’s important is figuring out what the most important metrics to track are and obtaining raw data collection of anything relevant to those statistics.

Data

Any measures you take from the previous step are going to be convoluted and virtually impossible to obtain anything meaningful from. It’s a jumble of data that can’t be sifted through in its basic state. That’s why, for the next step in the Lean Loop, your job is to make sense out of the chaos. Once you’ve gathered the information, the next logical thing to do is compile it.

By compiling the data, you’ll be able to properly analyze the influx of information for focused interpretation. It may not have made much sense in its raw form, but once you figure out what the measurements mean, you’ll be able to draw reputable conclusions that inform the next step in the process.

Learn

This is arguably the most important step in the entire loop. Without learning from past experiences, any future ideas may be subject to falling in on old, failed habits, practices, and concepts. Learning from failure is what greases the wheels of the cycle, keeping each iteration a natural, tangible evolution from the last one.

In this step, you’re taking what the data says and figuring out what this means to you and your project. Every idea spawns a new framework, which in turn provides the code with a structured outline to follow. Once you have a new theoretical improvement on your iteration, its testing should reveal a trove of new information, which can then be sorted, measured, and compiled to reveal vital metrics regarding the functionality of your product.

Then, once all the other steps are completed, you learn.

By hitting each iteration against a rock, you’re seeing what works and what doesn’t. By learning you can inspire new ideas to improve on the new iteration, either fixing old problems and generating brilliant new solutions. Then, once you’ve finished learning, you can develop an idea and start the cycle over again, perpetually continuing like a snake eating its own tail.

Takeaways

Creating a startup is risky business. There’s not a whole lot of room for error, meaning what you produce has to hit consistent high notes to keep your organization above the waterline. With a limited budget and limited time, the best way to ensure you reach safety is by dabbling in processes that generate products quickly and efficiently, regardless of how rough they are. The goal isn’t perfection, it’s creating something that can be improved on as fast as possible.

You have two options available for that: MVP and Lean UX design. Creating MVPs is the core of what this fast-paced process is intended to do - create a product that’s just functional for base consumer value and get it out there. Through feedback, your next pass on it will make another iteration that’s like the first one, but better. By the same virtue, Lean UX design is just an evolved form of the MVP method, except it creates a system that’s endlessly reusable until you can make the final decision and say, “Done.” At iTexico, we can help you discover the right product to build and build it right so it generates delight for your user through great UX. Feel free to contact us and explore the Nearshore opportunity. 

Hand-Picked Related Reads For You