On intelligent design: trying to be a more scientific designer
How to make better design decisions under tight deadlines, by using design research to show us 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, and I’m talking of 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.
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 wifeframing and then prototype
- Test the prototype with users
- See the family
- Gather more data
- Create a 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 you 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 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 a 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/post modernist 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 our make are creativity more sound. We don’t need to turn into 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 small practical example
Creating forms are the least sexy job a designer needs to do.
I have designed and sketched out more form layouts then I care 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 an 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’s 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’ in to 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 with some 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 though 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’. It is one of those things that niggles at me constantly.
There seems to be more debate over this issue then any other in form 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 was 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 everyday’s designers process. As Joe Leech, one of the most vocal proponents of a scientific approach to design says, “Data shows confidence in the design.”
Jessica Enders. The Definitive Guide to Form Label Positioning
Jessica Enders. Required versus optional fields – a new standard?
UX Central. Why Infield Top Aligned Form Labels are Quickest to Scan
Multi columns an readability
Jamie Appleseed. Form Field Usability: Avoid Multi-Column Layouts
Kathryn Summers. Designing Web‐based Forms for Users with Lower Literacy Skills
Luke Wroblewski. Marking Required vs. Optional form fields
Caroline Jarrett. The Question Protocol: How to Make Sure Every Form Field Is Necessary
Jared Spool. Avis Trying to Hard?
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
On assumptions in design