I was asked by a colleague to take a look at/do some UX work on his app, "Illume". His mission was to solve problems that both residents of urban High-Rises and visitors/delivery persons experience.
His initial designs can be seen below in a prototype video, 1.a.
Figure 1a. Initial designs presented to me.
Through research and interviewing doorman and building management, the pain points became clear:
*Doormen are not always present when guests or deliveries show up.
*Many buildings still use paper logs of guest and deliveries. A lot of clutter and illegible entries could be a liability.
*Sometimes residents do not answer the phone or do not leave proper identification for food deliveries leaving the courier frantic for time lost figuring out their customer's location.
Taking these problems into consideration, I started off creating personae and user stories for them to help map out each touch point for all aspects of this environment. A rough sketch of a user journey can be seen below in figure 1.b
Figure 1.b. shows a very rough sketch attempting to understand the problems that delivery men and women experience delivering to high rises.
The initial designs didn't take into account buildings not allowing front doormen to give out names and unit numbers. This prototype would allow anyone to look up everyone who lives in the building and their unit numbers, which is a liability. In order to get around this road bump, I ideated and sketched out some ideas, they can be seen below in figure 1.c.
Figure 1.c Some early sketching and ideating for solving the problem of disclosing tenant names and unit numbers. In order to get around that, the person checking in will be able to search by name or unit number and then be required to verify the corresponding name or unit number.
I then moved onto a medium-fidelity wireframe to illustrate the concepts explored in the sketches above. The wireframe can be seen below in figure 1.c.
Figure 1.c. A prototype made from medium-fidelity wireframes.
Our next step was to fill out a business requirements document to hand over to the developers. This can be seen below in figure 1.d., and it provided some clarity into the functionality of our design.
Figure 1.d. Business Requirements Document.