Research determines the problem.
Technical determines the solution.
User evaluates the solution.
Do it again until it is done.
The designer (and others including but not limited to researchers, marketing and engineering) is solely responsible for the first two. The user is solely responsible for the third. Any commingling tends to derail the process.
The topic of the thesis is " How can designers embrace Ambiguity in the product design process to create richer and more meaningful product experiences for the user" in regards to relationship between the Designer and User, between the User and Object (Product), and between the Designer and Object(Product)
What this entails is looking at how designers extract data from users and interpret those into objects(products) in which the user gives meaning to and interprets resulting in the user-product experience.
As for the questions I posed earlier, i am curious as to what designers view and think their relationship with users is, what their role in this relationship is and even what the role of the user in this relationship is?
Does this help?
Again thanks for any feedback and comments, they are much appreciated.
Your questions are still vast in scope. I’ll stick with my original vague answer.
But I would add there are some designers I would not want within a thousand yards of a customer. Horrible interviewers. Some can’t even sit quietly and observe.
Then there are others who can sell wheat to a Kansas farmer. But that doesn’t mean I want them talking to a customer at all times.
It will depend on what type of relationship is appropriate. That will depend on what phase of development you are in, what type of information is valuable for the designer and other factors. So sometimes you what the designer to sit down and shut up. Sometimes you want them to be an educator. Sometimes a cheerleader. Etc.
But you be surprised at how many turn out to be a defensive twat.
Users voice a problem with an existing product or lack of a product to solve their problem,
Research validates the problem’s existence and/or finds more issues common to the problem,
Designers determine possible solutions to satisfy the problems,
Users validate the solution(s) first with second pass research and then with purchase power after the final product is manufactured.
Here’s another approach. Try answering your own questions and then we can give you our feedback. They still sound like leading questions to a desired answer or a late night debate at design show. Answering those questions would take somebody over 30 minutes and they will vary greatly depending on the designers background.
I’ve found the key to successful interactions with others on a project, whether they are coworkers, clients, or users, is resisting the urge to be a defensive twat.
I think the above outlines do a pretty good job of describing how things should go, but it doesn’t always happen for various reasons and there is certainly variation among companies/designers. You’ll find some that brag about being users themselves and operating under the general assumption that if it works for me it’ll work for others, though I don’t think any company can get by for long without paying attention to what is actually selling and how other users actually use their products. Then there are other companies/designers that design for demographics that they can never fit into who are forced to acknowledge that they are not the user and design for someone else (following the rough outlines above).
Even when you are designing for a totally different demographic the designer will have to sometimes pretend to be a user in order to test designs. I know ideally we should be iterating quickly and getting in front of customers early, but it’s not practical to have a focus group every day and a half as we come up with new ideas or make quick mockups. So designers and engineers will have to in some way put themselves in the user’s shoes, whether that is mentally by refreshing yourself on the problem statement and user research or physically by wearing gloves to make using a device harder. Often it is helpful to note where you differ from the user, whether it’s your height, tastes, etc.
It’s still a very open question though and I’m not sure the above thoughts apply to your thesis. I think you’re trying to keep it vague so we aren’t restricted with our thoughts, but as FH13 has said, answering the open ended questions thoroughly would take quite a while and I think you would get very honest feedback if you presented your draft thesis statement.
I don’t think that is a dissent necessarily. While what you write is absolutely true, I think the majority of the time the user cannot articulate the problem and it is the role of the researcher to define the problem.
I’d also say problem definition is an iterative process, just like problem solving.
We are probably saying the same thing but as it turns out, I am as inarticulate as the user.
The role of the user is just that, to be the user. The role of the designer is to interpret and provide solutions to feedback, data and ambiguity from the user, marketing, engineering, etc. The way to get rid of ambiguity is to provide visual and physical options to help solve the challenges. One of my favorite quotes:
“I prefer drawing to talking. Drawing is faster, and leaves less room for lies”. Le Corbusier
I feel like I should be wearing a black turtleneck & touching my face! I’m out.
Just to riff a bit, in my experience many times users can not truly articulate or even realize they have a problem. Often they have found a work around that is odd but has become their normal. Spotting that odd work around, calling attention to it, and articulating it is a problem/opportunity is a skill.
I’ll pile on to my own inarticulation…I’d say my statement that “users voice a problem” really should have been written as “users identify that problems exist either by voicing it to an audience at large or to research stakeholders, or inadvertently while being observed by research stakeholders”. I like that better.
But to advance the discussion a bit, I have always thought the crux is the problem definition. I am confident in my abilities to solve any problem, but the trick is solving the “right” problem. That is an extremely valuable ability of the researcher.
I also think this is where ID falls down. A lot. IDers are not traditionally trained in this area, nor does it fit with an IDers “natural” attributes. I’m certainly not saying an IDer can’t do it, but it would be akin to having the researcher rip a hot sketch.
So while I encourage those on the technical side to go to the “field”, it should be limited. I don’t need them to cause any harm.
To help identify and solve the right problems, we’ve always believed industrial designers should have an observational role in user research. Ideally, we like to use a market research firm with screened user visits but if a client’s budget can’t absorb that level of research, then we use a well scripted guide to capture pertinent data during interactions with users.
Agreed. Usually helps if there is a good trained moderator or at least a designer that has aptitude in that area and is gentle and skilled at asking non leading questions. We have used outside firms and when we do it ourselves one of my teammates is skilled in that area. I then usually asian a couple of designers to document the session, photo/video/notes. This has two advantages 1) it keeps them busy 2) the designers are hearing the info first hand, unfiltered by a research team. Good and bad to that but I think mostly good.
I’ll give you an example. We did a round of ethno sessions with families and discovered a key purchasing driver of additional audio for their TV is the intelligibility of dialog. Yet this doesn’t align with the features of a typical simple soundbar or home theater in a box which tends to emphasize surround effects and bases with surrounds and subwoofers. People complained about having to turn up the volume in quiet spots and then an explosion happens and it wakes up the kids. So taking that back to the studio we started to wonder what we could do with that. We started playing with the concept of a separate volume control that could adjust voices. Then we worked with engineering to see if it could be done. They develop a unique adjustable digital signal processing component in software that could scrub through the audio content for human voice ranges and allow a user to adjust it. A little more research and it turns out the remotes are not displayed at retail so people would not see that feature, so we added the button to the top of the product so it could be seen and added a POP sleeve explaining the feature. We also got a utility patent out of it and made sure that when reviewers tested it for PR that they were aware of user benefit… and BOOM, one of the best selling non-TV maker soundbars. In the top 3 I think.
It is a mall benefit but one driven by an unmet need and I think it resonates.