Insights into the life of a UX/UI/Product Designer
Step 2: Make the business happy
Now that we have some real or empirical data on the problem, we can start drafting up some solutions. You possibly have a document outlining the core company values and business goals. If you don’t, get that done ASAP as these should always to be in front of you whenever you propose future solutions.
Remember that while your initial job is maintaining the user’s happiness, your challenge is to do so the way that your solution brings real value to the company.
Start with sharpie sketches or if you already forgot how to hold a pen, head into sketch app and lay out some stories regarding the issue. You’ll likely have a few routes you can take in solving the problem for the user, draw them all out in separate mind-maps. You can do these mind-maps with post-its on the wall, or there are several mind mapping programs for your computer or tablet. One of my favorites is Pinnic, the iPad version for your wall and post-its. Reorganising your post-its and linking them up are super easy, you can also attach photos, links and whatnot. The end result will remind you of the walls of a detective going after a serial killer. I’m a sucker for thrillers, no wonder why I chose this program.
After you have the different use cases drafted up in these mind-maps, add the business goals and values as separate post-its and try to match them up with specific steps in the user’s journey. Investigate that at which step could increase any business KPIs and why. Think about which additional functionality could make the development of the whole solution to turn a profit? What additional benefits could the business accrue throughout the whole journey to make the investment worth its while? Feel free to ignore me here but I think it’s quite powerful asking these rhetorical questions
Why I say you need to do all of this is after doing it, you’ll be able to defend your proposition and its costs. The business has to always think about ROI and you had better be prepared to be asked to prove the ROI. Try to think beyond increased retention, conversions or reduced maintenance costs whenever possible as repeating those values to the company will grow old soon and is hard to measure upfront. New horizons are always intriguing and help you to get a positive decision for plans that would otherwise be business as usual type of improvements.
Before you present your proposed solution to the top floor, convert your sharpie designs into a clickthrough prototypes using Sketch, Adobe XD or Marvel. You can even upload photos of your sharpie sketches and just link them up, it doesn’t really matter at this stage. Re-test these prototypes with a number of users. I like to use a few from the same set of people I interviewed at the discovery stages, plus an additional control group that haven’t yet seen, or discussed the specific issue that you are working on. This way I can see if the solution is only a placebo solution to people desperate for a change if the new prospects still report the same issues. In lieu of having formal test users, collect a group of people from the company or try to ask friends and family as you will need to prove the benefits of proper testing. Oh, and be prepared that one solution might open another can of worms.
Throughout the re-testing sessions, measure if the acceptance and usability rating improves with the proposed solutions, so you’ll have some extra proof to present when proposing it.
Grade your proposals based on acceptance, and ease of use. Then select two or three that are have the highest rates. Drop anything with subpar ratings and rather go back to the drawing board and come up with some new solutions. But for now say everything is nice and dandy, so you are almost ready to confidently present your solutions to the stakeholders. I said almost as you’ll need one little extra detail. So out we go on a legendary quest to retrieve that magical artifact called ROI. Let’s not waste more time, Adventurer, let’s get going!
Step 3: Make the tech-team happy
We are almost at the finish, and I don’t know if you realised it, but so far we didn’t touch our design software too much.
Developers are usually pretty much left out of the design process till the point of handing them over the designs. This is possibly the worst practice, as those are the guys who know your product on the deepest level and not only can they provide you with amazing ideas and history of what was already on the table, but can possibly give you a history on why they didn’t succeed or what’s the story about a given feature. You might also learn that specific (possibly great) things are already developed but are parked somewhere on a GitHub repository because your predecessor deemed them useless (can you tell I am speaking from experience? 😉
Show your prototype to the developers, so they can pick up on any roadblocks that would result in delayed sprints. Get rid of those roadblocks from your design if they are not essential. Run it by them again just to make sure they didn’t miss anything.
Our next step involves some devs or leaders from the tech team that understand the system and are capable of giving you a T-shirt size estimate on your proposed solutions. Now you have the other end of the ROI.
On better, but possibly more costly solutions, ask them how could you make their life easier, if they have any extra ideas that would turbo boost production of any features.
The company will want the cheapest and fastest solution almost every time, so if you have a solution that’s better but double or triple the cost of the quick and dirty your chances to get the better experience signed off are close to nil. What you can do to reverse that is to ask the developers of all the downsides of the cheap solutions as they might tip the scale towards them choosing what’s better for the users after all.
The other significant benefit of involving the tech team before getting a sign off is that developers usually have their own — and great — ideas about product direction and they hate getting signed off proposals and being put into a situation where they have to deliver something that has no flexibility or their involvement at all. The earlier you involve tech in your processes, the better synergy and less pushbacks you’ll experience.
After everything is cleared out and you could calculate the ROI, and have all the pros and cons on your solutions, present the best two to your stakeholders. My experience is that if you go with one solution, it’s a yes or no question that might render weeks of work useless if it turns out to be a no. When you present two options, it becomes a multiple choice and your stakeholders are more likely to approve one than say no to both. Think about asking your partner if they want to go to Papa Johns, or if you ask them if they want to go to Papa Johns or Pizza Express. The second variant gives you better odds having pizza that night than the first one. Mmmmm unicorns love a good pizza, that’s where the magic comes from 😉
After you have one of your proposals signed off, go and be a designer. Design something that will make everyone working on it real proud. While doing it, make sure you won’t make the developers life a living hell.
Start with using a design system. Not only will that speed up your workflow, but it would make sure that your designs are consistent. That keeps the developers life easier and they won’t need to create exceptions for your 16th version of a primary CTA or just a slightly modified version of a carousel. Choose a style and stick with it. In Sketch, using nested symbols right from the wireframe stages keeps my files in order and makes the next rebranding exercise a breeze, I don’t even start a job before I have my design system in place.
Think about edge cases, multiple resolutions and draw out all different variants without even being asked for it. Prepare for possible error messages due to wrong user behaviour and prepare screens for those happenstances as well. I appreciate if you are not into development you might miss a few of those, but keep communicating and checking in with the dev team through your preparations towards handover to make sure you covered all bases. As this is your only chance to actually be a designer, use your time wisely and make sure that every aspect of your app, regardless of device, resolution or user errors, everything looks perfect and professional.
Hand over your designs on Sketch cloud as a clickthrough prototype as that would make everything clear to devs. If you wish to have animations, prepare those in Principle, so they have a visual feedback on what is that you want exactly. Export animations in gif or mov and add it to the relevant tech tickets for reference as many developers prefer to use a PC. Also share the sketch file to the developers so they can import it in Zeplin, Avocode or Supernova Studio based on their preference. The latter two can provide you with production ready code for various codebases, so if you haven’t yet checked them out, I recommend you do now. Be nice and export all assets for them upfront. If you want to go the extra mile and you had to use png assets instead of svgs, at least run those pngs through tinyPNG before handing it over. Saving them time will result in a way better atmosphere between design and development. Throughout development and through preparation, use their selected project management platform religiously, be it Jira (God save us), Trello (my favorite), Asana (ssh, it‘s ok) or one of those fancy new tools like Monday (seriously don’t know what to think about that one).
At the end of this process you should have happy users, happy devs (but don’t expect them to look overly happy though) — and as an outcome of that two a happy business. If you are luckier than me, possibly even have some hair left on your head at the end of a project.
Special thanks to Cherry Maguire, my wonderful PO at WeShop for proofreading my sometimes messy English text. I hope you enjoyed my first publication, please inflate my ego by leaving some applause on the article.
I’m preparing a more hands-on practical guide on sketch based design systems and rapid prototyping (with gifs and real life examples other authors are spoiling you with).
If you are interested, please subscribe and keep your eyes peeled (I know, it’s a very Dexter thing to say) for the next article 🙂