Reinventing the wheel or pioneering new frontiers?

How to design wireframes that work

Recently we were asked by a client to design the front end of a booking website and app with a set of new features. When designing this kind of technology-based project you sometimes get stuck especially when you are asked to come up with a completely new and innovative approach. New findings or practices within UX design aren’t commonly shared or known yet and this might keep you from proceeding. A lot of design questions pop up from nowhere with only a small amount of answers. This would be the moment to research and to discover. Discovery is a crucial part of the design process, it’s that time we are truly learning and trying to make sense of the actual problems to overcome any obstacles. Unfortunately, the whole design process is covered in myths and half-truths that make a straight no-nonsense design approach difficult. At that specific moment, standing in front of all these questions, you can try three things: reinvent the wheel, pioneer unexplored new frontiers or just find something that already exists and copy it.

Discovery is a crucial part in the design process, it’s that time we are truly learning and try to make sense of the actual problems to overcome any obstacles.

One of the UX myths that go around is that all your design has to be 100% original. Although authentic design and originality are very, very important when it comes to experiencing creative work in general, simply because they have to evoke a certain emotion in the hearts of the spectator, in the case of user experience design this might not be completely true. Of course, we want the design of the user interface to look cool and oomph-inducing, but UX is mainly a matter of practicality and usability. Websites or apps are self-service products. This means that usually there are no manuals, training, or customer service people available to help or guide the user through the journey. Users have to use their own wits to find their way around.

Understanding the underlying problems before attempting to solve them

Designers are problem solvers. UX design is finding solutions to very specific design problems. Experimentation without usability testing is like preparing a meal for your in-laws and not using a recipe or something that you have ever tried before. Unless you are Jamie Oliver, using your intuition could end you up with barely touched food, apologetic frowning from all participants, and mainly just general disappointment. Improvisation and UX don’t go well together. Technology that doesn’t work enrages people beyond compare because it makes them feel stupid and powerless.

Each project has of course its own specific design problems that need to be researched and defined first. Without knowing what the actual requirements and obstacles are, you won’t be able to come to a good solution. From ‘The Elements of User Experience’, a book by Jesse James Garret also commonly referred to as the UX bible, we can learn that there are five main steps and elements (he refers to it as sort of overlaying planes) within the creation of any user experience. Although every project is unique and differs in size and complexity you will always have these 5 elements: strategy, scope, structure, skeleton, and surface. Designers usually only think about the latter two (or at least the last one): the skeleton and the surface. Two terms Garret uses these to describe wireframing and user interface design. In other words the outside look and feel. The front end. He also says we have to start working from bottom to top. So we start with defining the design problems of a project. This usually consists of understanding the brief, the strategy or vision, the objectives, the market, and the user or all the user groups involved. We start with more abstract concepts, ideas, and research insights and then go to content, structure, and design. Once we have successfully mapped down the issues and tasks we can start finding the solutions. Plotting down user journeys in the form of a user-flow diagram and designing a set of detailed wireframes are two important steps in what you could call the design phase, the phase usually worked on by designers. These two steps harbor questions such as ‘What is the right structure’ and ‘How do we establish the underlying foundations for the composition of the user interface elements’.

A lot of answers and solutions are already available in the form of precedent projects and other applications that have already been proven to work. Unless the UI/UX has been patented (enter a grey world of patenting software and intangible things like UX) you are free to use any UX solution that you will come across on the internet. So why reinvent the wheel? Why go through the lengthy process of finding the right design solution, if the solution can be found right in front of you and you don’t even have to do usability testing either? But as said before every project is unique and has its own challenges. The size of the project, the time, and the budget allocated alone call for different measures. There are as many UX solutions as there are users or user behaviors. What to do if you are facing new or difficult-to-specify features because there are no precedents to be found? What if the user journeys are really complicated? What if you are threading unexplored territory? If time and budget are limited, so is the feasibility of the project.

Tackling the challenging parts first might keep your project flow going. Honesty and flexibility towards your client and your team are also important because in any project, due to uncertainties, new tasks may arise at any time. Speeding up the process by jumping over or forgetting important steps can be fatal for the end result of the project. Design goes hand in hand with technology and designers bring their unifying vision to keep consistency in the UI. Their input is what you could call the creative glue.

There are as many UX solutions as there are users or user behaviors. What to do if you are facing new or difficult to specify features because there are no precedents to be found?

How to present a user journey?

Earlier I got a question from our team: do we show the wireframes in the presentation or just the design mockups? Where do we use annotations?

How do you best present a dynamic user flow in a static format like a PowerPoint presentation? Which steps do you emphasize and which do you hide? How do you present an incomplete journey? Do you hide the gaps in your journey? How detailed should the wire framing be and how many states do you show? Imagine a project with 40 wireframes that are all detailed. Each time something small changes in the user interface you will have to do the change 40 times.  I would suggest drawing wireframes that are not too detailed. Important is that you can present the general flow, rather than a detailed one and you can focus on those unusual or more specific parts of the flow that are unique for that particular project. Of course, the difficulty here is to find that median, that level in detail when enough is good enough. Enough to show the strength of the idea without revealing too much of what is missing.

This brings us to the part where we have to decide if we will use interactive or static wireframes. If you chose static, adding explanatory annotation can help. The same counts for a style and behavior guide that shows all the transitions and explains the behavior of the interface. There are a lot of interactive online UI/UX design solutions that are cheap and easy to use. They can be great if you collaborate online or you want your client to be able to test a working prototype. This type of wireframing is gaining a lot in popularity as ‘rapid prototyping’. It is a much more interactive and user-friendly solution to show the user interface components and their associated behaviors and it requires much less documentation (a killer for designers). It is also a good tool to test usability without having to wait for a demo or beta version from the developers.

So when do you choose a wireframe and when is a prototype? Can you skip wireframing altogether and jump straight to the latter? As usual time and budget are significant factors here as prototyping takes much more time. If you are for example doing a proposal or pitch, wireframes are a good choice to mockup an idea. On the other hand, if your project is more developed you have a better look at the scope and the budget, and you want a higher fidelity interaction from the audience involved, rapid prototyping might be definitely the way to go.