This blog can be as well applied for developing any app frontend for end-users. I went through this in corporate environment several times, so believe me it works. Of course you can skip some steps to make it faster, but what I will describe is the ideal scenario and in terms of waterfall proceeding. If you are good with starting small (with Minimum Vial Product) and grow in agile way step by step, you just transform these steps to personal competencies and start an agile team.
Idea
Everything starts with business idea. It’s good to make some quick research among your closest friends or colleagues, if the idea is good enough to be welcomed by masses or it solves only your tiny little problem. As soon as you feel confident, move on to the next phase.
Write down the the goal
Along with your ideas, it usually comes down a vision of a solution. Try to stay unattached and write down the root goal behind your idea. Then think about possible different solutions, how to achieve your goal. Once you are sure, web site is a best way to realize it, proceed further.
Analysis part
If you are analytical person, doing big project, which you need to defend, doing web site first time or you just want to spend some more time before going to everyone else, you can focus on:
- Personas – who are targeted visitors. Describe them.
- Scenarios – what will the personas do on the web site?
- Priorities – define priorities for each part of your analysis output. For example on homepage you will want to have link to everything. But if you overwhelm your users, it will not help the UX.
- User stories – you can enhance the analysis or describe better with using user stories – who will want something and why. This part can be extended even as “what my stakeholders want”. But remember, end-user decides if he will like to use the application, so he should be on first place, especially when building website and not an internal app.
User eXperience / Wireframes
Now it’s time to hand your work over to uninvolved experts. Only someone from outside, not burdened with internal policies, regulations and processes can think as “typical user” and create wireframes (functional model, easy and not as costy for development) for you, so you can materialize your idea start to shape to perfection.
Test in UX Lab
It’s got to reach feedback of others after each phase, but if you haven’t, this is for sure the best time to get it, before you get too far and any change or lesson learned will cost you a lot. And remember your UX designer is working based on his experience and best practices he learned in his career, he’s not a god.
A good way to proof your wireframes is to engage a specialized UX Lab, which will help you construct a focus groups or individual usability tests, in example with eye camera (producing useful heat maps) on multiple devices. It’s good to onboard your UX designer, so he can hear the feedback directly without any misinterpretation and change the wireframes between the sessions, which will save you money for doing another UX Lab.
All internal stakeholders feedback
Because I am describing waterfall proceeding and not agile, now it’s good time to show your results with all internal stakeholders (legal, compliance, business operations, call center, …, and of course your sponsor / management).
You have all the arguments why you did all what you did in a way you did it, so it should be easy to argue with these departments and not destruct your key idea with limitations, regulations or visions of others. Of course, you need to show some will and incorporate the most important feedback into your wireframes.
UX / Graphics design
Now, that you eliminated most of the risk of reworking the costly parts, you can engage your best graphic, but remember, even graphic design should serve the higher purpose, which is the UX.
Don’t forget to get feedback with anyone who you think is important and be prepared, that if you are not aligned with coporate design manual, you need to have strong arguments.
Coding / Programming
I am a business person, so, let’s just say, we will wait, after it’s programmed. Be sure, to tell the vendor that you are open to any programmer’s questions. Still, you can save some money here with good communication, before the work is done. And second thing, if you are a project manager – tell the vendor to follow the OWASP top 10, you can save some money in later phases and reduce the project risks.
Functional (integration) testing
So this should be separated phase from user testing. You don’t want to involve your end users, when the integration with another system doesn’t work the way it should, or the function is doing something else, than specified. And be sure that after coding and programming, the solution is not working. If you skip this phase, you will only upset your end users, which are from the perspective of the delivery of the project the most important ones, because they doesn’t have to accept the solution and then you spend all your money for nothing.
You can develop very complex test scenarios – to save end users some work, or do at least minimum smoke test of all functions and integrations at this phase. Decide wisely, because your stakeholder goodwill in not endless.
User Acceptance Testing
If you spend some time within analysis part, you will have it easier. Now you need to develop at least basic user testing scenarios (based on your personas, scenarions and user stories), because be sure, you will do the test several times and you don’t want to forget anything. I will go deep dive on UAT in different blog.
Penetration testing
Ok, so you developed all your web site with the help of your vendors, because it’s faster and your company trusts you. You did not include your IT yet? If so, now it’s the best time. Your IT doesn’t care what you are doing on the web site, if you are audit compliant and there will be no security issue later. You should consider risk of skipping this phase even if you are working for a small company.
But how to ensure the app is safe? All apps are safe, until some vulnerability is found. So we can only minimize the risk, that there is some easy to found vulnerability. And that’s what penetration tests are for. Remember when I told you, that your programmers should follow the OWASP top 10? Penetration will try to find a vulnerability on your site, by focusing on most common programming mistakes.
But how you should know if there is any risk at all and you need to spent anything on penetration testing? Well I will follow risk management in different blog, but let’s just say, the risk is higher when:
- you are working with personal data
- you have any database underneath
- you have login / password functions
- you have any user inputs at all (any form)
- you are using flash
- you are including dynamic components located on another sites (even tracking codes)
Stakeholder acceptance
This is the most annoying part of the project. You need to write formal document or at least email and go to all the key stakeholder representatives to sign, that they accept the solution. But why?
You can of course skip this phase if you believe in your co-workers, but there are several reasons even if you are family company:
- stakeholder will realize, the accountability for the solution is not only yours, and think twice if he did not forgot anything from his area. Of course, this could raise additional tasks or some discussion.
- when issue is found on production, you have indisputable proof, that these areas were covered by someone. Don’t think of it as a weapon for corporate fighting, but rather than insurance, when the person leaves company and you had just his word.
- when you have signature of others and issue raises, you will not need to beg for cooperation on solving this issue
And who can be the stakeholders? Well, when designing web sites, you won’t have the end users, as you will probably be the one doing UAT. But you will need:
- legal department (cookie definition)
- information risk management (penetration tests)
- IT guys (ie. domain ownership, https certificates, …)
- compliance (misselling wordings)
- marketing (URL address, advertisement)
- corporate branding (aligned design or approved exceptions)
- whoever else was involved during design process or should be aware
GoLive and celebrate
Don’t think that with acceptance, it’s over. You need to plan your GoLive precisely. Be sure, that everyone involved know about the release date and agrees with it. Imagine you will postpone GoLive without knowledge of marketing and the advertisement starts running day before. Or that your IT will make the domain public, but the production database was not migrated. This is the key part, when everyone has to be aligned, so focus on communication and good luck!
Project steps summary:
| 1 | Idea |
| 2 | Write down the goal |
| 3 | Analysis – Personas / scenarios / user stories |
| 4 | UX / wireframe |
| 5 | Test in UX lab |
| 6 | All internal stakeholders feedback |
| 7 | UX / graphics design |
| 8 | Coding / programming |
| 9 | Functional (or integration) testing |
| 10 | User acceptance testing |
| 11 | Penetration testing |
| 12 | Stakeholder acceptance |
| 13 | GoLive and celebrate |
Game Changer 