We like to expose the design to some stress before the development starts.
For this project we built a classic usability task test using Maze. We set up the tasks to complete with Maze (which uses the Invision project we built with the designs).
We use to share the link to stakeholders, customers, and other users within the considered roles and profiles, but for this specific test we arranged presential tests.
Sketch of the main areas and interaction
It was amazing to see how users interacted with it directly. We learnt a lot of things, realised that some assumptions we made were wrong, and had to redesign a couple of areas.
In a few hours we arranged a second version of the test with updated screens that really worked better.
Let’s test it!
We sketched the main funcionalities, navigation and interactions with Invision Freehand, and collaboratively refined them with stakeholder and key users.
Building the concept
Sketch of the main areas and interaction
The wires defined most of the UI language, but we had several iterations and variations of the visual design.
Visual design
Different cards for different meanings. Took
a while to agree on which to use :)
Landing page design evolution
The full app was wireframed inan Invision project, so that we could figure out the real flows and how they were perceived.
The wires
Full wireframe project to test in real devices
For the first release the app had 2 main areas and 5 core functionalities. In Release 3, just three months later, the app had 7 main areas ans 17 core functionalities + 32 complementary functions. How do we handle this evolution? How does it affect the navigation model?
We didn’t want users to learn everything from scratch (different navigation models, action models, accesses) for evey relase, so we figured out a hybrid navigation model that helped users understand navigation.
The main navigation is held with a BottomBar navigation. In Release 1 just 2 areas and the Profile would be there. In Release 2 the 4 main areas and the Profile will be there. And in Release 3 the last of its options will be a “More” menu, that will launch a popover with the rest of the areas.
Some areas that in earlier releases were hosted at first level may now appear in the “More” popover (due to relevance and priorization), but it will be the only change users may feel. From there, everything is perceived as “organic growth”.
The organic evolution of the main navigation model
“The app will go from low functionality to high functionality within 3 months. We need to handle evolution in a way it doesn’t disturb users”
The challenge
• We played “Buy a Feature” to reveal priorities.
• We then played “Prune tree” to stage functionalities in different releases.
• We played the O Test to reveal risks, assumptions, and gaps we may have missed.
Prune tree
O Test
The Design thinking research provided a full set of functionalities the mobile app sould have, and a user-focused priorization (which of them were the most relevant, and which the less).
We focused our efforts infiguring out which of them the app couldn’t live without, which were good to have, and which were a nice-to-have, prioritizing functionalities and obtaining a release plan.
Research & insights
Lidl recently ran with Dinngo a quite deep design thinking research focusing on communication flaws and issues between the core of the company (and offices) and the rest of the organization, such as stores, employees, blue collar staff, and so on.
The conclusions seemed to lead to a mobile app that helped employees get access to corporate news, and also training, documentation, contract management, and related stuff.
“After deep research & investigation, we figured out that we need to build an app for our employees. For all of them, from central offices to the people in the fridges in the stores.”
The kickoff