BONUS: 5‌ CHECKPOINTS AWARDED WORTH ‌$100‌ EACH

Register
Submit a solution
The challenge is finished.

Challenge Summary

Welcome to “MercuryAccess Wireframe Challenge”! The goal of this challenge is to come up with planning the user experience for an administrator website that controls access between users and devices.

We need to see an intuitive, elegant and easy to use wireframe concepts that will let us design and build the final web-based user interfaces on the next stage of this project. Think about what are the best UX practices when creating this wireframe.

Round 1

Submit your initial wireframes for checkpoint review. Feel free to add any screens which are necessary to explain your concept.
  1. Login
  2. Home
  3. Web Users List
  4. Create, View, Edit, Delete Web User
  5. Spaces List
  6. Create, View, Edit, Delete Space

Round 2

Submit your final wireframes plus checkpoint feedback implemented for the final round. Feel free to add any screens which are necessary to explain your concept.
  1. Login
  2. Home
  3. My Account
  4. Web Users List
  5. Create, View, Edit, Delete Web User
  6. Persons List
  7. Create, View, Edit, Delete Person
  8. Devices List
  9. Register, View, Edit, Delete Devices
  10. Spaces List
  11. Create, View, Edit, Delete Space
  12. System Configuration

Background Information
Our customer, Mercury, is offering key management solutions. They produce electronic keys that enable users to monitor entry to their locations and increase productivity. The inconvenience of having duplicate keys for several people is eliminated this way. The electronic keys are activated by PIN code. These keys can be a proprietary electronic device or a Key application running on a smartphone.

The applications for these keys are multiple: from access to different buildings, houses (real estate) to automobile industry either for dealer managers or individual people, and even banks or ATM services. The keys let you know who opened the building entry / car and who was the last person that accessed them.

In this challenge, we are looking to create the wireframes for an application which will see which devices are accessed by which person and when. The application will have 2 personas: web user and person. The web user will have access to all the system settings and configuration, while the person is able to access a device through mobile only.

As this is a wireframe challenge, feel free to improve the user experience and come up with your own suggestions on the flow, things to display, etc. We're looking forward to your ideas.

Glossary
  • Web user (administrator): has access to system, organization data, multiple site info, can define access permission for other web users, persons, devices and spaces. He can do any actions listed below.
  • Person (regular user/ individual): will have a mobile phone that needs to access the device. Depending on his permission, he might be able to add a new device and edit/delete it, and also create a space and edit/delete it
  • Device: can be a door lock or padlock
  • Space: is a group of devices. For example you might have access to a space which may include a main door and an office door. A space can have 1 or multiple users added to it.

User Story
Mike and his family (his wife Anna, and his kids Tim and John) are using the Mercury Keys. They have a house with 2 cars, 2 garages, a small office and several keys for each family member for the house and the garages. The keys can be accessed through a mobile application and on the electronic key based on credentials.

In this application we would like to be able to monitor and manage these users and devices/spaces, to see which member is accessing which item and when. Each member can name his device such as “Mike’s key”. The key will also have some unique identificator.  Mike will create a space for the house key where he will add all family members to it. He will aso create different spaces for the 2 garages, where he will add him and his wife to garage 1 (for their first car) and his both sons to garage 2 (for the second car).

Below are the required pages for this application:

1. Login
This should be a simple page which will include the option to login with username and password, option register if the user doesn’t have an account and recover his password. Based on the username, the system will detect if the logged in user is a web user (admin) or a person (individual).

2. Home
The home page will be acting as a homepage that will take you to other pages. It should have the ability to switch between building sites/locations for different contexts.
In addition the homepage will also show overall stats about the sites, devices and web users, persons, etc.
  • How many accesses happened in the last 24 hours
  • How many devices have errors
  • If there are any problems for some devices like low battery
  • Latest access for the devices
  • Perhaps other trends in utilization of the devices
  • Anything else you find interesting
 
3. My Account
On this page the user can edit his username, password and change his photo..

4. Web Users List
Here the user will see a list of all web users with their details and access permissions (system wide, organization, multiple site, single site).
  • This page should display both list and grid view
  • We need to have the search and filter options available too
From this page, the user will be able to create a new web user, to view an existing one, edit and delete him.

5. Create, View, Edit, Delete Web User
Create Web User: Creates another administrator with the same access levels as yourself. Each user will have name, username, email, access level, access permission.

Access Level:
  • System Wide (site administrator)
  • Organization
  • Multiple Sites
  • Single Site

Define Access Permissions:
  • Web Users (read, edit)

View Web User: this will show the same details as for the create screen, just that it will be in the non editable form. Here the user is able to reset the 1-time password.

Edit Web User: here the user can see the same information as for creating a new user, just that all the data for the user will be there prefilled and can be modified. Here the user is able to reset the 1-time password.

Delete Web User: we can delete an existing web user from the list and there will be a modal window asking us to confirm that

Think about what other things would be useful  to display here.

6. Persons List
This page will list all the people that are in the system with their details such as username, site name and access, access permission, last accessed device,etc.
  • This page should display both list and grid view
  • We need to have the search and filter options available too

7. Create, View, Edit, Delete Person
Create Person:
A person is an individual that will have a mobile phone that needs access to device/s. Here, the webspace user is allowed to add a new person in the system. That person will have a mobile phone that will need access to a device / key. He will get a push notification and can unlock the access point then. The user will  have an option to enter the person’s first name, last name, phone and set up the devices and spaces he has access to. He can also see which device he has accessed last time and when, the status (has access or not) and last time the person has accessed a device and which one.

View Person: this page shows the person’s details in non-editable way and the devices and spaces he has access too

Edit Person: here the person can modify any of the person’ details

Delete: a person can be removed from the list of total persons

8. Devices List
The devices list page will show all of the devices that exist in the system. Each device will have several fields, such as ID, name, last accessed, status. For each device listed the user can perform several actions: view, edit and delete.

9. Register, View, Edit, Delete Devices
Register Device: the web user is able to register a new device in the system based on the unique ID. The user can also associate a person to the device in this step.

View Device Details: the user is able to see all the details of the device here such as ID, name, which persons have access to it, status, etc. If there are issues with the device such as low battery or throwing errors, those should be displayed too.

Edit Device Details: here the details of the device such as ID and which persons have access to it can be updated

Delete Device: A device can be removed from the devices list and we need to see how that flow happens

10. Spaces List
A space represents a group of devices. The space can have several people added to it as well. On this page, we need to see a list of all the spaces that exist in the system with several details such as their name, the devices in a space and their status, the persons added to that space, etc. Feel free to add any details you might find useful.

11. Create, View, Edit, Delete Space
Create New Space: here the user can create a new space, give it a name and add multiple devices and persons to it. Like for example Mike can create “Garage 1 Space” and add him and his wife to it to park their car.

View Space: this page will display the details of a space such as its name, the devices added to it and their status as well as persons that are part of it

Edit Space: the user can edit here the space name and which persons and devices are part of a space.

Delete Space: we need to see a how the deletion of a space is looking as well

12. System Configuration
System configuration will be available only to the web users who have system wide access. They can do system wide configuration or specific configuration for a site for different owners.
On this page, the user is able to set up notification settings as well as different levels of user access and privacy.

Define Access Permissions:
  • Web Users (read, edit)
  • Persons (read, edit)
  • Spaces (read, edit)
  • Devices (read, edit)

Size
You should plan your experience for Desktop size

Target Users:
The admins who manage the key system and persons who use the key solutions

Tools :
  • We are asking to work with Axure: http://www.axure.com/
  • You can also work with static images but you must include a fully navigable prototype in HTML.
  • If you are designing in Adobe XD, Photoshop or Sketch then it is mandatory that you create the flow using MarvelApp as we are expecting to see a clickable wireframe in this challenge. Feel free to request a Marvel App on forums or email keyla.blue1@gmail.com for that. Note: do not use colors in your wireframes, if you use a design tool! Keep it simple – black and white, as we are focusing on the UX here, not the UI.

Stock Photography and Icons
Judging Criteria
  • User Experience of the application
  • Completeness and accuracy of your wireframes
  • How well your wireframes provide a consistent user flow

Final Deliverables
  • Source.zip – All original source files.
    • All source files of all graphics created in Axure(.rp) or any design tool
  • Submission.zip – PNG/JPG files
    • Submit JPG/PNG image files based on the Challenge submission requirements stated above.
  • Preview.png – Your preview image
    • Please create your preview image as one (1) 1024x1024px JPG or PNG file in RGB color mode at 72 dpi and place a screenshot of your submission within it.
  • Declarations.txt – All your declarations and notes
    • This file must contain your notes if any, fonts used, links to the stock images and icons used and the link to your Marvel projec

Please read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. It is important that you monitor any updates provided by the client or Studio Admins in the forums. Please post any questions you might have for the client in the forums.

How To Submit

  • New to Studio? ‌Learn how to compete here
  • Upload your submission in three parts (Learn more here). Your design should be finalized and should contain only a single design concept (do not include multiple designs in a single submission).
  • If your submission wins, your source files must be correct and “Final Fixes” (if applicable) must be completed before payment can be released.
  • You may submit as many times as you'd like during the submission phase, but only the number of files listed above in the Submission Limit that you rank the highest will be considered. You can change the order of your submissions at any time during the submission phase. If you make revisions to your design, please delete submissions you are replacing.

Winner Selection

Submissions are viewable to the client as they are entered into the challenge. Winners are selected by the client and are chosen solely at the client's discretion.

Challenge links

Screening Scorecard

Submission format

Your Design Files:

  1. Look for instructions in this challenge regarding what files to provide.
  2. Place your submission files into a "Submission.zip" file.
  3. Place all of your source files into a "Source.zip" file.
  4. Declare your fonts, stock photos, and icons in a "Declaration.txt" file.
  5. Create a JPG preview file.
  6. Place the 4 files you just created into a single zip file. This will be what you upload.

Trouble formatting your submission or want to learn more? ‌Read the FAQ.

Fonts, Stock Photos, and Icons:

All fonts, stock photos, and icons within your design must be declared when you submit. DO NOT include any 3rd party files in your submission or source files. Read about the policy.

Screening:

All submissions are screened for eligibility before the challenge holder picks winners. Don't let your hard work go to waste. Learn more about how to  pass screening.

Challenge links

Questions? ‌Ask in the Challenge Discussion Forums.

Source files

  • RP file created with Axure
  • Sketch
  • XD
  • PSD
  • AI
  • Figma

You must include all source files with your submission.

Submission limit

Unlimited

ID: 30122200