I am a developer, I had been coding for last 6 years, building android apps and web apps. I had always faced problem with design thinking and did n...
For further actions, you may consider blocking this person and/or reporting abuse
I've got to disagree with one point here. Moreso than talk to your users, watch your users. We began doing UX testing sessions about a year ago, and the insight we've gained has been invaluable. That being said, what the users say while they're doing a UX session rarely correlates with what they do.
Watching users can be better than talking.
Is it practical? How do you do that and when?
Think about the most cases we need this at and for different stages of a project.
Nonetheless, the point was to involve users in the process to help you out make better decisions, whatever medium you choose to collect that info.
Disagree was a bit too strong of wording; rather, if you can watch your users, you should absolutely take the chance to because it's even better than talking to them.
We build enterprise software, so it's a easier for us to go about this.
When we first started doing UX sessions, we created a few scripts that go through basic functionality, but soon found those to be too far-reaching and time-consuming.
Now, whenever we are creating a new feature or testing a new layout, we invite several customers — particularly any who requested said feature or complained about the layout — to test drive it on an internal server, sometimes with a copy of their database if they have specific use-cases, during a screensharing session. Generally, we'll pick 3-5 customers, and do a 1 hour session each. Our development team as well as the sales team watch the sessions take notes, while our project manager guides the client through a script. We take all the feedback, triage it, implement any changes, and then invite them back to test drive again before rolling it out.
We're still learning ourselves, but found the advice in this blog to be really beneficial to the way we conduct our sessions.
Doing both is probably the best. You need to talk to user to know what user wants and what problem you’re solving. But to know how users use their computers and how do they manage problems you software is supposed to solve now, it is better to watch them. If you ask me how do I interact with my computer every day, I am not sure if I could describe good enough for it to be usable.
I remember good example of this. One of our opeartors was reporting problems with one of our kiosk apps. A lot of app crashes and corrupted local SQLite database files. It was obvious “something” is damaging files in fs. We dismissed usual suspects (virus, bad hdd...), but it didn’t help. We even rewrote how we handle corrupted db files - didn’t work. In the end tech guys went there, observed how local operator operates the machine. It wasn’t surprise when they reported operator was shutting down machine by unplugging power cable from the wall. Operators never mentioned that, because they took it for granted, and figured out it’s trivial and not important.
This is really great advice, and we could stand to take some of this advice to heart on dev.to. I also just went and bought Design of Everyday Things. I can't believe I haven't read that yet.
Some great advice here, i would also add that encouraging your users to become a part of your applications ecosystem is important too.
Feedback is important in a few ways some of which are mentioned here but most importantly knowing what your users want is critical to your projects life cycle.
I totally agree. I started frontend design with the mindset of a unix/linux shell user (report errors only), so I also ended my user requests with nothing when everything worked well. This lead to the following problems:
That was completely the wrong approach for designing web user interfaces. So here's my advice: ALWAYS give feedback from the server to the client. Make it rock stable! You can still decide to throw away an "OK" on the client side.
Another interesting concept that adds to the above discussion is Gestalt Design Principles. It describes things like The Principle of Proximity, continuity, similarity and more. Essentially, providing guidelines for designing a better UI.
Great advice Sathvik. Thanks for sharing. :)
Yes, Norman's book is worth reading. I wrote a review of the book a couple of years back: iedf.in/index.php/blog/item/the-de...
Hi Pradeep. What do you mean about Make at least 3 personas? Thanks
Have a clear picture of "who will be using this product". To have a clarity here, create persona of user(who are they, their habits, how technical these people are, what they like etc.). Basically something which you can visualize and connect instantly. This will help you make faster and better decisions while designing. Saying a user "age: 25-35" is not enough, it means you do not have any real user of the product. You need to research first, "who they are".
Generally the product I build, I'm one of the users, so first persona is of myself, other two are some friends of mine who are potential user of the product.
In case you want to read more: interaction-design.org/literature/...
Thank you so much this has been very helpful for me!
Design seems as difficult as development, even more so when you don't know how to make things look good just work good.
very well summarised