Well I’ll be honest, while I had checked some of the colors for the design of this site for color contrast accessibility, I had not done it for everything. I also had not even done basic accessibility checks on the overall page templates. So I spent some time this weekend working on those things. I used the excellent webaim wave accessibility evaluation tool.
Things should be improved now. However, I know until I get an actual person with an accessibility limitation to provide accessibility feedback, that it is still probably far from pleasant to browse my site here. The automated site checking tools only tell you the most basic of issues and do not give a full assessment of the actual experience, particularly for people who may use a screen reader.
In my career I have often been involved in collecting and reporting on the usage of websites and applications through the data captured in logging / tracking systems. It can be fun to analyze and select data points and pull them into graphs and charts to be presented to leadership. However, there is a danger in relying only on quantitive data to make design decisions. People often view data collected from web/applications as definitive. It is after all a record of exactly what people clicked on and what pages / sections they visited, isn’t it? Unfortunately, this is an assumption and along with several other bad data manipulation practices you could be seeing problems where there are none.
Like many people, with the rise of Covid-19, I have been spending more time online. Particularly, places like Twitter, Hacker News and yes, Facebook. As anyone who has tried to have a discussion online knows, there are challenges and limitations to online communication. For all their shortcomings though I feel I have gained better understanding and even learned some things from some online discussions. However, one of the worst places to have a discussion online is twitter.
People new to UX often ask which tool should they use or which tool is the best for doing our work. The short and unhelpful answer to this is that there are many different tools each with their own strengths and weaknesses. A longer answer usually starts with… The current most popular tool is Sketch and to have the broadest appeal to employers you should learn this tool. While it is a great tool capable of doing both wireframes and high-fidelity designs it lacks certain capabilities that make it less than ideal.
There have been many articles written on whether designers should learn to code. I believe it to be part of the craft, and something that will help you be a better designer by knowing the medium in which your designs are built. However, I feel user research is one skill that is more helpful to master as a designer than coding.
It has been noted that people spend approximately 85% of their time in apps when using their mobile devices. Based on this there are a number of consultants who believe that if you want to capture the attention of people on mobile, you need an app. If you are a small or even medium sized business, I believe this is not a valid analysis or proper extrapolation of this data.
Don’t. Well if you have to there are a few things I have learned in using an Invision prototype with the Userzoom remote user research platform. One is that the custom loading page typically does not load in the Userzoom mobile app. So don’t waste time doing one of those. If you do make one, it should be as small and lightweight as possible. I tried making a nice gif animation and no matter how small I made it, it just did not load.
There continues to persist the perception that people who use mobile devices to connect to your website have different needs from when they connect to your website with a desktop/laptop (large screen). I often hear this suggested by mobile design “experts” and other UX professionals as well as by developers and product owners. It is based on the premise that since people are on the move when using their mobile devices that they are only in need of features and functionality that meet this “mobile” context. The inference is the mobile experience then needs to be different from your home/work needs from the same site. This is a wholly unsubstantiated and erroneous premise and one that designers should discard if they intend to create great mobile experiences.
For many design teams, customer support feedback, server logs, online surveys and possibly A/B testing are the only sources of user based data they may collect to guide their design efforts. It is great if a team is also conducting usability tests to improve their designs. Even if it is just before launch or to benchmark designs after launch, usability tests can be helpful to uncover problems with a design. Of course a more effective time to usability test is early in the design phase when the design can still be more easily changed. Despite a growing awareness and usage of usability testing, your team may still be in the dark about essential needs of the people for whom they are designing products or services. For those who want to have more success, there are several other research methods that can be conducted to help an organization learn what people need beyond what you already provide.
There have been a number of posts around the web about not using the term “user” any longer when talking about designing for experiences. Don Norman, one of the leading consultants and speaker on design thinking wrote a post and gave a talk back in 2008 at an adaptive path conference on not using the term user. More recently, almost a year ago Facebook’s director of product design, Margaret Gould Stewart shared in a conference how they have banished the term “user”. At first this seemed to me to be a bit pedantic. I am not sure how referring to people as “people” or “humans” can make a team more empathetic as those are also abstracts. However, I find myself now cutting out the term wherever I can as it seems to be taking further hold in the experience design community. Yet, this leads to challenges as I struggle how to efficiently communicate design concepts to other team members and in terms of job titles.
This site is not related in any way to FB or Meta. I created this site long before FB became Meta and the Metaverse. The idea for the name was that making things useful and usable requires continuous change.