Categories
- Design Systems
- Interal App Suites
- Design Process
- Design Theory
Client
AppleApp Review Team
Role: Interaction DesignerCollaborators
- Full-stack UI Engineers
- Product Managers
Summary
I worked at Apple on the App Store Internal Tools team for 2.5 years as the sole designer supporting engineers and data scientists. I am not able to talk about or show actual work here, so this article details the design process I utilized to design and ship internal tools.
At Apple I redesigned end-to-end user flows and high fidelity UI for apps relating to the App store submission and approval flow, comprehensive app provider and developer tools. I worked on both MacOS native and web apps. We upgraded the visual UI and app branding, simplified the flows and integrated ML tools for improving the user experience. Our results were measurable and we continued to iterate and incorporate new features.
How to be process-oriented, not outcome driven
Being process oriented, not outcome driven, is an important and difficult skill for a designer to develop. The design process is often structured and methodical, but it is not a mechanical process. I take this approach at Apple.
As interaction designers, we are comfortable in the state of design decision uncertainty. By following a set process of research, storytelling, prototyping and polishing the best solutions arise.
By investigating creative problems, measuring user-analytics and user-testing our work, and contining to iterate towards solving user pain points and reaching business goals. We succeed when we are able to create memorable and enjoyable experiences that solve real user problems and achieve measurable business goals.
Tips for being a process oriented designer:
Ask the right questions by interrogating design challenges and empathizing with your users.
Seek to understand design goals before chasing after solutions.
Don’t force fit solutions to old problems onto new problems.
Be aware of project constraints, edge-cases, and the inevitable trade-offs that come with most design decisions.
Remain flexible to changing requirements and conditions. Communication with stakeholders is key.
Avoid prideful investment in your ideas and be slow to fall in love with them.
Make design decisions holistically rather than solving them individually.
Know when to make a change and know how to defend design decisions.
Accept as normal the anxiety that comes from not knowing what to do. Have confidance in your design process and put in the time.
Design your products to function fluidly across all platforms and devices. Respect the different environments without sacraficing brand consistency.
Always ask “What if…?” regardless of how satisfied you are with your design. Prototype and user-test your ideas. Draw insights from testing analytical data.
Remember that design is never done. Iterate in cycles towards more optimal results.
Embrace rapid prototyping. Design mocks are generally fast and cheap while coding the wrong solution is slow and expensive.
Keep your designs simple with a focused utility and a crafted execution.
Create an intuitive and favorable user experience. The onboarding and user journeys can make break your audience’s perception of your product.
Be bold and intentional with your design decisions. Designers know the rules and conventions before breaking them.
Create meaningful experiences through motion. Intuitive subtle SVG animations can help guide your users and adds delight.
Be comfortable with not knowing the design outcome. Properly gaining control of the design process tends to feel like one is losing control. Your job is to shepherd the design process.
Ask the right questions when you approach a design challenge
Design interrogation
Before starting a new design concept, I start by investigating the problems you are trying to solve by writing down specific answers about the target users, stakeholders, constraints and goals:
Audience. What types of people are you serving with your product? What’s their current workflow and painpoints? What motivates them? Be specific about the persona-users you are serving.
Constraints. There are intrinsic constraints that come with every project. All design decisions have trade-offs. Some common constraints are budget, performance, useability and timelines with competing priorities.
Stakeholders. It’s important to identify the people that have an interest in your project and can influence its success, such as clients, department heads, or technical engineers on the project. What are their concerns?
Goals. Write down business goals and users goals. What metrics will define success? What are our short term goals with the product? Do they align with our long-term goals with the product and greater brand vision?
Chart the journey
You can think of your design challenge as a voyage. Your point of departure is where your product and your users are currently. What are the daily workflows and pain points?
The destination is your objectives. The more specific and clearly articulated your destination goals, the greater your chances of success. What business and user goals are you trying to acomplish?
Once you understand your users and your goals, the journey is to connect the two. By asking the right questions and emphasizing with your users, you are now able to ideate possible solutions. Be specific about your audience and their user-journey stories they lead as they use your product.
Evaluate your assumptions with both user research and data
Collecting quantative data and qualitative research both have their strengths and limitations. Data doesn’t communicate users’ attitudes, motivations, and the source of their confusion when using the product. Qualitative user research can better answer these questions.
Quantative data is essential for approaching your product with the scientific method. Analytics can reveal where your assumptions are wrong. For example, you can measure at where users drop off and where they are succesfully completing micro-interactions within the app. A/B testing can reveal which solutions are better for fufilling your measureable goals (KPIs).
Indivdual user testing can reveal a lot about your design. By giving the subject an interaction to complete you can observe when they get stuck or hesitate can reveal more about your design assumptions.
It is critical to perform design research how others have addressed similar challenges. Where did they succeed? What did they not think of? I like to compare products and write down workflows with screenshots in a spreadsheet. This allows us to identify both trends and also opportunities that others may have missed.
Storytelling adds the human element to product design
At Apple, storytelling is used at every step of the design process to highlight problems that need to be solved. These stories can be used as tools to help stakeholders empathize with users and to align on target pain points. In consumer apps, storytelling is less about what the product does and more about why it does it. Our goal is to align what people want with the mission of your product.
Create meaningful experiences through clarity and motion
Great design is as transparent and easy to use as a glass of water
Designers are striving to make product flows and user interfaces simpler while decreasing friction. Getting rid of non-essential elements on a user interface often boosts user comprehension and allows them to accomplish their goals faster.
Users of your product are on a mission. Most of the time, they come to your product to with a goal in mind. A designer’s job is to help them accomplish their goal in the most direct and pleasing way possible.
I believe that every element in a user interface needs to be justified in at least two ways. For every element you add, you are automatically decreasing emphasis on the other elements. Think of a crowded navigation with no clear hierarchy.
When evaluating adding a new component, ask yourself, is it worth the visual weight and cognitive load for your users? Does its function aid in directing your users towards their target goals? Is this component surfaced in the right moment of the user flow? Out of all possible solutions, is this one the most appropriate?