29 Things I, as a designer, wish more tech startups knew

From Stephen Anderson, as part of The Pastry Box Project:

29 Things I, as a designer, wish more tech startups knew:

1. Learn the difference between a UX Designer and a Visual Designer. They are not the same. And while there is (and should be) a lot of overlap in skills-it’s good to know what the designer you’re hiring thinks is priority.
2. Recognizing these differences, know that a pretty coat of paint will not make your very real usability problems magically disappear. I’ve said as much in conversations: “So, to be clear, you’re just looking for a shiny coat of paint right now, and you’re not interested in fixing the problems that are going to stop people in their tracks…?!”
3. Form labels, microcopy, instructional text-this is core to an application. In fact, the best UIs often start as written conversations between the user and the system. Be wary of designers who layer copy into their lovely layouts, or worse, use “lorem ipsum” as a stand-in for functional copy; these are signs you’ve hired a stylist and not a designer. (The same is true of visualizations-good designers start with the data, not the pretty pictures!)
4. Don’t look at a design or prototype as an approximation for what should be implemented. A good designer will sweat every detail. A 20px size difference, a change in the typeface, the timing of an animation-these kinds of things make the difference between confusion and delight.
5. 1. Bring in the UX designer before you’ve attempted any UI work. I can’t tell you how many times my clients have said “I wish I’d brought you in earlier!” The UI changes are often enough to necessitate technical re-architecture. Starting with a good designer from day one will save you a lot of headaches later on…
   2. Of course, starting with an existing alpha version means requirements have been defined. In these cases a good designer can spend her time redefining how things get done in the UI (however, be wary of “functional fixedness;” I spend a lot of my time just getting everyone on the team-designers included-to see the problem in a different way, not the way it has been implemented).
6. Listen for what your customer needs, not what they ask for. Good design (or UX) isn’t about giving customers everything they request-it’s about listening to these needs and then showing the thing they can’t articulate (unless they also have a good design sense!).
7. Iterate on a weekly or bi-weekly basis with real customers and users. Do not skip or marginalize this critical feedback loop. If you do, you risk building a product that no one else really cares about using.
8. Iterate with 5-7 different customers who have very different needs. If you design for a homogenous group of folks, you’ll end up with the perfect system for a small minority; your system likely won’t scale to accommodate the needs of a market. By testing with a diverse group of customers, you rise above specifics to see the patterns and common challenges. You create a product that addresses a market need.
9. Make sure your problem space is well researched and that you’re beginning with customer input, not waiting for it later on (when it’s too late to make significant changes).
10. Hire a dedicated front-end developer. Don’t let your UI be the afterthought of back-end programming. There’s too much going on in the UI to rely on libraries and frameworks. If you’re doing anything at all unconventional, you’ll need a good front-end dev to build these out. Better yet, pair this front-end dev with the designer so they can create and iterate together on functional prototypes. Then, once these designs have been vetted with customers, there’s no documentation needed for styles or behaviors, or miscommunication in the dreaded “handoff”-that stuff is already taken care of. The UI is ready to be hooked up to the back-end systems.
11. Good designers will care about your technology stack, to the extent that it affects the UI.
12. Design from the “bottom up” (vs “top down”). What do I mean by this? In web apps, the structure of your app (IA) will emerge over time-don’t start with structure or navigation. Think about flows, scenarios, and activities. The structure of the site will emerge from specific page level designs. Start with a laser focus on a specific activity, then follow that thread into other areas of the app. Starting with a top down focus on structure and consistent UI elements often glosses over the details and minutiae that set apart a stellar product. And don’t get hung up on inconsistent interaction and visual details that come about from this bottom up focus-these details will be ironed out as time goes on. That said, if you start with a comprehensive UI framework such as Bootstrap or Foundation, this will help a designer be intentional about introducing inconsistencies. Not that I’m admitting a personal flaw of mine or anything.
13. Don’t force web site patterns on a web app. For example, don’t waste your time thinking about “what should go in a home page?” (of the app!) or what goes into the tabbed navigation. If you’re designing around a defined flow or set of common functions, your app will more closely resemble a mobile app than a web site, with a focus on content and functionality over chrome and navigation.
14. Design for mobile first (even if a mobile app is not in your roadmap). The constraints of a mobile context will force you to focus on what’s essential, and help you cut what’s not needed. The question “How would I design this as a mobile app?” always clears my head and helps me find the simpler, elegant solution.
15. Don’t over design. Less is better in the early stages. Launch with too much going on and you won’t know which pieces are broken and which are working.
16. 1. Focus on the experience, not the product. Assume people won’t want to use your product-in fact, they don’t! Except for the early adopter/beta-junkie, most people have existing habits; you’re competing against the inertia of existing behaviors.
    2. Design for the existing ecosystem. People already have apps they know and use. Rather than try to displace those, can you work with these other systems?
17. Reject any design candidate who is overly focused on process. UXers accustomed to corporate environments may want to “do it the right way” (there is no right way). Aside from initial research, most startups can’t afford (or shouldn’t be spending money on) too many deliverables or things that don’t directly translate into product improvements. Iterate early and often. Don’t focus too much on documentation.
18. 1. You get what you pay for. I charge a lot. But, I guarantee you’ll save money in the long run. Most visual designers at ¼ my rate will take much longer and still not get you where a seasoned veteran will. Note: veteran doesn’t necessarily mean years experience-2 years at a dot com startup taught me more than most people learn in 5-7 years at a big company.
    2. As a corollary to the above comment: experience and naïveté are good things. You get a fresh perspective not indoctrinated with jargon or groupthink.
19. Designs are never handed off. Design isn’t a stage-it’s always happening with every new release. Think long term.
20. Hire “experts” initially. Transition to mid or jr. level folks over time, as the problems get more defined. Keep the expert around to offer guidance and mentor these less experienced folks. This, by the way, is the approach I use with my startup clients.
21. Work together! Don’t think about handoffs, think about collaboration. Where there are too many meetings or an abundance of documentation, I’ve also seen a proportionate lack of communication and lack of clear alignment amongst the team.
22. Frame the problems to be to be solved, then evaluate accordingly. Set aside your subjective opinions. Evaluate the design based on how well is satisfies (or delights) the end user.
23. Good designers will question assumptions-and will very likely ask you to undo stuff that’s already been done. This is a good thing. Mostly.
24. Good design doesn’t happen magically: there needs to be: (1) a well articulated-and shared-vision, and (2) autonomy. Making sense of a really, really hard problem requires uninterrupted time where you can “go deep” with a problem (8 1-hour blocks of time do not equal 1 8-hour block of time!).
25. If possible, build your API, then build your app on top of this. This leaves room for a lot more flexibility, both in terms of what you can do in the UI and portability to other devices.
26. Please, please, please spend time hanging out in the latest and greatest apps, regardless of their personal relevance or interest to you. If you do, your expectations of a “good experience” will be raised. Archaic team communication tools are often a good indication of what the decision makers believe qualifies as “good.” (Hint: it’s often a very low bar relative to what’s possible!)
27. Unless you’re doing something entirely new or different, think about the Minimum Viable Experience. MVP tends to focus on features and functionality. In a crowded, mature space, HOW you implement something is equally-or more-important than WHAT you implement.
28. What should you look for most of all in a designer? Curiosity, Empathy, and Grit. I’d care far more about these traits than any artifacts or prior “design” experience.
29. Get to know each other outside of the work environment-as friends. It’ll make the day-to-day collaboration so much easier!