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.
Many enterprise organizations are in the process of adopting or are already practicing some form of Agile development. Digital experience architecture and design professionals need to adopt Agile approaches when working with Agile development teams. While it has been the method of choice for start-ups for many years, most enterprise organizations have struggled to go fully or even partially Agile. Some of this has to do with the large number of stakeholders and teams involved in enterprise development. Where I work currently has been trying to go Agile for several years now and I have talked with a few colleagues where they have had more success. The following are some common issues I’ve faced or heard about from UX teams in enterprise organizations trying to adopt Agile methods and some suggestions on how to overcome them.
Web & Mobile sites are not desktop software
There are a number of interface guidelines and heuristics to help evaluate user interfaces. One of the most well known are Jakob Nielsen’s 10 Heuristics for User Interface Design. These were developed by Nielsen in the mid 90’s and were intended for the evaluation of user interfaces for computer software applications in general. He has since then revised them several times, but they remain rooted in the desktop in my view.
In designing and building websites it seemed to me that some of these heuristics did not translate well to the web and even more so now for mobile. While some rules could be rephrased to be more applicable to web sites, others when it comes down to it, really do not apply to the web. I also felt that several items were too closely related to each other and could be better understood as a single point.
When I first designed this site, responsive design was not as big as it is now. My main focus was getting a site dedicated to my interests in UX issues up and running as quickly as possible. After the big push to get it launched, I settled into the satisfaction of indifference that follows such endeavors. I knew that responsive design was the wave of the future, but it was not now for me at least. However, it was not long before the responsive design clarion bells of Luke Wroblewski and others clanged in my subconscious as I read various articles on the surge in mobile usage.
So I got a new Macbook pro with retina display and along with the upgrade to Mountain Lion (I’ll write another article on that experience later), I also upgraded my Parallels virtual machine and Windows system as well. For my current work environment, I was still using Windows XP for the most part and at home I had a Windows Vista system that I really used only to test things in IE 9. I had seen several folks with Windows 7 and it seemed that Microsoft had worked out most of the problems with Vista with that version. Although I never really had many problems with Vista as I did not have any peripherals I needed to connect.
I think it is obvious that with this new version of Windows, Microsoft is looking to not just gain ground on Apple and Google, they are looking to bypass them. Unlike the muddled failure that Vista was, where most problems were hardware compatibility and a few usability issues, this time around the problems are hardware utility and perhaps some major usability issues.