How to design beyond the interface
All of the design elements you need to add beyond user interfaces (UI), user experience (UX), and interactions (IxD).
You mapped out a user journey, designed the screens, and added in interaction animations to a prototype — job done… right?
Not really. Once you go a level deeper you’ll see there’s a lot more to consider. And I’m not just talking about covering the different UI states of buttons!
This whole topic was a huge motivation for Primary itself. In this article we’ll go through the different design elements which will help:
Contents
- Introduce our five (additional) design elements
- Use each element in a case study
- Tie it all together in one user flow
1. Five (additional) design elements
Design element? The term design element isn’t part of the design lingo, or nomenclature, of technology, design, or software. It’s intended to be inclusive and covers: “things that are part of designing and analysing digital products and services”—
… obviously design element rolls off the tongue better.
Design elements and their roles
There are many elements which you need to consider in your project. We’ll focus on just five.
As you can see, these examples are not technical! They sit comfortably on the business and design side.
2. Case study: sign up flow
Let’s use a standard onboarding flow as our case study. We’ll step through each of the design elements, building on each design element as we go.
Interfaces in context (1/5)
Okay we’ve connected two screens… done and dusted?
Nope! There’s likely an interface missing. Do your users get an email when they sign up?
The flow, or series of interfaces doesn’t have to be strictly in sequence. Remember you are trying to communicate how the app works, not just simulate one or two scenarios with a prototype.
Each extra step you miss, is like each extra jacket you try to wear through airport security; every additional one will lead to a lot of questions. Sure you can get away with one here or there but if you do it multiple times you’ll be in serious trouble.
Here’s a few questions that the extra step for the “sign up email” could cause down the line:
- Is there a template for that?
- Which system is that coming from? (Intercom?)
- How does this fit in with the other customer onboarding communications?
- Who is responsible for creating the email?
User types in context (2/5)
Who your users are is an important topic for UX research and marketing. Who your users are and what they are allowed to do in your product is important to define for developers and designers.
In our example it could be as simple as a visitor becomes a user after signing up. Likely it’ll be more complex. In our example, a user signs up, and then is given trial of the fully-featured Pro plan for seven days.
This leads to more cases and questions that need to be designed for:
- What can the Pro user do that the Free user cannot do?
- What happens seven days after the user signs up?
- Is this just a short-term promotion? Should it be flexible enough to extend to other plans?
- Do all visitors get access to the trial, or just visitors with the right email addresses?
These questions cover many different features, flows, and interfaces; it’s best to define a lot of this under each user type.
Forms in context (3/5)
There are countless articles about the UX of forms, but there’s not much written about deciding on what fields to include and how they work.
In our example there is a form in the first step.
There’s more to cover than the UI states of each field! Here’s what you should consider:
Getting these details right up front is the easiest way to save money and time. It does not cost much to change things in this design phase, but is relatively quite expensive to change once it is in code.
Data in context (4/5)
In our flow the user fills out the form, clicks submit, and then sees the beautiful onboarding page. What else is happening?
There is data being entered, saved, used, and changed. Some of this falls in the technical realm, but there is a lot to consider from a design standpoint.
Here are some questions which could come up about data in our flow:
- What user data are we storing? Just what’s in the form?
- How do we add this to the company’s CRM?
- Can we use this information to personalise the onboarding screen?
Let’s include the data design element called “customer tag”. This will allow us to tag a user after they complete sign up so we can send them the right messages. This could be used to link the seven day trial we mentioned above in the user section.
There’s always a lot going on with data in applications. We’re interested in the data which has meaning to the business and users. Some of the data required may seem obvious to you but won’t be obvious to the person implementing the design without the same context.
For example, your company’s CRM might need to collect the post code of your users. If you don’t capture that in the design you’re essentially outsourcing decision making to someone else down the line, or for yourself as rework.
Rules in context (5/5)
Rules help organise your designs. They are used to define the constraints, intentions, alternate paths, edge cases, and fallbacks of the system you are design.
When does something classify as a Rule? Anything that involves the application of logic or a conditional test is best captured as a rule. User actions should not include conditions, as this breaks the narrative and makes the flow harder to understand.
You could define the details of a discount code at checkout as a Rule which defines how the discount code works in a few lines. You could also use a Rule to define the complex calculation of a portfolio’s expected return in many pages complete with figures and attachments.
Here’s how we used a rule in our example:
We included the Rule ‘Check for priority customers in sign up’. This Rule covers the case for checking if a new sign up should be given a different onboarding experience, if their email address comes from an enterprise customer account.
We define it here because it’s outside of the standard sign up process and will be important to discuss and design before implementation.
I personally feel like the blind faith given to ‘iteration’ hides a lot of unnecessary rework. If you implement the flow without the rules in this example, and you later have to include it later, was it an “amazing UX discovery”, or is it rework?
3. Tying it all together
What’s the point? Great question, these additional design elements are a lot of work! But every element you add could save at least a:
- meeting,
- issue card,
- email,
- thread,
- or post-it note angrily placed on your monitor before you got into work.
In our case study we defined only eight elements and this saved at least 28 questions. These questions (read: rework) could have come from a range of people in your team: developers, product managers, marketers, and eventually customers.
Sure you could have covered a lot of those questions in business-requirements and technical-requirements documents but that’s far less fun. It’s also less effective.
Why does this work?
Our monkey brains only seem to work well with and remember stories. So it’s only when you go through the flow your users’ take does all of the design elements become clear.
Beautiful! And so time-consuming to make! If you want to cover the same content and not spend your life in Sketch to design it, then try out our tool Primary.
Like I said at the start, this topic was one of the main reasons we created Primary. We know these elements are first-class citizens of designing digital products. (And if it’s not for you, that’s cool — these design elements are still valuable however you use them).
I guess I went over the recommended 4 minute read attention span on articles, so if you’re still here let me know with 24–46 claps and a comment. I promise to respond to every question in the comments!
