Even for us IT industry insiders, the concept of what UX is and what it is used for is often unclear.
It’s a relatively new discipline and, even though the definitions and standardised methods have been around for decades, everyone tends to interpret it their own way. Some have dedicated UX people and some have entire teams working on it. Others use UX and UI interchangeably to refer to “everything on the user side”. This is why it’s always a good idea to clarify what exactly you get during a UX engagement, and based on that, decide whether you need it or not.
Here, at reinteractive I am the Lead UX specialist and work with our customers directly to work out their app’s requirements. My role, in a nutshell, is reconciling business needs and user needs in a way that is technically feasible within the time and budget. I don’t do it alone, of course, I have a cross-disciplinary team of designers and developers in my corner.
When starting an engagement, I always conduct stakeholder interviews during which I aim to find out as much as possible about the app. This includes finding out what we know about the existing user base or prospective users (if the app is new), and defining overall what we are trying to achieve with the app.
This step is essential, no matter how good the written brief is. I am interested in the more subtle aspects, and I like to have a semi-guided conversation about what constitutes a success in each stakeholder’s mind. If I can get access to users or prospective users, then they are the next on my list to talk to. Talking directly to the end user allows me to understand what problems they are facing now that the app can help with and how this new app will be able to make their life better.
The next step is coming up with the information architecture. This is defining what navigation item goes where and how the screens will end up working together.
Following this, I create an interactive, clickable prototype of the app through an iterative process. This is a really important step as it takes those written ideas and puts it into the real world. You have something that can then be tested with actual users. Seeing users interact with the clickable prototype enables us to make adjustments well before any money is invested in developing the app. It de-risks software projects and increases confidence that the development will result in an app that delivers a needed product to its end users.
Because the prototype is only “medium fidelity”, it doesn’t contain final visuals, colours, fonts, etc. We like to ensure that the core functionality and interaction is established before tackling the visuals. This process is described in more detail on our UX service presentation page - check that out in more detail.
What I’d like to highlight is that this prototype - the main deliverable of the UX process - becomes a very important piece of information going forward. It will serve as a blueprint for the whole team. It ensures that everyone is looking at the same interpretation of the brief and the additional information uncovered during this UX process. As the app gets developed, the whole team can refer back to the prototype to ensure that what is being built still aligns with the original goal.
Top 5 Reasons for Creating a Rapid Prototype
So, to summarise, here are the top 5 reasons to spend some time creating a Rapid Prototype before jumping into development:
- UX Design helps uncover business needs and user needs that might not be obvious to begin with.
- It allows quick iteration - we use UX design software so no time is spent writing code. Changes are quick, and multiple options can be explored.
- It turns the brief into a tangible, clickable prototype that people can interact with. Show instead of tell.
- UX Design allows for testing with actual users who can navigate and use the app. This is impossible to do with just a brief.
- The whole team is looking at the same thing, experiencing the product from the same angle and as such, working towards the same goal for the application.
I’m not in sales but I believe my colleagues when they tell me that, in all our years developing software at reinteractive, the projects that start with a clickable prototype go on to save a considerable amount of time and money during development, which more than pays for the cost of the UX Design service itself.
