On intelligent design: becoming a more scientific designer
How to make better design decisions under tight deadlines, by using research to discover the best design patterns to use.
Wouldn’t it be wonderful to make perfectly informed choices when there are deadlines, lack of resources and extreme tiredness bearing down on you? We are talking about the design masses who need to ship very quickly, have no access to large design teams with a funding round to burn. Sometimes, it’s the important aspects of the design process, like research, which get overlooked.
We are not talking about user research at the very beginning of the design process. This is a given and should be conducted as well as possible. It is about using design and psychological theories that have been tested to underpin what we design. We can then build design patterns and artefacts with more confidence.
When it comes to developing a new product or feature, be it online or physical, the design process might go like this:
- Interview users about their needs
- Gather data
- Draw up the spec
- Start wireframing and then prototype
- Test the prototype with users
- Gather more data
- Create an MVP
- Test again
- Gather more data
The initial prototyping should be quick and dirty. After this, a higher fidelity version will begin and involve thinking about what design patterns are most appropriate – the finer details of user interaction.
Making these design decisions is normally arrived at by making assumptions, which are based on past use cases. That’s when a designer tends to pluck that tried and tested design pattern off the shelf.
From talking to fellow designers and developers, intuition, gut feeling and assumptions play a large part of what we do. Assumptions drive us on. It’s the starting point for logic. It creates our hypothesis, with which we can test these initial assumptions.
As David C Brown says, “it’s clear that assumptions must be included in Design Rationale, as explicit assumptions can be part of the reason for a design decision.”
As experienced designers, we know what design patterns to use, what works best, don’t we? We’ve been around long enough, read enough A List Apart articles to see how inputs should behave in online forms, where to place navigation, and how to create a hierarchy of information. Yet as users get more experienced, patterns get old, and it’s very easy to slip behind.
Too great a reliance on successful precedents can lead to failure. Success is not simply the absence of failure; it also masks potential modes of failure.
~ Henry Petroski
We have libraries, frameworks and style guides. But these can blind us somewhat to seeking out new ways of doing things.
Design research tells us what we should be doing, and is a source of ideas and inspiration.
Depending on what side of the modernist/postmodernist fence you sit on, product design is not self-expression. Personally, I leave that up to my graphic design work. This doesn’t mean that creativity is dead. We can all be creative in our solutions, we just need solid foundations to build upon. We don’t need to turn into the Niels Bohr of design. And this research is not exhaustive by any means. We’re just doing some due diligence. Being curious.
Research is what I’m doing when I don’t know what I’m doing.
~ Wernher von Braun
Form creation: a practical example
Creating forms are the least sexy job a designer needs to do.
I have designed and sketched out more form layouts than I care to remember. You would think I would have everything in a file, ready to pull at a moment’s notice. But with every project comes a different set of circumstances, context and questions. What’s the skill level of users interacting with this form? What content will be used? How does it fit in with the user flow?
On a recent redesign of an app, our team needed to create various form layouts. So I needed to tackle some issues that perennially haunt me.
What I’m talking about is not user or field research, (this is highly important and another matter), but the first small steps that we can all take at the start of a design sprint. It really comes down to reading the experts who have thought about design issues in depth.
Where does the label go?
Form label positioning is one of those areas that is easy to get mired in, and there is no end of good primers on it.
I wanted to introduce ‘top aligned Inline labels’ into various form types in the app. My reason for using inline labels was so that we could create more compact forms. This we hoped would speed up user input. I knew from past experience that inline labels can present recall problems if the form is too long and they disappear on focus. But were they ok to use on smaller forms?
I started searching online and came across hundreds of results on the subject. How rigorous many of these articles are is a matter of debate. To discover how reputable the source is, I usually trawl through comments, see the quality of commenter and see how many times an author has been cited.
An article on UX Central that seemed interesting. The comments were a real insight. I found opposing views from Jessica Enders of Formulate. I dug around the article and found out more sources, one which was Luke Wroblewski’s Web Form Design, a book I was familiar with. As Wroblewski says, “Top Aligned Forms tend to reduce form completion times”. Wroblewski has a wealth of sources for his findings. He also has concerns about inline labels, but this was published before the technique of top aligned inline labels was fully formed.
So armed with a sound basis to make a more informed decision, I decided to try top aligned labels inline in favour of traditional top aligned labels.
One column or two?
Since forms in the app might grow in length, I thought breaking the layout down into columns might be a solution. I dug around online. What I found was mostly conclusively against multi-columns and my instinct told me this could be the case. It was interesting nevertheless. Caroline Jarrett feels that two column forms are best avoided.
Through her post, I found a research paper by Kathryn Summers. It was a long read, but I got the essentials out of it. Summers recommends against multi-columns, as it slows down scanning and comprehension. After more trawling, I came across an article from Baymard Institute stating categorically to avoid multi-column layouts.
I couldn’t find any arguments for multi-columns, so I put that to bed.
To require or not to require?
What is the best way for labelling form fields ‘required’ are ‘optional’? There seems to be more debate over this issue than any other in design land.
On our forms, the majority of inputs need to be required. So the issue is, how do you signify it? Do you use the word ‘required’? If so, is there not a problem with repetitiveness and visual noise? I have used a variation of an asterisk or text to signify required fields, but I was never satisfied that it would aid the user efficiently. Of all the things that can scupper form completion, it’s not knowing why a form won’t send and then discovering that there is an error after minutes of frustration.
Jessica Enders has an interesting perspective on labelling: “To achieve optimal usability and accessibility across the broadest user base, we propose that every web form should mark only optional fields”.
There were many interesting comments from amongst other Jared Spool and Caroline Jarrett about the subject on this IXDA thread.
A UX Matter’s post decided matters. I went with placing the text ‘Optional’ beside each optional label and putting instructional text the top of the form stating, “All questions must be answered, unless marked (optional)”. Now the form looks clean, less cluttered and there is no heavy eye fixation after scanning past each label.
A little bit of design research should be a part of a designer’s process. As Joe Leech, one of the most vocal proponents of a scientific approach to design says, “Data shows confidence in the design.”
- Henry Petroski. Success through Failure
- David C Brown. Assumptions in design and in design rationale
- Joe Leech. Psychology for designers
- Luke Wroblewski. Web Form Design: Filling in the Blanks
- Brian Crescimanno. Sensible Forms: A Form Usability Checklist (Over 10 years old, but still relevant.)
- M.G.(Ron) Britton, P.Eng. Thoughts on Design . . . and assumptions