Who’s Down — UX and design takeaways
Hi, it’s me again!
I’m following up my previous post with more thoughts in designing Who’s Down. Here are some of my personal (design-focused) takeaways from designing and launching a product from scratch.
Design for Wiggle-room
Strive for excellence, not perfection
Design the ideal user experience to 70% and leave 30% for the unknown. Make sure the foundation is there and it can scale. Often times, as you build something, unknown issues come into play (technical, time, etc) and you need to come up with new solutions on the fly. If the core experience and foundation (e.g. navigation) are there, this will allow wiggle room for last minute changes.
Keep the designs lo-fi
I’d recommend keeping the designs in the sketch-phase for as long as possible. Especially if you want to move fast. Once you lock designs into higher fidelity, it’s harder to move away from. Another bonus of keeping it lo-fi, is that the designs will feel more approachable and your teammates will feel like they can give feedback/input versus hi-fi designs that look untouchable.
Pixel-perfect mocks are slow
It’s faster to work interactively with engineers. There will be more rinse-and-repeat cycles to get it looking right, but it’ll be faster because the product and features often change while building.
Stay nimble and flexible
When building a product, it’s similar to a basketball game where you come in with a playbook, but then you adjust and adapt as the game goes. An advantage we have in tech vs other industries is that we don’t have to be as rigid because the medium allows for quick pivots (get it?!).
Think holistically and see the big picture
Map out the whole system and lay the groundwork first. It’s like building a house. Create the house’s blueprint and wood framework first, before putting on the coat of paint.
Keep it simple
Of course, this is cliché. Anything that’s considered being added needs intense scrutiny. Added features creates more complexity.
The MVP Design Process
When you’re designing a product, make sure you’re focusing on designing the right things at the right time. Focus on designing the core experience you want to test with users, and see if that resonates. Then methodically add new features and ideas from there. Just be mindful that the product will change fast as you design it.
Teamwork
Interdisciplinary teamwork
Get everyone involved. Start with a sprint or brainstorm so everyone feels invested. The output is greater over time.
UX is the heart and soul of a team
Designers want to connect with their users. We are trained to empathize and improve people’s lives.
Product designers are full-stack and work end-to-end
Product designers enjoy doing everything from problem-discovery, to concept-brainstorming, to creating hi-fi mockups, to user-testing, to prototyping. During the last phase of building, they’ll be there testing and submitting code to improve the UI.
Designers should code, or least understand the technology
This creates empathy with your engineering counterparts (also, so you can feel their pain when trying to change things). You will also be able to tweak UI on your own and let the engineers focus on the bigger engineering tasks. Hopefully, if you meet someone halfway, they’ll meet you halfway.
Designers, as Jedi
A big part of a designer’s responsibility is shepherding and (subtly) influencing the rest of the team so everyone starts thinking like a designer and using best UX practices. There’s an art to seeding the cross-functional team so they end up thinking like a designer and improving the user experience of the product on their own.
Keep the design work transparent
Make sure everyone sees the design progress and it’s always open to the group so everyone is on the same page. Do weekly syncs/reviews with the cross-functional team so members can give input. Post up the designs on paper so everyone in the room can see the latest progress.
Faith in the Design Process
Draw from your influences
Some of Who’s Down product design conception and thinking derives from Alone Together by Sherry Turkle, Mark Weiser’s publication called The Computer for the 21st Century and Don Norman’s Opportunistic Action model.
Create design principles
This will help to structure your design decisions. Here are some principles used for Who’s Down.
• “Start with an activity bias, eg. a hammer’s handle invites you to grasp it, and primes how you might use it.” — John Maeda
• “Do one thing and do it well” — the Unix philosophy
• “The purpose of a computer is to help you do something else, and the best computer is a quiet, invisible servant.” — Mark Weiser
Adhere to the Design Process early on
To focus and define your team process, it’s helpful to answer these questions first.
• What’s the problem?
• Is it a problem that actually exists?
• How many people have this problem and is it worth tackling?
• Who exactly has this problem?
• What parts of the problem are best to focus on?
• What are some solutions to this problem?
• Have you tested these solutions with your target audience?
Stay focused, stay patient and trust yourself
It’s a marathon when building a product. Half of building something is just grinding it out. It takes fortitude, stubbornness and resilience to keep everyone on the same page too. As a lead, it’s important to listen to advice, but ultimately you will have the most information to make the decisions.
Trust the process
If you do due diligence in every phase of the product design process, you can hope that what you make will turn out well. Additionally, if you create a good process, you can hope to replicate it again.
It’s sometimes about the journey, not always the thing you build
The processes you learn, the experience you gain and the skills you build will usually last longer for you than the thing you create (especially when working in a fast, ever-changing industry such as tech).
I hope some of this is helpful to other designers out there. Thanks for reading!
