UX Prototype

Prototype first. Fail fast. How to ship products that delight.

You want to build and launch an awesome digital product, or thinking about redesigning? You’re in luck! — We’ll talk about our UX process at RebelDot and why putting emphasis on research, validation, and prototyping will make or break your web or mobile app.

According to this research, by the time you’re done reading this article, 40 new digital products & startups will have been created. That’s 1 startup every 10 seconds. Truth is, 90% of them will fail in their first months, while others will go around for years chasing their tail without actually doing something about the sinking ship.

The good news is that you don’t have to be one of them. We’ve built dozens of products and even though there is no one size fits all, following a well-structured UX process will guide and take you closer to launching a delightful digital product that people want to use. Think of it as a fitness program: if you stick to it, put in the work and avoid shortcuts, you’ll end up with the results you have always wanted.

Before getting into this, it’s safe to say that following a UX process will definitely work to your advantage. Still, as every product is different in its own way, understanding that a good design process adapts to certain product needs is vital, therefore the needs and goals should define the way of approach.

  • The core part of our approach here at RebelDot is going UX first and building products through an iterative user-centred design process. Through iterative loops, we design, build and validate ideas, flows, journeys, processes, and test disruptive ideas that might never see the light of day. However, none of this would be possible without prototyping.
 

The RebelDot UX process looks like this:

UX/UI Process

From the automotive industry to food, health and of course digital product development, prototyping serves as the keystone in releasing successful products. Simply put, think of prototyping as the most effective step to accomplishing and validating things with minimum effort.

The primary purpose of a prototype is to validate if a process or flow works and lives up to the requirements, hitting the target goals. Essentially, the sooner you realise you need to adjust, the better. Sure, if you want to take the alternative route, you’re welcome to go forward with getting engineers to develop your idea and after at least 50k spent in 6 months time realise you built a product that no one will use. Historically speaking, this is a moment when many companies reach out to UX designers to fix their product but unfortunately fixing it only means rebuilding everything.

The most important lesson you can learn when building a product is that you’re not building the product for yourself. The primary focus needs to be on your users, therefore you must address their needs, frustrations and objectives, enabling them to excel through the product and reach their goals.

The tools of the trade

There isn’t one do it all prototyping tool. The tool used should facilitate building a prototype to fit the desired scope in the fastest time. Overextending will result in delays in delivery and validation time, therefore the versatility of the tool should match the requirements, and keep the effort to the lowest. You can’t call it rapid prototyping if it takes an eternity.

Prototyping models 

Depending on the stage of the product, there are a few prototyping models we opt for to make sure the journey suites needs and hits the goals.

Best UX/UI team- RebelDot

01. Exploratory prototypes

We build exploratory prototypes when the product team, stakeholders or clients have an idea and want to visualise it in a real, tangible form. We start off the ideation process, reflect the objectives on our target user’s needs and define the goals and actions needed to get there. The idea can be a standalone idea, an extension of the current product which could become a candidate in the roadmap or a new way of approaching existing actions in the current system.

02. Validation prototypes

Validation prototypes are the result of thorough research, need mapping and are built based on the whole set of knowledge gathered throughout the research and iterative phase. The prototype is based on well-defined flows, user needs, goals and motivations and sets out to solve problems and reach key objectives. Its purpose is creating a realistic enough experience that can be put in front of users to be validated through user testing, so it can set the route for the next round of iteration.

03. Visionary prototypes

These are the coolest, most challenging, uber-cool prototypes that will, most likely, never see the light of day. The purpose of a visionary prototype is to test truly disruptive ideas that are so crazy they might never get built into an actual product. However, by forcing ourselves to think so far outside the box, we innovate and create solutions that may be applied further down the line. Think of F1 cars: — their purpose is to push the boundaries of motorsport through innovation, which will later become part of our future.

Conclusion

Designing a product without the prototyping phase is like wanting to build a car from scratch based only on your imagination. You will most likely end up missing the steering wheel. Start with listening to your users, launching assumptions and hypotheses. Reflect on needs and objectives, do the research and concentrate all these efforts in prototypes which can be validated with real people.
Prototype first, validate often and fail fast. Drive the product experience through your users to build and launch a product that delights.

🚀Did reading this really make you want to work with Tom? Reach out and let’s talk about building your awesome digital product. Make sure you getintouch@rebeldot.com, and we will get back to you in no time.

🤓Want to read more? Check out this article on How going UX first is a necessity for your digital product’s future.

🤔Reading this made you want to be part of the RebelDot team? We’ve got great news! We are in search of creative engineers that can help us ship digital products. Check our openings, here.

Blockchain

Challenges of adopting blockchain.

Blockchain is the new kid on the block (pun intended). There’s a lot of buzz around it, about how disruptive it is, that it will change a series of industries and will start a wave of innovation.  You might have considered using it in your next product or project, but not sure what your approach should be? Let’s see what you can expect down the road!

Disruption always comes at a price, because you are bringing something radically new to the table. Adopting something new takes time. It implies getting out of the comfort zone – for you, for your team, for your users, for the industry. Therefore, disruption can happen at a tipping point: when the need to innovate and the benefits of disruption will outweigh the inconveniences of the process. This is also how blockchain itself was born: to solve a problem.

So far so good. It sounds exciting. Except, it comes at a price. Blockchain solves a series of problems in an innovative way, thus using it implies a paradigm shift. This paradigm shift, although very promising, comes with its challenges. Some of these are not obvious from the start, because disruption questions the very same things that we’ve got accustomed to and take for granted. Let’s dive in!

You operate in a decentralized environment.

Blockchain is successful in delivering its promise to create trust in a trustless environment by making sure that no central party is controlling the information on the blockchain. Not even you! This transfer of control and ownership comes with a series of considerations:

  1. How do I achieve compliance with various regulations (e.g. GDPR)?
  2. What happens if I do an honest mistake when adding data to the blockchain?
  3. What if I have new requirements and I must adjust existing data?

Obviously, there are already a few techniques to cope with these challenges, just keep in mind that these usually imply a change in the way you do things as opposed to centralized systems.

Your users need to communicate with the blockchain.

In a purely decentralized environment, users should not need to communicate with any central authority, but with the blockchain itself. This is not a trivial task and currently needs quite some effort from your users’ part. To consume decentralized applications, you need specialized software. Your users need to be aware of that and they will need to go through a learning curve themselves.

On the other end of the spectrum, users are already accustomed to certain ways of interacting with software. Depending on your use-case, the real value that you can bring is finding a way to combine centralized technologies with blockchain in such a way that you can offer your users all the good stuff that they are accustomed to, while also leveraging the blockchain promise. And walking that fine line takes some fiddling with the technology

Developers need to adjust to the new paradigm too.

Because of the nature of the technology, developing blockchain applications resembles developing firmware: once you release it, it’s out there on thousands of devices. Devices over which you have very limited (if any) control. Thus, the price of updates is very high. As with firmware, get it right the first time, or you will pay the price later. This also implies that a series of best practices that developers are usually familiar with might not fit well: continuous integration, incremental builds, Agile itself. You’re more than welcome to use these internally, but your first release should be as complete and stable as possible.

Blockchain is immutable.

This also means that you need to deliver quality software from the start. And the implication is that you need to budget way more design and testing time than in centralized projects. They say that software testing cannot prove that a piece of code has no bugs, it can only prove that known bugs have been fixed. Thus, quality starts with software design. You should budget enough time to consider all the corner cases, limitations, long term consequences and security implications. You should have strong quality metrics.

Having a dedicated testing team is also important. Your developers will start with a great design and their code might be of excellent quality, yet bugs will slip through the process. This is because it is hard to accurately test your own code. People tend to build a mental model for solving a problem, and developers will use the same mental model for testing their code. In other words, they will look for bugs using the same mental model with which they’ve created them in the first place. This is human nature. A dedicated testing team can make sure that software is verified using a different mental model. Budgeting plenty of testing time is also important. The rule of thumb (that might shock you at first) is ‘5 to 10x’: for every week of development consider 5 to 10 weeks of testing. Software testing for blockchain is not just an aspect of quality assurance, but a way of risk mitigation.

Security is paramount.

Your code is accessible in some shape or form to everyone running a blockchain node (and in case of public blockchains to literally anyone). Thus, security plays a crucial role in your development lifecycle. Even more, once out there you cannot really modify it. If there is a security bug, bad actors can exploit it and there is not much you can do about it, since you cannot just patch your code, like you would in a centralized environment.

The technology and tool set are not yet mature.

The ecosystem is still in its early stages and while new implementations and tools appear quite frequently, these are not as stable as the offering on conventional technologies. Often, developers need to face the reality that something that is trivial to achieve using other technologies will turn out to be quite complex with blockchain.

Blockchain is not particularly fast.

The main characteristic of blockchain is immutability and security. By design, blockchain solutions will favor these over performances. Of course, the technology is rapidly evolving, and new solutions are proposed to boost blockchain performance, but today’s reality is that blockchain is not as performant as other centralized technologies.

 

At this point, you might incline towards giving up on blockchain, but the truth is that there are solutions and practices in place to help you deal with the challenges that you might face. The key takeaway is that blockchain not only disrupts the fields it is used in, but it has similar effects on the way you build your product as well.

So, is it worth it?

As with every technology, the answer is: it depends. Blockchain can indeed bring innovation to a whole series of industries and it has a lot of potential. In some cases, it really is unparalleled and offers advantages that simply cannot be matched by any other technology on the market. But we should use the right tool for the job. This technology is particularly good at making sure that information cannot be tampered with and there is a complete and immutable history of events, a permanent record of sorts. If that is something that you are after and you can build value on it then blockchain will prove to be a great fit for you.