Posts Tagged ‘design’

The value of paper prototypes in software design

February 8, 2012  |  Process, UX  |  No Comments

Notebook

In the domain of user experience design there are many tools, processes and artefacts. Most would agree though that the best starting point is with a quick paper sketch.

What is a prototype?

A prototype is a preliminary model of something, from which other forms are developed or copied.

The purpose of a prototype is to communicate an idea for a software product, often to inform improvements in its design. The prototype is a reference point for dialogue, whether it is my internal reflection as a designer, a debate within the team or an evaluation by an end user. Through a process of iteration, we explore the design space so that the best decisions for implementation can be made.

Fidelity, in the context of software design, refers to how closely a prototype corresponds with the desired condition of the end system. A prototype that has “high fidelity” is accurate, or realistic in how close it is to the system it is modelling. An interface design sketched on a napkin would be considered a low fidelity prototype. Fidelity increases as you add detail to a sketch, add colour in Photoshop, add interactions on a screen and eventually create a partially working system.

High fidelity is generally a good thing, but it usually makes sense to start with a simple, low fidelity prototype such as a paper sketch.

Reduce time and Effort with a paper prototype

It is cheaper and quicker to produce a lower fidelity prototype. Making something look and interact more realistically generally takes more effort.

With software development, where we continually encounter new risks and opportunities in the design space, you want to learn as much as you can, as soon as you can and with the least amount of effort. If you sketch out some ideas for a new system and run them past a colleague, you have an opportunity to get feedback and improve on your design at a very early stage and with minimal effort.

Avoid tunnel vision – Explore alternatives

A prototype is a great way to externalise the ideas we have for a system so that they can be communicated. But often more importantly, the process of generating a prototype also leads to new ideas that branch off and evolve. Because higher fidelity prototypes require more effort to create and change, they can sometimes discourage innovation. Scrunching up a paper sketch and starting over with a fundamentally different design is not such a big deal.

Perhaps more important than wasted effort are the psychological factors involved. I have noticed that people become less likely to come up with design alternatives as they see a prototype become more and more realistic. It might be easy to think of minor improvements and new additions, but it is incredibly difficult to abandon the core decisions that the design was based on. Our brains seem to be programmed to move forward with evolution of an idea. It takes concerted effort to step backwards and explore requirements from a different angle.

I find it a lot easier to abandon an idea within a rough sketch than a Photoshop mock-up or an HTML prototype that I have refined over time.

Another way to encourage alternative design options is to get multiple designers to compose sketches in parallel for the same set of requirements. They should do this independently from each other, so that a more diverse set of designs can be generated. It is also helpful to stress that the purpose of the sketching process is to explore ideas to be catalysts for conversation – not to focus on a specific solution to the problem.

Focus on the big picture

Another reason to start simple is to avoid distraction. Introducing interactions, colour and detailed imagery while you are exploring high level design ideas can lead to stakeholders getting lost in the details.

My approach to prototyping

Personally, I really enjoy designing interfaces from scratch in Photoshop. From experience though, I have learned that exploring a diverse set of designs up-front will usually lead to a better result. Photoshop can be a bit tedious when you are trying to quickly put many ideas down. I start with some simple sketches to sort my own ideas out and then use Balsamiq to produce a set of digital sketches that are easier to communicate and collaborate on with other stakeholders.

Once the design space has been explored and the sketches start evolving in a distinct direction, higher fidelity prototypes can aid in generating richer feedback since they create an experience that is more realistic for users. The approach here depends very much on the project.

User Centric Design – Addressing negative influences

August 28, 2010  |  Process, UX, strategy  |  5 Comments

There is a tendency with most creative people I know to aspire for the approval of peers. This is natural, as we are all insecure and desire encouragement from people we respect. But it is possible, and often the case, that our peers have different values to our true audience. Chasing the approval of peers can compromise the success of a creative project.

Musicians playing to musicians

To help illustrate the point – this type of conflict is clear within localised communities of musicians. I used to occasionally watch bands play at venues in Durban and I would imagine that what I noticed occurs elsewhere. I would guess that almost half the people in the audience were musicians themselves – they came to support friends or check out the competition. This led to the bands writing and performing with the primary goal of impressing each other. Songs ended up being too complicated and progressive to be ‘radio friendly’. Needless to say, few bands broke out of the local scene.

Negative influences in software design

I design web and mobile software. I elicit requirements, sketch ideas, build prototypes and design interfaces. Throughout the process, there are points at which the user experience can be compromised because of the desire to impress stakeholders other than the users themselves. Much has been said about User Centric Design from a methodology perspective, but not from the psychological or emotional perspective of the designers themselves.

Say I have a fixed time box of 2 days in order to deliver a design for a new interface. My clear goal is to make sure that the limited time I have is spent on addressing the user’s needs through my design. The following examples illustrate how influences from peers and other stakeholders can conflict with this goal.

Designing for designers

As a designer, I often feel inspired to include novel aspects in my designs that I’d hope to see mentioned on blogs, Twitter or generally earn me kudos. I also feel obliged to keep graphics pixel perfect and mark-up spotless. Although valuable, this time could often be better spent elsewhere.

Insecurity

I frequently run designs by fellow team members for their input. Many developers love seeing their code ‘bling’ on the font-end, and will often suggest elements that I would deem low priority considering time constraints. It is often difficult to oppose these suggestions without seeming arrogant or defensive. This is an issue of insecurity and designers need to be bold about their convictions.

Unfounded client input

Clients are usually the least well educated when it comes to what is important in a design. We recently purchased a hilarious poster from The Oatmeal, titled “How a Web Design Goes Straight to Hell”. The comic does an excellent job of illustrating how input from a client can ruin a design. Standing up to inappropriate suggestions from clients can be very tricky. I try to make clients aware of these possible conflicts at the outset, clarifying that it is our job as designers to keep the users’ interests in mind.


Simply being conscious of these influences can help you to always keep the users’ goals in focus. Unfortunately though, certain personalities can make this very challenging.

Software development is human centric and heavily reliant on effective communication. I sometimes wonder if we shouldn’t have psychologists in our development teams.