I suffered through a few seasons of having some UI designers who obsessed over doing the _whole process_ despite our target UI was for maybe 6 in-house users and was to expose the front-end on a work-in-progress system that changed heavily over time. I learned two main things from that experience (that likely doesn't apply when you have millions of users):
1. The "sketch" step yields about 80% of what you'll benefit from the whole process. If you can't do anything else, at least do that.
2. Very often, getting something, anything, built and working, and letting your users test and critique it will reveal far more than any amount of thoughtful design process will.
As both a long-time developer and, more recently, a UI designer, I'd assert that having a UI designer for a 6 person user-base doesn't really make sense, unless maybe it's 6 highly paid full-time users that are doing almost all of their work through it— in which case it would probably be critical.
In my 20 year tech career, I've seen far fewer cases of "why was the UI designer so involved, here" than cases of "Oh, the developers will know what makes sense to users, so we'll just have a designer come in at the end and make it look nice." The latter is a much bigger mistake than the former.
As someone who’s done UX for 20 years, I agree with you entirely. Some of the value of a UX process is that decisions are reversible. When you user test it can be difficult to integrate the results, especially if many things are wrong. With a thought-out design and a good paper trail of decisions, design decisions can be evaluated atomically and the team can react faster to user feedback.
Sadly, some of the value of a UX process is that many teams will not test with users at all. A process can give people a better shot at building something useful to begin with.
But your point stands well for most software: sketch something Good Enough, build it quickly, and get feedback.
In the 10+ years designing for mostly Software companies [1] (large and small) I found that the most important aspect of Interface design is the continuous cycle of eliminated things. Sketching and planning on paper is nice (and a must), but you are always wrong in the beginning. We usually only work with companies that have a working product, because we found that Interface Design is less critical in the early stages. A good UI can help you grow faster, but not necessarily achieve product market fit. In the beginning, UI isn’t all that important and you can go far with something decent. Once you have a working product and users, that’s when you can start the simplification process in order to pave the road for smoother growth. User Interface design can be summarised as: Eliminating obstacles from the user’s experience and remove as much friction as possible.
Maybe I’m just grumpy today, but this looks like poorly written marketing blog spam with zero useful advice. The product it’s promoting gives you very trite fake “briefs”, like this:
> I would like you to create an interface design of an on/off switch. Can you do that?
An approach that I was taught in an interaction design course (taken from SIGCHI research) that doesn't seem to be used much, is to have a sample of intended users design what they think they want (with simple approaches like pencil and paper, pasting UI widgets on paper, etc.), and then have the designer synthesize and refine those ideas into something more polished/concrete utilizing their own knowledge of the principles of the medium. This helps to more accurately reflect the mental models of users, and sometimes even helps elucidate functional requirements for the overall project that may not be readily apparent. This probably mostly works for internal/enterprise development where the overarching goal of the software being built is commonly understood by the user base, rather than a greenfield consumer facing product.
I have a hard time taking a supposedly user-focused design resource seriously when they set paragraph text in a bold sans serif font. Not reader-friendly. Anybody who's been to design school would learn not to do that in Type 1. It might be a valuable resource, but that's not the right way to get off on the right foot, especially with a design-savvy user-base.
It really is eye-wateringly bad. Open up the inspector in your browser and remove the reference to roboto for the paragraph text, and see how much more readable it is. The problem is they only import two Roboto fonts, one is a semi-bold and the other is a bold. Firstly, there's almost no situations where a semi-bold should be paired with a bold because there isn't enough contrast between them to show any meaningful difference in the content, but they still look different enough to kill any sense of harmony you might have by simply using a larger-point font. Secondly, paragraph text should only be set in regular/roman/book/normal/etc width. That width is "regular" for a reason— it's the most readable.
Articles like this one give content marketing a bad name. It’s disappointingly lacking in details. It’s main purpose is to sell a product, not to inform, and it shows. Let me give you a summary of 90% of its contents:
- Research who will use your product and how it will be used.
- Start with paper and pencil sketches. It’s faster than other methods.
- Turn those sketches into digital mockups. Fill in details.
- Have someone else look at your stuff.
The few other comments on this thread already provide more insight into the UI design process. I wish more content marketers spent more time on the content part.
13 comments
[ 3.6 ms ] story [ 36.4 ms ] thread1. The "sketch" step yields about 80% of what you'll benefit from the whole process. If you can't do anything else, at least do that.
2. Very often, getting something, anything, built and working, and letting your users test and critique it will reveal far more than any amount of thoughtful design process will.
In my 20 year tech career, I've seen far fewer cases of "why was the UI designer so involved, here" than cases of "Oh, the developers will know what makes sense to users, so we'll just have a designer come in at the end and make it look nice." The latter is a much bigger mistake than the former.
Sadly, some of the value of a UX process is that many teams will not test with users at all. A process can give people a better shot at building something useful to begin with.
But your point stands well for most software: sketch something Good Enough, build it quickly, and get feedback.
[1]https://fairpixels.pro
> I would like you to create an interface design of an on/off switch. Can you do that?
- Research who will use your product and how it will be used.
- Start with paper and pencil sketches. It’s faster than other methods.
- Turn those sketches into digital mockups. Fill in details.
- Have someone else look at your stuff.
The few other comments on this thread already provide more insight into the UI design process. I wish more content marketers spent more time on the content part.