I’ve really enjoyed all the buzz in the news between the Comcast Time Warner Cable acquisition and HBO/Cable versus Netflix debate. I just wanted to jot down my thoughts:
A great info graphic referenced some data:
- 40% of TV’s are connected to the internet, either through the TV itself or another device.
- 70% of broadband users under the age of 35 get at least some of their TV from online sources
- 119M US TV’s will be connected to the internet by 2015, up 51% from 2013.
I want talk about one example from the other side of the world. Singapore, is a place where Temasek Holding , a government company, has monopolized the television industry. Private ownership of satellite dishes is banned and there are only two local pay TV operators. Obviously, the media and telecommunication industry is much different than ours in the United States. I think this is important because they’ve had to design a process that will work within their constraints. As our competitive landscape in the United States changes, it’s important to consider a new way to provide service. In Singapore, channels can be purchased a la carte. Imagine being able to do that in the United States? As companies like Netflix and Hulu produce their own “television” shows, we start to see a way to break outside of the mold.
As fas as experiences are concerned, I have a list of TV shows that I really enjoy. I’ve selected them through recommendations from articles and the newspaper, and found a way to preview the series. I’ll list a couple of them:
- Mad Men
- House of Cards
- The Walking Dead
- The Bachelor (secret addiction)
Let me discuss how I receive this service:
- ROKU (Television) or IPad Xfinity App
- ROKU (Television)
- ROKU (Television) or IPad Xfinity App
- Apple TV (Television) / IPad App
- Apple TV (Television) / IPad App
- Xfinity App
- Apple TV (Television) / IPad App
- The Bachelor (secret addiction):
- Antenna Basic Cable
As you can see, there isn’t a consistent platform for delivery. I don’t want to preach, but let’s please find a way to unite these experiences through 1 platform. I have a feeling I’m not the only one with this problem. I think it’s fun when the industry is shaking at the knees, because it provides an opportunity for something new.
So its 2013, and over the past 5 years my opinion, informed by articles, research and first hand experience, is a majority acceptance of the user experience design practice.
Yes, every once in awhile you’ll hear the occasional
“my company doesn’t understand why we need to defend the user..”
But as a whole, most industries see the benefit of user experience design. If they don’t, they probably invest in it anyway because their competitor has a solid practice.
What is going on?
If we win the argument, then we get to practice our craft? Yes. However, there was something appealing about convincing the business and technology. I believe many of us, as user experience designers, fell into the role out of pure stubbornness and hot headedness. We like the convincing, and evangelical side of the job. In some ways, that quality is what sets us apart from others on our development teams. So what do we do now? If our field becomes fully accepted, what type of UX designers will be bred? Will we continue to be a bunch of innovative, quick witted, assholes? Personally, that’s who I want to continue to work with everyday. At ThoughtWorks we’ve started to reinvent the craft a bit.
Instead of fighting the business and technology to defend the user, we’ve begun to help the business and technology asses the right problem.
Sometimes when we are asked to implement usability fixes, we realize the reason the system is not-usable, is because of a different constraint. This constraint, in fact it has nothing to do with the design and once realized, we are able to surface this knowledge and address it appropriately. This concept magnified times 10, to the business, is the a problem we are solving at ThoughtWorks. That is to say, when a business identifies an issue and has not yet figured out how to address it, we help the business learn about this problem and identify the solution, together.
Where does UX tie into this?
Almost always, a business’ problem has to do with users. Example: I was working with a client earlier this year that build really cool hardware. They employed us to help solve a problem, but as they began they realized they didn’t have much information on their users. They fully embraced user experience design, but only at the development level, so the UX techniques were not applied to the business. As a result, their solution was not tailored to their users. This caused all sorts of problems from a HUGE backlog of stories to confusion around prioritization. Together we partnered to approach the business solution from a user centered perspective. I was suddenly working with the CMO and the CTO directly to create a common ground for which our problem would be solved. It was THRILLING! Honestly, it was like “convincing the business that UX design matters.” However in this case it was sharing my knowledge about users, how to learn about them and the way that they must be integrated into the business solution.
So what is next for UX?
I see much more of this happening in our future. Moving closer to the business while maintaining a relationship with technology, will be a new skill that we must acquire. In addition, we will need to know how the business works. Budgets are crucial and stakeholders are even more important. In this approach we still get to work on a cutting edge problem with cool controversial projects, while maintaining our love for the user. I believe it’s a great transformation for “our kind,” and it still allows us to be informed assholes that respect our users.
I really love being here for work.
At this point, this is something I am working on. The open questions:
1. Should a site’s IA mimic the service of it’s business?
2. If not, how does it differ? i.e. environment, device.. etc?
I traveled to Madison, WI this weekend to attend and speak at UXMad http://uxmad.com/
1. This conference is jam packed with fantastic people
2. It’s a GREAT mix of disciplines
3. It was held on a great busy beautiful weekend in Mad town.
4. Attend next year!
User Experience + Quality Assurance = Usability
By Riley Graham
Published: July 8, 2013
- See more at: http://uxmatters.com/mt/archives/2013/07/user-experience-quality-assurance-usability.php#sthash.EGK2GR5G.dpuf
Relax. Engage. Refresh.
UXMad is a one-track conference where agile design meets elegant function. With two full days featuring speakers from near and far, the conference will showcase the assets of the passionate local UX community and allow Madison visitors a chance to experience one of the best, brainiest and least-expensive places in the United States to live and work. Come for UX inspiration. Stay for the cheese.
(Will be published in the next UX Matters issue)
Jacob Nielson put it perfectly, ‘Quality assurance impacts the user experience: when things don’t work, users question their understanding and develop superstitions and inefficient workarounds.’
User experience and quality assurance have one key factor uniting the disciplines at the core: usability. According to Wikepedia, ‘Usability is defined as the ease of use and learnability of a human-made object .’ This principle encompasses everything from physical items like hammers to all types of software applications. Often, technology seems to transcend the physical world and as a result, the usability of software is pivotal to its value. In agile software development the usability of a product is a shared concern across the entire team. However, I’d like to focus on the way QA and UX address usability during 4 broad phases of agile development; research, development, testing and release.
This phase of agile development is traditional dominated by business analysts and designers. However, this phase is also crucial for quality assurance. At ThoughtWorks, we’ve used this phase do specification by example, typically led by QA this process commonly occurs through example-driven development, executable requirements, acceptance test-driven development and/or agile acceptance testing. The basic idea of spec by example is the creation of 1 source of truth about requirements from all perspectives. Members on the project collaboratively create and maintain these requirements allowing them to run all tests and documentation synchronously. In doing so, the team avoids miscommunication and confusion about requirements and design. When changes are made, the team can apply the specification and create a refined set of examples to derive a test for acceptance. This process happens continuously to support the end user by creating ‘living documentation’ that ebbs and flows much like the products users.’
When it comes to process, development is a phase composed of a variety of activities. However, the process of designing the user interface is something of grave importance for both UX and QA. During this period, UX should be building and refining a style guide that lists information about standards for the application. These may range from colors to patterns. This is an opportune time for UX and QA to work together to develop a shared understanding of how the app will work and look. As stories are being continuously developed and tested, there will be certain aspects of the user interface that will not change- as defined by UX and the business. The sooner QA is aware of these areas, the sooner they can build regression tests and make notes of standard that they should see repeat during every test.
During this phase of the agile cycle QA’s maybe conducting unit tests, regression tests, smoke tests, exploratory tests etc. The rest of the team is focused on their work by phase. Therefore, if UX researches and designs piece A of the application then development picks it up, develops it and QA runs it through a series of tests. While QA is testing, development is working on developing piece B because UX should have completed researching and designing B, and moved onto researching and designing piece C. This is the typical process that the team follows. So, when QA is busy testing piece A and UX is researching and designing piece C there is a high chance that those pieces of the application are related. This opens up a world of opportunities for the disciplines to work together.
About a year ago I was working for a client and took advantage of the opportunity to work with my teams’ QA. I was about to begin my weekly usability testing on a portion of the application that focused on the users ability to step through a series of progressive steps to completion, and realized that the QA I was working with might be able to help me. I was testing on paper, and the latest build included the steps without a progress bar indicator. Prior testing indicated that users needed to be aware of their progress, so my test included our latest progress bar designs. Meanwhile, QA was busy doing exploratory testing on the series of steps developed since the last check-in. At this point, I noticed that their exploratory testing was occurring on paths that our users could travel down, during usability testing. As a result, I asked for their input on my scripts and found that they had already discovered a series of bugs that could potentially affect that week’s build and usability testing. In addition they suggested a variety of ways to test the ‘unhappy’ path in order to account for a variety of users. Over time our paired relationship turned into diagramming sessions where we would outline all the users and potential scenarios. We quickly displayed this map for the team and although it provided visibility for everyone, it was most effective for the product owner. When he spent most of his day thinking 3 months ahead of the current build, our maps would be the way to pull him back into the ‘now.’ It spurred many conversations about context and potential conflict. This was an experience that proved to me that, pairing with my team QA was exceptionally beneficial to the project.
The team has researched, developed and tested code so its time to release. A very important part of this phase is implementing and tracking analytics. The results can produce business insight, patterns of user behavior and more visibility to catch bugs in the system. This type of data is sort of a freebie, the match you get with your 401k. If you are in beta then these analytics validate your product and potentially save you from a big mistake before it hits the market. If you are releasing live to the market, then these analytics can be used to reassure trust with your customers. You are ready and watching for any mistakes or errors that may occur during their usage. UX can use these insights to assess user behavior while QA might use the analytics to catch bugs. Together they can recognize user behavior patterns and make sure they are free of bugs and/or any workflow blocks for the user. If identified they start from the beginning, re assess their design make and make any changes necessary to create a truly usable product.
At the end of the process UX and QA have a variety of ways to pair: Specification by example, the creation of the style guide, usability testing and analytics. QA impacts UX and pairing early and often can help close the gap between understanding and satisfaction to truly build a usable product. Try it out, it’s worth the conversation!
“There is an inverse relationship between control and trust — the more you give away, the more of the other you expect back in return.”
How to design for cloud:
1. Design a cloud computing experience that becomes invisible.
2. Open ID: Helps meet our goal of ensuring our users gave the moest efficient experience possible. Best practices- Visibility, support different logins, return users to the task at hand and don’t distract them.
3. Security (see quote above)
4. Social: Layers of info = meaningful insight.
5. Distribution: Not just consistent but continuous
Doing a talk on this:
Jacob Nielson said: Quality assurance impacts the user experience: when things don’t work, users question their understanding and develop superstitions and inefficient workarounds. Business process, system intelligence, ideal workflow scenarios, overall testing and user interface design are aspect of UX and QA that contain much more overlap than meets the eye. We’d like to share creative ways to collaborate and ultimately to build a faster, cheaper and most importantly usable product. After all, ‘it’s 100 times cheaper to fix a design flaw on the drawing board than after product launch.’