Where the design community meets.
Los Angeles Designer in LA Joined about 5 years ago
You are welcome! Glad it was helpful.
I don't really write that much.
I would recommend reading and listening to Erika Hall and Jared Spool. I've learned more about design from those two than anyone else.
First thing I would do is frame it just as a normal, casual conversation. You might only need 10-15 mins. If you need longer, invite them to out to lunch. That can make it feel more approachable. Pitch the conversation as a "shop talk" session where you just want to learn about what they do day-to-day. No need to seek a "key informer". Just find people who have a vested interest in the problem space you're designing in. They might be worried you are there to judge them or they will somehow get into trouble for speaking truthfully.
If the person you want to talk to simply refuses and you have no one else in an analogous position to can talk to, I would escalate the matter to your manager. They should work with other business units on getting you the access you need.
If that does not work, then the organization is deeply dysfunctional. The path ahead to align the organization in a way that would allow you to learn what you need to is long and hard and maybe not worth your time. If you want to stick it out, continue talking with your manager on how to solve the problem. Approach it as another other design problem. Try to understand the underlying motivations and goals of the folks you'd like to talk to.
At the very least, revisit how your role and position is evaluated. If you are evaluated on the outcomes of your designs but are prohibited from truly understanding the context, environment, and users of those designs, then you are being set up to fail.
I've found that gathering context and understanding from these groups before the UI is designed is much more valuable than getting comments after the fact.
Get a person from each group in a room and interview them. Listen to what they're goals are, what they are trying to do, what worries them, etc.
I think you'd have more compelling results if each product that you released had a control and experiment group. The experiment group had all the nice "designery" things and the control didn't. And then you measure real product engagement with each group.
Here, you can measure engagement (how many people used the site to achieve a goal?) and retention (how many people who used it at least once in a month came back again in the same month?)
Your experiments are measuring traffic to the site, not how well the site actually works.
They are different problem scopes.
A company might have a fine brand and logo but due to new contexts (app icons, environmental, print, VR, other digital formats), the logo might not work well. It's too small, it has too many colors, it doesn't work well in non-uniform backgrounds. So the designer needs to design a logo that works in these new contexts. The problem scope is localized to the logo.
A "brand" problem would be is at a higher organizational level. Uber's recent rebrand tried to solve at least two problems: bad PR from a bunch of scandals and a confusing brand system composed of "bits". A new logo was included in that brand problem along with new design language, fonts, etc.
Something I would try is not to "convert" a logo request into a brand package but to first ask what business problem the client is facing and see how you can help. A logo is a solution to a problem. The client might request a logo thinking it might solve a problem but it might not. As you dig into the client's business, you might see new opportunities for larger projects.
You'll also build credibility with larger clients. When they see you as a business partner instead of just a logo designer, they will think of you when it comes to solving bigger and more complex problems.
Writing should be done by the designer IMO. You collab on what it should be with stakeholders, your team, etc. I treat copy like any other UI element.
You can develop voice and tone documentation to help you write coherent and consistent copy. This is particularly helpful on large systems with many teams.
Mockups should not be the source of truth (I assume that's what you mean when you say 'source of trust').
developers are blocked until I finish updating the mockups
This sounds like an awful situation that leads to a lot of bad outcomes. Changes to copy (or any other UI element) should not be a dependency on engineering. I would work with your team, execs, decisionmakers, etc to figure out why that is the process. It's adding unnecessary bottlenecks to the process and unnecessary stress for you.
Hey I worked in healthcare.
Based on the product description, your practice-facing supply side users sound like front desk staff or the office manager. Most doctors aren't worrying about scheduling patients. They usually hire people to do that. The provider is a stakeholder (they want more business for sure) but the person who ends up buying and using it might be someone else.
I would try to figure out who your real users are and then go out and learn about them.
As far as getting them into a room, some kind of compensation will go a long way. It sucks if you don't have any capital but it's worth it. It's better to spend money now on interviews and usability tests than to spend more later building a product no one wants.
Yep agreed. Sorry if I was being glib; this is a sensitive subject for me. I just spent the last 10 months trying to convince people to do research and failed. What I’ve learned is people don’t make decisions based on their best self-interest. They do things based on their value system. The evidence for conducting research is clear. However, within this company, "being correct" was valued. So when I asked questions about our users and their contexts, it conflicted with that value system. "Why don't you already know the answer?" No amount of data or logic or evidence could change that perspective; it was engrained in the culture. What I needed to do was to reframe the research so it worked within that value system. But before I could figure that out how to do that I got burnt out and quit.
A few years ago, I was working on a healthcare app that allowed patients to pay their medical bills. In the US (and probably elsewhere) there are strict privacy laws around healthcare information that require patients to authenticate their identity before a service can display any medical information. Success for us was to get as many people paying for their bills through our service instead of other means (CC payment over the phone, mail a check, payment in person, other payment solutions, etc).
We assumed that patients would want to see their full medical bill including services and procedures before they would pay. People want to know what they are paying for. Seems obvious right? Well, we challenged that assumption. Would people pay if they only saw the final amount due? I didn't think so. Before we designed or built anything, we learned more about that scenario. We found that there are people out there (a new undiscovered persona) that would do that. Parents, legal guardians, and caretakers often do this. They don't need the full medical information; they just want to pay the bill.
So we designed the software to allow you to create an account/sign in to see all info, or, you can just make a payment (this was actually really technically tricky that added some risk to the overall project). ~50% of payments were made without the person authenticating and signing in. If we didn't do the research, we would have built something that didn't work for those people and the product wouldn't have succeeded.
If we didn't do the research and just released it as first intended, would we have learned what we learned through research? I don't see how that would be possible. We would have received half as many payments but we wouldn't know how much was left on the table. We wouldn't know where to look. We wouldn't be able to look at the database and say, "Oh it's because the we didn't build it to serve parents and caretakers who can't/don't want to authenticate." The Lean Startup build-measure-learn cycle isn't design. It can't tell you what you should do.
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.