After 11 weeks of being in CSC318, I have much to think about and reflect upon. What have I learned? What has changed? What do I know now that I didn't before? The truth is, these questions are quite abstract. I could certainly list everything I have learned, but I don't believe any reader of my blog would benefit from such an act. Instead, I believe it is more important for me to explain how my mindset has changed. Before, I wasn't very creative or artistic. I would see people create beautiful works of art, and I would wonder, how did they create such a thing?
However, this class made me realize something important. Art isn't just the technical ability to create visual works - it is any expression of human creativity. You can be completely ignorant about the first detail of visual art or graphic design, yet in terms of mindset you can still be extremely artistic and creative. If you can imagine beautiful, innovative and unique creations that build upon your life's experiences while still being different from everything you have already seen, then for all intents and purposes, you are an artist. There are many products I have used and many gadgets that I have seen which I believe I could improve given my experience with this class, because I can now utilize my artistic abilities to rigorously evaluate products.
However, I believe there is one skill that I am still sorely lacking. How do I create art? This is a massive topic that people get degrees on. So it may be unreasonable for me to believe that it can be incorporated into a 12 week class that has so many topics to cover. However, I believe it is important to remember that this is 2017. There are many design tools out there that are geared to provide the best user experience. Anyone with the desire to learn and the right information and teachers can learn quite a few things in a few short hours. I believe it would have been better if at least 1 or 2 lectures was actually dedicated towards rapidly prototyping beautiful, artistic designs. I will probably learn this stuff myself on my own time because I want to learn. But I have many friends in this class who I believe aren't particularly enthusiastic about doing any extra-curricular activities. These people also mostly focused on doing the writing parts of the group project rather than the artistic part. I believe they would have benefited if the class actually had some specific lectures about visual design, such as how to use Photoshop or Illustrator.
Bibliography
www.adobe.com/Photoshop
www.adobe.com/Illustrator
Friday 24 March 2017
Monday 20 March 2017
Combining Agile Software Development with User Centred Design
I found myself in an interesting situation this semester - two of my classes involved team-based development and collaboration. I took CSC301 which is a software engineering class as well as this class. What's more notable, however, is that in both classes, I was developing products that were aimed at a specific user-base and required very systematic approaches in order to create products that were compelling and useful to the target group.
In this class, my group and I are working to build interactive technologies for the homeless. In CSC301, my group and I are building HCI tools for people who don't have hands and arms. Dealing with marginalized groups in both classes meant that I was in a unique position to take my understanding of each class and apply it to the other class.
After 10 weeks of CSC318, I have found some of my opinions to have changed. Before, I was fairly confident that I knew a lot of things. I knew what users wanted. I knew how to make good apps. I knew good design from bad design. But after doing this class, I have found my own knowledge and opinions challenged many times. I thought I knew what was best for users, but that isn't true. There have been multiple occasions where user research, usability evaluation and literature review revealed the flaws in my own understanding.
So, I wanted to take the tools I acquired from CSC318 and use them in CSC301. If I am making interactive technologies for a select group of people, it would make sense to believe that user centered design is an ideal approach to the development process.
There is one problem, however: in the fast paced world of agile development (or to be more specific, scrum development which is what is practiced in CSC301), how can we take the time to formally conduct user centered design? I thought about this for a long time, but I came to a simple answer: you don't. It is important to realize that in the real world, it is very difficult to do things in a way that is 100% consistent with the theory. The theory very specifically states how user centered design is conducted across the development lifecycle, but the reality is that few teams will have the resources and time to follow this approach so perfectly.
Therefore, I realized that it may be more useful for me to take the most important things I learned from UCD and then somehow incorporate them into the agile process. Here is what I did:
- during the design stage (please see the diagram of agile development above to see which stage this is), instead of solely focusing on software specifications, UML, technological constraints and other things like that, also incorporate usability research and user research. Allocate some resources to find out what your users need and what the problem is. What are they lacking currently? It is very important to know before you spend resources on development whether your product is actually useful and whether people actually want it.
- during the build and configure stage, always keep your user research in mind. This may sound simple, but what I mean is that, very often, when software teams start development, they will become highly preoccupied with technical issues, technical research and all the other intricacies of developing highly complex software systems in the 21st century. It is easy to forget what your research showed you in the beginning. I believe it is very important to consistently keep the research in mind, because the final product must be a reflection of what your users actually want, not what you were realistically able to build after constantly changing the target product because of technical difficulties.
- during the testing stage, bring in actual usability testers instead of just unit testers or code readers. This is EXTREMELY important. If the people who are testing the code are people who have been involved in the software development process, chances are, they know too much about the code to judge the product in an impartial way. It is very, very important that the product is tested upon actual users before release so that your team does not end up releasing a product which the actual users do not like.
These are some of the observations I have made over the past couple of weeks as I have been involved in both HCI design and Software design. I hope you, the reader, learned a thing or two from reading this.
Pic sources:
https://image.slidesharecdn.com/edsusergrouppresentation-160206105225/95/user-centred-design-and-students-library-search-behaviours-3-638.jpg?cb=1455237084
https://lh6.googleusercontent.com/o_QZmtpH3XrDabJmS6CUQfOySx7dMGlWT0hKH-HL3OfMWazMHDyMffRRR1GZd2aPMpXqjnwmrto1eCQQ_BSbRui11820xRA0qeu2YZ9CqNUeWHqdwToSk5fdRVQT4vXy9A
In this class, my group and I are working to build interactive technologies for the homeless. In CSC301, my group and I are building HCI tools for people who don't have hands and arms. Dealing with marginalized groups in both classes meant that I was in a unique position to take my understanding of each class and apply it to the other class.
After 10 weeks of CSC318, I have found some of my opinions to have changed. Before, I was fairly confident that I knew a lot of things. I knew what users wanted. I knew how to make good apps. I knew good design from bad design. But after doing this class, I have found my own knowledge and opinions challenged many times. I thought I knew what was best for users, but that isn't true. There have been multiple occasions where user research, usability evaluation and literature review revealed the flaws in my own understanding.
So, I wanted to take the tools I acquired from CSC318 and use them in CSC301. If I am making interactive technologies for a select group of people, it would make sense to believe that user centered design is an ideal approach to the development process.
There is one problem, however: in the fast paced world of agile development (or to be more specific, scrum development which is what is practiced in CSC301), how can we take the time to formally conduct user centered design? I thought about this for a long time, but I came to a simple answer: you don't. It is important to realize that in the real world, it is very difficult to do things in a way that is 100% consistent with the theory. The theory very specifically states how user centered design is conducted across the development lifecycle, but the reality is that few teams will have the resources and time to follow this approach so perfectly.
Therefore, I realized that it may be more useful for me to take the most important things I learned from UCD and then somehow incorporate them into the agile process. Here is what I did:
- during the design stage (please see the diagram of agile development above to see which stage this is), instead of solely focusing on software specifications, UML, technological constraints and other things like that, also incorporate usability research and user research. Allocate some resources to find out what your users need and what the problem is. What are they lacking currently? It is very important to know before you spend resources on development whether your product is actually useful and whether people actually want it.
- during the build and configure stage, always keep your user research in mind. This may sound simple, but what I mean is that, very often, when software teams start development, they will become highly preoccupied with technical issues, technical research and all the other intricacies of developing highly complex software systems in the 21st century. It is easy to forget what your research showed you in the beginning. I believe it is very important to consistently keep the research in mind, because the final product must be a reflection of what your users actually want, not what you were realistically able to build after constantly changing the target product because of technical difficulties.
- during the testing stage, bring in actual usability testers instead of just unit testers or code readers. This is EXTREMELY important. If the people who are testing the code are people who have been involved in the software development process, chances are, they know too much about the code to judge the product in an impartial way. It is very, very important that the product is tested upon actual users before release so that your team does not end up releasing a product which the actual users do not like.
These are some of the observations I have made over the past couple of weeks as I have been involved in both HCI design and Software design. I hope you, the reader, learned a thing or two from reading this.
Pic sources:
https://image.slidesharecdn.com/edsusergrouppresentation-160206105225/95/user-centred-design-and-students-library-search-behaviours-3-638.jpg?cb=1455237084
https://lh6.googleusercontent.com/o_QZmtpH3XrDabJmS6CUQfOySx7dMGlWT0hKH-HL3OfMWazMHDyMffRRR1GZd2aPMpXqjnwmrto1eCQQ_BSbRui11820xRA0qeu2YZ9CqNUeWHqdwToSk5fdRVQT4vXy9A
Sunday 5 March 2017
Evaluating the Nintendo Switch UI as a UX Designer
The Nintendo switch console was released a couple of days ago. This class provides a good opportunity to evaluate the UI of a modern, interesting device from the perspective of a UX Designer. We won't focus on functionality and instead dedicate our efforts on the use experience.
When we start up the console, this is one of the first screens we are met with - this is a screenshot of the menu screen:
From the start, it is apparent that the UI makes good use of minimalism and Fitt's law - the user is not presented with a huge amount of information or a lot of buttons and everything is large and visually appealing and sufficiently separated to prevent any wrong presses. Everything is quite natural- things react how you would intuitively expect them to and there is very little waiting - the UI is fast and responsive and doesn't test the users' patience.
The UI also makes good use of color and graphic design - colors are complimentary and everything seems consistent - the buttons have a cartoonish feel that makes sense for the target user-base and the whole UI has a 'flat' design, somewhat like current generation iOS iterations, which is a trendy type of UI that is seen a lot in 2017. The color scheme uses similar colors within the same feature (for example within one button) or contrasting colors between different features (such as between different buttons).
However, there are some shortcomings. For one, the keyboard isn't consistent with present day designs of touchscreen keyboards - the predictive touch isn't very accurate and the spellchecker is also quite unsophisticated compared to present day offerings. Also, some things aren't obvious. For example, given the above menu, how do you start the browser? One of the trade-offs to having a minimalist UI is that sometimes, obvious actions are no longer obvious.
All things considered, I am quite pleased with the UI. As someone who has used previous Nintendo consoles and was extremely frustrated at certain things, such as the lag, the inconsistency, the blocky text etc, I am glad that Nintendo focused on user-centred design and addressed many of the issues that people might have had with previous consoles.
When we start up the console, this is one of the first screens we are met with - this is a screenshot of the menu screen:
From the start, it is apparent that the UI makes good use of minimalism and Fitt's law - the user is not presented with a huge amount of information or a lot of buttons and everything is large and visually appealing and sufficiently separated to prevent any wrong presses. Everything is quite natural- things react how you would intuitively expect them to and there is very little waiting - the UI is fast and responsive and doesn't test the users' patience.
The UI also makes good use of color and graphic design - colors are complimentary and everything seems consistent - the buttons have a cartoonish feel that makes sense for the target user-base and the whole UI has a 'flat' design, somewhat like current generation iOS iterations, which is a trendy type of UI that is seen a lot in 2017. The color scheme uses similar colors within the same feature (for example within one button) or contrasting colors between different features (such as between different buttons).
However, there are some shortcomings. For one, the keyboard isn't consistent with present day designs of touchscreen keyboards - the predictive touch isn't very accurate and the spellchecker is also quite unsophisticated compared to present day offerings. Also, some things aren't obvious. For example, given the above menu, how do you start the browser? One of the trade-offs to having a minimalist UI is that sometimes, obvious actions are no longer obvious.
All things considered, I am quite pleased with the UI. As someone who has used previous Nintendo consoles and was extremely frustrated at certain things, such as the lag, the inconsistency, the blocky text etc, I am glad that Nintendo focused on user-centred design and addressed many of the issues that people might have had with previous consoles.
Subscribe to:
Posts (Atom)