Where the design community meets.
Orange County, CA Product Design at Weedmaps Joined almost 5 years ago
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.
Some reasons I've been told for why we can't do research and/or testing:
You probably don't need a screener form anymore. You can run software in the background that can predict—to a reasonable degree—if you've actually read an article or not. It could watch things like time on page, scroll behaviors, etc. This is basically how Google's reCAPTCHA works. If it passes, show a share button. If not, don't.
This is probably tougher on desktop browsers where the user can just grab the URL and paste it anywhere they want.
They could sell the crap out of that data on their ad exchange. Surprised they aren't doing this already.
Amazon has some built-in protections against this type of behavior. Competitors used to do this same kind of brigading with reviews.
Coding doesn't irk me. I enjoy coding.
But I think designers are better positioned to impact a business, project, experience, etc in other areas. Specifically in understanding who the user is, what they're goals and scenarios are, aligning with business needs, collaborating on prototypes, and user testing.
The prototyping can be done in code. Some times it is required but mostly it isn't.
If it suits your work style—carry on. But I wonder if it should be a requirement for designers.
Heh. It's not easy. Our design system is very much an MVP. So when we add or update the system, it's a laborious process of updating sketch libs, documentation in Confluence, and React components.
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.