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 these kind of technology based projects 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 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. 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 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 it’s 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, 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 to describe wire framing 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 from 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 basically free to use any UX solution that you will come across on the internet. So why reinventing the wheel? Why going 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 the question in 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 really detailed. Each time something small changes in the user interface you will have to do the change 40 times.  I personally 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 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 for 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 wire framing 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 a prototype? Can you skip wire framing all together 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 and you have a better look on 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.